Microservices Patterns
Jim Bugwadia, Nirmata
DEVNET-1184
About me
• Founder and CEO at Nirmata
• Software Developer (C++, Java, Javascript, Go)
• Large-scale distributed systems
• Why Microservices
• Microservices defined
• Architecture & Design Patterns
• Summary
Agenda
Businesses are adopting Microservices for agility at scale
20% of enterprises will adopt Microservices by 2016” -- Gartner
A Microservices style application is composed of several cooperating
services, each of which is versioned and deployed individually.
Monolith
ms
msms
ms
Microservices  Agility
• The Art of Scalability
AKF Scale Cube
Microservices  Scale
Client Load Balancer Application
Application
Application
X-Axis Scaling
scale by replicating the entire application
Client Load Balancer Orders
Catalog
Customers
Y-Axis Scaling
scale by splitting the application into components /catalog
/orders
/customers
Client Load Balancer
Z-Axis Scaling
scale by splitting the data /catalog[a-i]
/catalog[j-r]
/catalog[s-z]
Catalog
Catalog
Catalog
Client Load Balancer
Microservices combine
X-Y axis scaling
Orders
Catalog
Customers
/catalog
/orders
/customers
scale by splitting the application into services,
and replicating each service
Client Load Balancer Orders
Catalog
Customers
/catalog
/orders
/customers
scale by splitting the application into services,
and replicating each service
Best scalability
Best resiliency
Best efficiency
Microservices combine
X-Y axis scaling
Microservices Defined
1. Elastic: scales up or down independently of other services
2. Resilient: services provide fault isolation boundaries
3. Composable: uniform APIs for each service
4. Minimal: highly cohesive set of entities
5. Complete: loosely coupled with other services
A Microservices application is composed of multiple cooperating services.
Each Service is:
Microservices Architecture &
Design Patterns
The Monolith Pattern
• Tiered approach
• Modules within each tier are
compiled and integrated
• Easier to build and manage
• Long test cycles for any change
• All-or-nothing deploys
Client
Load Balancer
Application
Database
WebUI
Orders Catalog Customers
Reviews Cart Payments
… … …
The Microservices Pattern
• Multiple services with Uniform APIs
• Services can be build, tested, and
deployed separately
• Enables rapid experimentation on
smaller components
• Can have:
• Polyglot languages
• Polyglot data stores
Client
Load Balancer
Gateway
Gateway
Customers
ReviewsPayments
Cart
WebUI
Catalog
Orders
Microservices: Inner and Outer Architecture
• Microservices are meant to be simple
• Complexity gets pushed outside the Microservice
• A platform built for Microservices must absorb this
complexity
That [the complexity you removed from your services to simplify them ]
complexity has moved and, I would argue, increased. It now lives in what I
call the ”outer architecture”. -- Gary Olliffe , Research Director at Gartner
Service Naming, Registration & Discovery
• Each Service has a well known name
• Each Service Instance dynamically
registers its availability
• Clients can resolve a well known
Service name to the location of an
available Service Instance
connect with me at:
orders.shopping.com
192.168.50.11:9762
192.168.10.7:80808
192.168.3.12:42132192.168.100.23:9065
192.168.100.23:9065
e.g. Netflix OSS, Nirmata Service Networking
Service Gateway Pattern
• An entry point for the application
• A single client connection is
multiplexed across backend
services and service instances
• Routes requests based on
content (e.g. URL Path)
• An application can have multiple
gateways
Gateway
Gateway
CustomersWebUI
Catalog
http://shop.io
Load Balancer
/ui
/catalog
/customers
e.g. Zuul, Hipache, Nirmata Gateway Service
Mid-tier Load Balancing
• Services in an application need to
communicate
• Each Service is elastic and
resilient
• Scale-out dynamic load balancing
is required
• Client-based LB
• Host-based
• External service
e.g. Zuul, Nirmata Dynamic Proxy
Gateway
Gateway
CustomersCatalog
http://shop.io
Load Balancer
/catalog
/customers
LB
Distributed Locks
• Coordinate operations across several
Service Instances
• DB level locks are not enough
• Implementations should provide
Mutex, Semaphore, RWLock
semantics
e.g. Curator / Zookeeper
Lock Service
Server Server Server
Catalog Catalog
Lock /catalog/item/12a91kl
Lock /catalog/item/09a9ab
Unlock /catalog/item/09a9ab
…..
Lock /catalog/item/ij98108
Unlock /catalog/item/ij98108
…..
Shared Work Queue
Leader Election
• Select one service instance to perform
a task
• Good for lightweight scheduling of
periodic tasks
• Use different leaders for different
functions
• Run elections periodically
• Nodes can join election at any point
• If leader node goes away, a new
leader is elected
e.g. Curator / Zookeeper
Leader Elector
Server Server Server
Catalog Catalog
-> Elect /catalog/purge-> Elect /catalog/purge
<- Take Leadership
Distributed Workflows
• Coordinate execution of a set of tasks
across services instances
• Each task may be executed by a different
services
• Tasks may execute in parallel, and may
have inter-dependencies
Workflow Service
Server Server Server
e.g. AWS SWS, NirmataOSS Workflow
Catalog Catalog
Summary
Summary
1. Microservices enable agility at scale
2. Microservices push complexity into the platform
3. Microservices require operations tooling and
distributed programming skills
Related Sessions
Come try it live @ DevNet Cloud POD #3
DEVNET-1170 - Intercloud Microservices with Docker
and Nirmata
Thursday, Jun 11, 11:00 AM - 11:30 AM,
DevNet Theater
DEVNET-1137 - Application Centric Microservices Wednesday, Jun 10, 3:00 PM - 4:00 PM.
DevNet Theater
DEVNET-2013 - DevOps In Depth - Adrian Cockroft on
Fast Delivery
Tuesday, Jun 9, 1:45 PM - 2:30 PM,
DevNet Theater
BRKDEV-1002 - What's Hot in Containers Thursday, Jun 11, 1:00 PM - 2:30 PM,
30B Upper Level
References
• Microservices : Building Services with the Guts on the Outside, Gary Oliffe,
http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the-
outside/
• Migrating to Cloud Native with Microservices, Adrian Cockroft
http://www.slideshare.net/adriancockcroft/qcon-new-york-speed-and-scale
• Microservices: Decomposing Applications for Deployability and Scalability, Chris
Richardson,
http://www.infoq.com/articles/microservices-intro
• Microservices, James Lewis and Martin Fowler,
http://martinfowler.com/articles/microservices.html
• Cloud native software: Microservices, Jim Bugwadia
http://nirmata.com/2014/07/cloud-native-software-microservices/
Thank you
Other Interesting Patterns
• CQRS (Command Query Responsibility Segregation)
Separate model updates from views
http://martinfowler.com/bliki/CQRS.html
• Bounded Context
Keep different models independent
http://martinfowler.com/bliki/BoundedContext.html
• Event Sourcing
Use events, with playback, to manage distributed state
http://martinfowler.com/eaaDev/EventSourcing.html
Single Sync
• Each user call results in a
single synchronous call
• A user call spawns one or
more Distributed Workflows
• Workflow tasks update user
state via APIs
• Retries and failure recovery
are built-in per tasks
Client
Gateway
Service
Orders Service
Payment
Service
Message Queue
1. Place Order
2. Route Request
3. Validate
& Commit 4. Publish {new order}
5. Handle Payment
6. Publish
{payment update}
7. Update Order
Rest Cache
• Services are using REST
APIs to communicate
• Frequent fetching of data
causes latencies
• A local cache can reduce
latencies
• Async Messaging can
update the cache
Orders Service Catalog ServiceREST
Message Queue
Updates
Updates
Catalog
Cache
POST,
PUT,
DELETE

DEVNET-1184 Microservices Patterns

  • 2.
  • 3.
    About me • Founderand CEO at Nirmata • Software Developer (C++, Java, Javascript, Go) • Large-scale distributed systems
  • 4.
    • Why Microservices •Microservices defined • Architecture & Design Patterns • Summary Agenda
  • 5.
    Businesses are adoptingMicroservices for agility at scale 20% of enterprises will adopt Microservices by 2016” -- Gartner
  • 6.
    A Microservices styleapplication is composed of several cooperating services, each of which is versioned and deployed individually. Monolith ms msms ms Microservices  Agility
  • 7.
    • The Artof Scalability AKF Scale Cube Microservices  Scale
  • 8.
    Client Load BalancerApplication Application Application X-Axis Scaling scale by replicating the entire application
  • 9.
    Client Load BalancerOrders Catalog Customers Y-Axis Scaling scale by splitting the application into components /catalog /orders /customers
  • 10.
    Client Load Balancer Z-AxisScaling scale by splitting the data /catalog[a-i] /catalog[j-r] /catalog[s-z] Catalog Catalog Catalog
  • 11.
    Client Load Balancer Microservicescombine X-Y axis scaling Orders Catalog Customers /catalog /orders /customers scale by splitting the application into services, and replicating each service
  • 12.
    Client Load BalancerOrders Catalog Customers /catalog /orders /customers scale by splitting the application into services, and replicating each service Best scalability Best resiliency Best efficiency Microservices combine X-Y axis scaling
  • 13.
    Microservices Defined 1. Elastic:scales up or down independently of other services 2. Resilient: services provide fault isolation boundaries 3. Composable: uniform APIs for each service 4. Minimal: highly cohesive set of entities 5. Complete: loosely coupled with other services A Microservices application is composed of multiple cooperating services. Each Service is:
  • 14.
  • 15.
    The Monolith Pattern •Tiered approach • Modules within each tier are compiled and integrated • Easier to build and manage • Long test cycles for any change • All-or-nothing deploys Client Load Balancer Application Database WebUI Orders Catalog Customers Reviews Cart Payments … … …
  • 16.
    The Microservices Pattern •Multiple services with Uniform APIs • Services can be build, tested, and deployed separately • Enables rapid experimentation on smaller components • Can have: • Polyglot languages • Polyglot data stores Client Load Balancer Gateway Gateway Customers ReviewsPayments Cart WebUI Catalog Orders
  • 17.
    Microservices: Inner andOuter Architecture • Microservices are meant to be simple • Complexity gets pushed outside the Microservice • A platform built for Microservices must absorb this complexity That [the complexity you removed from your services to simplify them ] complexity has moved and, I would argue, increased. It now lives in what I call the ”outer architecture”. -- Gary Olliffe , Research Director at Gartner
  • 18.
    Service Naming, Registration& Discovery • Each Service has a well known name • Each Service Instance dynamically registers its availability • Clients can resolve a well known Service name to the location of an available Service Instance connect with me at: orders.shopping.com 192.168.50.11:9762 192.168.10.7:80808 192.168.3.12:42132192.168.100.23:9065 192.168.100.23:9065 e.g. Netflix OSS, Nirmata Service Networking
  • 19.
    Service Gateway Pattern •An entry point for the application • A single client connection is multiplexed across backend services and service instances • Routes requests based on content (e.g. URL Path) • An application can have multiple gateways Gateway Gateway CustomersWebUI Catalog http://shop.io Load Balancer /ui /catalog /customers e.g. Zuul, Hipache, Nirmata Gateway Service
  • 20.
    Mid-tier Load Balancing •Services in an application need to communicate • Each Service is elastic and resilient • Scale-out dynamic load balancing is required • Client-based LB • Host-based • External service e.g. Zuul, Nirmata Dynamic Proxy Gateway Gateway CustomersCatalog http://shop.io Load Balancer /catalog /customers LB
  • 21.
    Distributed Locks • Coordinateoperations across several Service Instances • DB level locks are not enough • Implementations should provide Mutex, Semaphore, RWLock semantics e.g. Curator / Zookeeper Lock Service Server Server Server Catalog Catalog Lock /catalog/item/12a91kl Lock /catalog/item/09a9ab Unlock /catalog/item/09a9ab ….. Lock /catalog/item/ij98108 Unlock /catalog/item/ij98108 ….. Shared Work Queue
  • 22.
    Leader Election • Selectone service instance to perform a task • Good for lightweight scheduling of periodic tasks • Use different leaders for different functions • Run elections periodically • Nodes can join election at any point • If leader node goes away, a new leader is elected e.g. Curator / Zookeeper Leader Elector Server Server Server Catalog Catalog -> Elect /catalog/purge-> Elect /catalog/purge <- Take Leadership
  • 23.
    Distributed Workflows • Coordinateexecution of a set of tasks across services instances • Each task may be executed by a different services • Tasks may execute in parallel, and may have inter-dependencies Workflow Service Server Server Server e.g. AWS SWS, NirmataOSS Workflow Catalog Catalog
  • 24.
  • 25.
    Summary 1. Microservices enableagility at scale 2. Microservices push complexity into the platform 3. Microservices require operations tooling and distributed programming skills
  • 26.
    Related Sessions Come tryit live @ DevNet Cloud POD #3 DEVNET-1170 - Intercloud Microservices with Docker and Nirmata Thursday, Jun 11, 11:00 AM - 11:30 AM, DevNet Theater DEVNET-1137 - Application Centric Microservices Wednesday, Jun 10, 3:00 PM - 4:00 PM. DevNet Theater DEVNET-2013 - DevOps In Depth - Adrian Cockroft on Fast Delivery Tuesday, Jun 9, 1:45 PM - 2:30 PM, DevNet Theater BRKDEV-1002 - What's Hot in Containers Thursday, Jun 11, 1:00 PM - 2:30 PM, 30B Upper Level
  • 27.
    References • Microservices :Building Services with the Guts on the Outside, Gary Oliffe, http://blogs.gartner.com/gary-olliffe/2015/01/30/microservices-guts-on-the- outside/ • Migrating to Cloud Native with Microservices, Adrian Cockroft http://www.slideshare.net/adriancockcroft/qcon-new-york-speed-and-scale • Microservices: Decomposing Applications for Deployability and Scalability, Chris Richardson, http://www.infoq.com/articles/microservices-intro • Microservices, James Lewis and Martin Fowler, http://martinfowler.com/articles/microservices.html • Cloud native software: Microservices, Jim Bugwadia http://nirmata.com/2014/07/cloud-native-software-microservices/
  • 28.
  • 30.
    Other Interesting Patterns •CQRS (Command Query Responsibility Segregation) Separate model updates from views http://martinfowler.com/bliki/CQRS.html • Bounded Context Keep different models independent http://martinfowler.com/bliki/BoundedContext.html • Event Sourcing Use events, with playback, to manage distributed state http://martinfowler.com/eaaDev/EventSourcing.html
  • 31.
    Single Sync • Eachuser call results in a single synchronous call • A user call spawns one or more Distributed Workflows • Workflow tasks update user state via APIs • Retries and failure recovery are built-in per tasks Client Gateway Service Orders Service Payment Service Message Queue 1. Place Order 2. Route Request 3. Validate & Commit 4. Publish {new order} 5. Handle Payment 6. Publish {payment update} 7. Update Order
  • 32.
    Rest Cache • Servicesare using REST APIs to communicate • Frequent fetching of data causes latencies • A local cache can reduce latencies • Async Messaging can update the cache Orders Service Catalog ServiceREST Message Queue Updates Updates Catalog Cache POST, PUT, DELETE