Successful applications have a habit of growing. What’s more, the rate of growth increases over time because the development team typically gets larger. Eventually, the application will become extremely large and the organization ends up in monolithic hell. All aspects of development, testing and deployment are slow and painful. It’s impossible for the developers to keep up with the demands of the business. And, to make matters worse the application uses a technology stack that is increasingly obsolete. The way to escape monolithic hell is to migrate to the microservice architecture.
In this talk, you will learn about the essential characteristics of microservices. I describe the benefits and drawbacks of the microservice architecture and when it makes sense to use it. You will learn about the design problems you will encounter when using microservices. I describe how to solve this problems by applying the microservices pattern language. You will learn how the microservice architecture accelerates the delivery of large, complex applications.
Given at Silicon Valley Code Camp 2018
5. @crichardson
About Chris
Founder of a startup that is creating
an open-source/SaaS platform
that simplifies the development of
transactional microservices
(http://eventuate.io)
10. @crichardson
Tomcat/App. Server
Food To Go: Monolithic
architecture
Browser/
Client
WAR/EAR
MySQL
Database
Delivery
management
Order
Management
Kitchen
Management
Web UI
Restaurant
Management
HTML
REST/JSON
The application
19. @crichardson
Application
Business capability Service
Food to Go
Order
Taking
Kitchen
management
Delivery
management
Business Capability = something a business does to deliver value
…
Order
Service
Kitchen
Service
Delivery
Service
…
Service
21. @crichardson
Service = independently
deployable component
Command
Query
API
Event
Publisher
Event
Subscriber
API
Client
Consumer facing Implementation
Synchronous:
REST, gRPC, …
Asynchronous:
Command/Reply, Notification
Service database
Events
Events
Synchronous:
REST, gRPC, …
Asynchronous:
Command/Reply, Notification
Data owned by the service
Data replicated from elsewhere
SLA
23. @crichardson
Loosely coupled teams and
services
Order
Service
Orders
Team
Automated deployment pipeline
Source code repository
Kitchen
Service
Kitchen
Team
Automated deployment pipeline
Source code repository
Delivery
Service
Delivery
Team
Automated deployment pipeline
Source code repository
Working independently > 80% of the time
32. @crichardson
Do I have the skills/pre-requisites in place:
automated testing
automated provisioning
….. ?
33. @crichardson
When using microservices:
How to decompose an application into services?
How to deploy an application’s services?
How to handle cross cutting concerns?
Which communication mechanisms to use?
How do external clients communicate with the services?
How does a client discover the network location of a service instance?
How to prevent a network or service failure from cascading to other services?
How to maintain data consistency and implement queries?
How to make testing easier?
How to understand the behavior of an application and troubleshoot problems?
How to implement a UI screen or page that displays data from multiple services?
40. @crichardson
Microservices pattern language: http://microservices.io
Splitting Reassembling
Operations
Architecture
Microservice patterns
Data patterns
Communication patterns
Application
architecture
Cross-cutting concerns Security
Deployment
Maintaining data consistency
External API
Reliability
Discovery
Transactional
messaging
Testing
Observability
UI
Decomposition
Database architecture
Querying
Communication style
API gateway
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Messaging
Remote Procedure
Invocation
Database per
Service
Saga
Shared
database
Microservice
Chassis
Backend for front end
Event
sourcing
Aggregate
Monolithic
architecture
Microservice
architecture
Motivating
Pattern
Solution
Pattern
Solution A Solution B
General Specific
Serverless
deployment
Circuit BreakerAccess Token
Domain-specific
Externalized
configuration
Consumer-driven
contract test
Service
Component Test
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API
Service deployment
platform
Server-side page
fragment
composition
Client-side UI
composition
Decompose by
business capability
Decompose by
subdomain
CQRS
Transaction
log tailing
Transactional
Outbox
Polling
publisher
API
Composition
Domain event
Consumer-side
contract test
Sidecar
Service mesh
Application
patterns
Infrastructure patterns
Application Infrastructure patterns
Log deployments and changes
41. @crichardson
The pattern language guides you
when developing an architecture
What architectural decisions you must make
For each decision:
Available options
Trade-offs of each option
43. Issue: What’s the deployment
architecture?
Forces
Maintainability
Deployability
Testability
…
Monolithic
architecture
Microservice
architecture
Single deployable/
executable OR
Tightly coupled services
Multiple loosely coupled
services
44. Issue: How to decompose an
application into services?
Forces
Stability
Cohesive
Loosely coupled
Not too large
Decompose by
business capability
Decompose by
subdomain
Organize around
business capabilities
Organize around DDD
subdomains
45. @crichardson
Issue: how to maintain data
consistency?
Context
• Each service has its own
database
• Data is private to a service
Forces
Transactional data consistency
must be maintained across
multiple services
2PC is not an option
46. @crichardson
Issue: how to perform
queries?
CQRS
Context
Each service has its own
database
Forces
Queries must join data
from multiple services
Data is private to a service
Maintain query views by
subscribing to events
API
Composition
47. @crichardson
Issue: what external API to
expose?
Context
One or more clients access the
application’s API
Forces
Different clients need different data
Different clients use different networks
Mismatch between client’s needs and
fine-grained service APIs
Application architecture must evolve
without impacting clients
Services might use protocols that are
not web friendly
API gateway
Backend for front end
48. @crichardson
Issue: how to test that services
collaborate?
Context
Application consists of
multiple collaborating
services
Forces
Services collaborate and
must agree on APIs
End-to-end tests are slow,
brittle, and expensive and
best avoided
Client Service
Contract
defines
Consumer-
side contract
test
Tests
Uses
Consumer-
driven
contract test
Tests
Uses
50. @crichardson
Issue: How do services
communicate?
Messaging
Remote Procedure
Invocation
Domain-specific
Forces
Services must
communicate
Usually processes on
different machines
…
51. @crichardson
Issue: How to handle cross
cutting concerns?
Microservice
Chassis
Forces
Every service must
implement logging;
externalize configuration;
health check endpoint;
metrics; …
52. Issue: How to deploy an
application’s services?
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Serverless
deployment
Service deployment
platform
Forces
Multiple languages
Isolated
Constrained
Monitor-able
Reliable
Efficient
53. @crichardson
Issue: How to discover a service
instance’s network location?
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Forces
Client needs IP address of
service instance
Dynamic IP addresses
Dynamically provisioned
instances
54. @crichardson
Issue: how to monitor the
behavior of your application?
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API
55. @crichardson
Summary
The goal of architecture is to satisfy non-functional
requirements: deployability, testability, …
To enable DevOps/continuous delivery/deployment use the
appropriate architectural style
Small applications Monolithic architecture
Complex applications Microservice architecture
Use the pattern language to guide your decision making