When architecting an enterprise Java application, you need to choose between the traditional monolithic architecture consisting of a single large WAR file, or the more fashionable microservices architecture consisting of many smaller services. But rather than blindly picking the familiar or the fashionable, it's important to remember what Fred Books said almost 30 years ago: there are no silver bullets in software. Every architectural decision has both benefits and drawbacks. Whether the benefits of one approach outweigh the drawbacks greatly depends upon the context of your particular project. Moreover, even if you adopt the microservices architecture, you must still make numerous other design decisions, each with their own trade-offs.
A software pattern is an ideal way of describing a solution to a problem in a given context along with its tradeoffs. In this presentation, we describe a pattern language for microservices. You will learn about patterns that will help you decide when and how to use microservices vs. a monolithic architecture. We will also describe patterns that solve various problems in a microservice architecture including inter-service communication, service registration and service discovery.
Powering Real-Time Decisions with Continuous Data Streams
Decompose that WAR? A pattern language for microservices (@QCON @QCONSP)
1. @crichardson
Decompose that WAR!
A pattern language for
microservices
Chris Richardson
Author of POJOs in Action
Founder of the original CloudFoundry.com
@crichardson
chris@chrisrichardson.net
http://plainoldobjects.com
http://microservices.io
9. @crichardson
Suck/Rock Dichotomy
Spring vs. Java EE
JavaScript vs. Java
Functional programming vs. Object-oriented
http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html
Containers vs. Virtual Machines
15. @crichardson
The structure of a pattern
Resulting context
aka the situation
Name
Context
Problem
Related patterns
(conflicting) issues
etc to address
Forces
Solution
18. Pattern language
A collection of related
patterns that solve problems
in a particular domain
Relationships
Pattern A results in a
context that has a problem
solved by Pattern B
Patterns A and B solve the
same problem
Pattern A is a
specialization of pattern B
http://en.wikipedia.org/wiki/A_Pattern_Language
Access to Water
Promenade
Local townhall
Intimacy gradient
Light on two sides
19. @crichardson
Meta-pattern
Problem: How to talk/reason about technology?
Solution: Use the pattern format
Benefit: More objective
Drawback: Less exciting
Context: Emotional software development culture
Related patterns: It’s awesome!
23. @crichardson
Let’s imagine you are
building an online store
Browser/
Client
SQL
Database
Review Service
Product Info
Service
Recommendation
Service
StoreFrontUI
Order Service
HTML
REST/JSON
25. @crichardson
Forces
There is a team of developers that must be productive
The application must be easy to understand and modify
Do continuous deployment
Run multiple instances for scalability and availability
Use emerging technologies (frameworks, programming
languages, etc)
30. @crichardson
Obstacle to frequent
deployments
Need to redeploy everything to change one component
Interrupts long running background (e.g. Quartz) jobs
Increases risk of failure
Fear of change
Updates will happen less often - really long QA cycles
e.g. Makes A/B testing UI really difficult
Eggs in
one basket
32. @crichardson
Lots of coordination and
communication required
Obstacle to scaling
development
I want to update
the UI
But
the backend is not working
yet!
36. @crichardson
Product Info
Microservice architecture
Product Info
Service
Recommendation
Service
Review
Service
Order
Service
Browse Products
UI
Checkout UI
Order management
UI
Account
management UI
Apply X-axis and Z-axis scaling
to each service independently
38. @crichardson
Benefits
Smaller, simpler apps
Easier to understand and develop
Less jar/classpath hell - who needs OSGI?
Faster to build and deploy
Scales development: develop, deploy and scale each service independently
Improves fault isolation
Eliminates long-term commitment to a single technology stack
System level architecture vs. service level architecture
Easily and safely experiment with new technologies
39. @crichardson
Drawbacks
Complexity of developing a distributed system
Implementing inter-process communication
Handling partial failures
Implementing business transactions that span multiple databases
(without 2PC)
Complexity of testing a distributed system
Complexity of deploying and operating a distributed system
Managing the development and deployment of features that span
multiple services
Fortunately solutions exists
41. @crichardson
Issues to address
How to deploy the services?
How do the services communicate?
How do clients of the application communicate with the
services?
How to partition the system into services?
….
44. @crichardson
Forces
Services are written using a variety of languages, frameworks, and
framework versions
Each service consists of multiple service instances for throughput and
availability
Building and deploying a service must be fast
Service must be deployed and scaled independently
Service instances need to be isolated
Resources consumed by a service must be constrained
Deployment must be cost-effective
51. Benefits and drawbacks
Benefits
Great isolation
Great manageability
VM encapsulates
implementation technology
Leverage AWS
infrastructure for
Autoscaling/Load balancing
Drawbacks
Less efficient resource
utilization
Slow deployment
52. @crichardson
VM
VM
Pattern: Service per Container
host
Service
Container
image
Container
Service
Container
Service
Container
Service
packaged as
deployed as
54. Benefits and drawbacks
Benefits
Great isolation
Great manageability
Container encapsulates
implementation technology
Efficient resource utilization
Fast deployment
Drawbacks
Immature infrastructure for
deploying containers
59. @crichardson
Forces
Mismatch between the fine-grained microservices and needs
of the clients
Different clients need different data
LAN vs. WAN vs. Mobile network performance
The number of service instances and their locations (host
+port) is changes dynamically
Partitioning into services can change over time and should be
hidden from clients
60. @crichardson
Directly connecting the front-end to the backend
Model
View Controller
Product Info
service
Recommendation
Service
Review
service
REST
REST
Thrift
Model
View Controller
Browser/Native App
Traditional server-side
web application
Chatty API
Web unfriendly
protocols
What’s the host/port??
61. @crichardson
Pattern: API gateway
Model
View Controller
Product Info
service
Recommendation
Service
Review
service
REST
REST
Thrift
API
Gateway
Model
View Controller
Browser/Native App
Single entry point
Client
specific APIs
Protocol
translation
Traditional server-side
web application
63. @crichardson
Benefits of the API gateway
Insulates the clients from the partitioning
Insulates the clients from the problem of discovery
Provides the optimal API for each client
Reduces the number of requests/roundtrips
Simplifies the client by moving logic for calling multiple
services from the client to API gateway
Gateway translates between web-unfriendly protocols and
HTTP/WebSockets
64. @crichardson
Drawbacks of the API
gateway
Increased complexity - the API gateway is yet another highly
available component that must be developed, deployed and
managed
Increased response time due to the additional network hop
through the API gateway
66. Benefits and drawbacks of
messaging
Benefits
Decouples client from
services
Message broker buffers
messages
Supports a variety of
communication patterns
Drawbacks
Additional complexity of
message broker
Request/reply-style
communication is more
complex
Client needs to discover
location of message
broker
67. Benefits and drawbacks of
RPC
Benefits
Simple and familiar
Request/reply is easy
No intermediate broker
Drawbacks
Only supports request/
reply
Service must be
available
Client needs to discover
locations of service
instances
69. @crichardson
The problem of discovery
Service
Client
Service
Instance A
Service
Instance B
Service
Instance C
?
10.4.3.1:8756
10.4.3.99:4545
10.4.3.20:333
Client or API
gateway
Dynamically
changing
Service
Instance A
Service
Instance B
Service
Instance C
10.4.3.1:8756
10.4.3.99:4545
10.4.3.20:333
How to load
balance?
Dynamically
assigned
72. Benefits and drawbacks
Benefits
Flexible, application-specific
load balancing
Fewer network hops and
moving parts compared to
Server-side discovery
Drawbacks
Couples the client to the
Service Registry
Need implement client-side
discovery and load balancing
logic in multiple languages/
frameworks
Service Registry is yet
another moving part to setup
and operate - highly available
75. Benefits and drawbacks
Benefits
Simpler client code
Built-in to some cloud/
container environments, e.g.
AWS ELB, Kubernetes,
Marathon
Drawbacks
Limited to (generic) load
balancing algorithms
provided by router
More network hops
Router and Service Registry
is yet another moving part
to setup and operate -
highly available
76. @crichardson
The problem of registration
Service
Registry
Service
Instance A
Service
Instance B
Service
Instance C
10.4.3.1:8756
10.4.3.99:4545
10.4.3.20:333
register
How does registration
happen?
78. @crichardson
Forces
Service instances must be
registered with the service registry on startup
unregistered on shutdown
Service instances that crash must be unregistered from the
service registry
Service instances that are running but incapable of handling
requests must be unregistered from the service registry
80. @crichardson
Examples
Netflix Eureka Java client
API for registering/unregistering with Eureka server
Specify state: STARTING, UP, DOWN, OUT_OF_SERVICE
Register a periodically invoked health check callback
Zookeeper-based Java applications
Service = znode
Service instance = ephemeral child of znode
81. Benefits and drawbacks
Benefits
Simple - no extra
components
Service can implement a
more sophisticated state
model
Drawbacks
Couples the service to
service registry
Must implement registration
logic in multiple languages/
frameworks
Service might lack the self-
awareness to unregister
itself
82. @crichardson
Pattern: 3rd party registration
Service
Registry
Service
Instance A
10.4.3.1:8756
register
heart-beat
unregister
Registrar
healthcheck
83. @crichardson
Examples
AWS Autoscaling groups
Automatically register/unregister EC2 instance with ELB
Registrator
Registers and unregisters Docker containers with service registry
Kubernetes/Marathon
Automatically register/unregister services
Netflix Eureka Prana
Sidecar application for non-Java clients
Registers/unregisters service with Eureka
Performs health checks
84. Benefits and drawbacks
Benefits
Simpler service
Registrar can perform health
checks
Some cloud/container
environments provide a
Registrar
Drawbacks
Registrar is yet another
component that must be
setup/operated. Must be
highly available