Introduction to
Microservices

About Me!
Anil Allewar
• Technology Evangelist
& speaker
• Core interests: Cloud,
Enterprise, Mobile

Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics

Software Architecture Evolution
http://www.kanbansolutions.com/blog/microservices-architecture-friend-or-foe/

Monolith

Microservices

Crux of Microservices
Bounded business
context

What are Microservices actually?
Services build around
bounded business
context
Independent
development, testing and
deployment
Interact with end-user
and with each other
using well defined
contract
De-centralized data
management and
governance
Automated
deployments
Intelligence in the
endpoints and dumb
pipes

Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics

SaaS & 12-Factor Apps
Software-As-A-Service
• Subscribe to software – periodic contract
• Scalability – horizontal
• Multi-tenancy
12-Factor apps
• Methodology for building SaaS apps
Majority of Microservices & distributed system concerns
are defined by 12-factor methodology

12-Factors
1. Codebase
• Single codebase for one app - tracked in revision control
• If more than 1 app then each has it’s own codebase - distributed system
2. Dependencies
• Declared explicitly through dependency manifest - gradle, maven, npm
• Dependency isolation - no implicit dependencies, gradle
dependencyManagement for exact version of dependency
• Simplify developer setup
• Project dependencies - build system (gradle)
• Runtime dependencies - containers (docker, linux lxc)

12-Factors
3. Processes
• Stateless - share nothing
• Persistent data needs to be stored in stateful backing service like database
4. Port binding
• Export HTTP as a service by binding to a port
• In built web server like Tomcat for Spring boot
5. Concurrency
• Different process models for different tasks - WebServer for HTTP, workers for
background
• Multiple processes on multiple machines - easy to scale out

12-Factors
6. Config
• Strict separation of config from code
• Hosted externally or setup as environment variables
7. Backing services
• Databases, message queue system, S3 etc
• Treat as attached resources accessed over a URL
• No code changes needed for resource swap - local mySQL with RDS
8. Build, release run
• Strictly separate build (say gradle), release(say Jenkins) and run (say docker
orchestration)
• Ability to rollback to previous release

12-Factors
9. Disposability
• Started or stopped at moments notice
• Pets v/s Cattle
10. Dev/prod parity
• DevOps, quick deploys
• Use Docker and external configuration
11. Logs
• Treat logs as event streams routed to common destination
• ELK stack, Fluent etc

12-Factors
12. Admin processes
• One off administrative maintenance tasks like database migration,
running one-time scripts
• Must ship with application code

Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics

Communication

Silos

Business Agility

Scale Cube
To ensure scalability – applications should be able to scale in at-least 2 axis

Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics

Who is doing microservices?

Monolith
Horizontal
scaling
3-4 months
gestation
Fear of release
Quicker competitorsGo-live firefighting
Unintended side
effects
Recruitment
Monolith
Release – 4
months

Chipping The Monolith

Large Distributed System
APIGateway
(Zuul)
Config
Server
Registry/Di
scovery
(Eureka)
Circuit
Breaker
(Hystrix)
Web Portal
Web
Service 1
Web
Service 2
Web
Service 3
Web
Service 4
DB2DB1
Auth Server
Auth-DB
Ribbon RibbonRibbon
Web
Apps
Mobile
Apps
3rd Party
Integration
Github
Registry
Dashboard
Health
Dashboard
OAuth 2.0
Security
Metering
Load Bal
Routing

Agenda
• What are Microservices?
• SaaS and 12-Factor apps
• Typical Use Cases
• Why Microservices?
• Characteristics

Characteristics of Microservices
Componentization via Services
Organized around Business Capabilities
Products not Projects
Smart endpoints and dumb pipes
Decentralized Governance
Decentralized Data Management
Infrastructure Automation
Design for failure
Evolutionary Design
Aligned towards developing cloud native SaaS application following Twelve Factor Apps

Componentization via Services
Any Failure means
redeploy entire application
Failures means only that
microservice is redeployed.
Circuit Breakers can help stop
propagate the effect
May or May not have
published interfaces
between components
Restful APIs mostly are the
published interfaces.

Organized around Business Capabilities

Products not Projects
Project Model
Product Model
Amazon Model- You Build it, You run it !

Decentralized Governance
nodejavarubyR
hbase
redismysql

Decentralized Data Management

Infrastructure Automation
Continuous Delivery A Must
Monolith Microservice

Design for failure
Microservices needs following to function
1. Circuit Breaker – Fallback Response
2. Detect Failure Early
3. Automatic Restore

Evolutionary Design
Drive modularity through the pattern of change
Ongoing service decomposition - independent
replacement and upgradeability
You want to keep things that change at the same time in
the same module

Microservices - Challenges
If you can’t build a well-designed modular monolith, what makes
you think Microservices is the answer? – Simon Brown
If not well designed – Microservices would become distributed ball
of mud (though more modular!)
Well defined software modules in monolith(Domain Driven Design)
is pre-requisite to converting it to micro-services
Hence always try to start as monolith (more agile) and then
decompose to Micro-services once modularity & complexity is
prime concern

Organization & Architecture Changes
Attempt Microservices to transform your business
Microservices will trigger organization change
Learning organization
Deliberate & discuss – benefits v/s risks
Versioning of contracts between services
Dormant Monolith
Automation and DevOps intrinsic to Microservices

Organization & Architecture Changes
Monolith first - Version 1.x of system
Domain driven design – services with well defined seams
Peel off Microservices once complexity and scaling needs
affect productivity & innovation
Invest in product management and QA
Containers & Orchestration

Considerations
Upfront planning & decomposition of business services - else
spaghetti architecture
Avoid distributed monolith – Things that change at the same
time should be in the same service
Monitoring Microservices is order of magnitude harder –
deployment map & health status
Centralized logging, alerting and distributed tracing - critical to
debug & resolve production issues
Circuit breakers to prevent chain of failure

Considerations
Issue in service A could be because of input from service B or
messaging queue - APM tools & strong service contracts to
isolate root cause
Services graph - Dependency and version management
IT Governance – streamline tools & methodology
Track what service API gets exposed and their security
Consumer driven contracts for robust API – check out Pact /
PactJVM

Microservices Frameworks

Spring Stack - Java
Spring Boot, Spring Cloud withNetflix OSS/Consul
Most stable and mature Microservices platform
Opinionated view of building production applications
using Spring framework – convention over configuration
Supports both synchronous HTTP and reactive micro-
services
Additional support for streams, tasks, AWS, distributed
tracing etc.

Vert.x
Vert.x is a tool-kit for building reactive applications on the
JVM
Event-driven and non-blocking using asynchronous
message passing
Can be used with multiple languages including Java,
JavaScript, Groovy, Ruby, and Ceylon
Based on Java 8 so you can write elegant code using
lambda and streams

Lightbend Lagom
Lagom is an integrated microservice platform built in Scala
APIs initially are provided for Java services, with Scala to
follow
Provides for asynchronous communications and event-
sourcing (capture all changes to the application as a
sequence of events)

Seneca
Seneca is a Microservices toolkit for Node.js
Seneca has the following three core features:
• Pattern matching: Instead of fragile service discovery, you just let the
world know what sort of messages you care about.
• Transport independence: You can send messages between services in
many ways, all hidden from your business logic.
• Componentization: Functionality is expressed as a set of plugins which
can be composed together as Microservices.

Contact Me
anilallewar@yahoo.co.in
https://www.linkedin.com/in/anilallewar
https://github.com/anilallewar
http://www.slideshare.net/anilallewar
@anilallewar