This document discusses common anti-patterns that organizations face when adopting a microservices architecture. It describes the "Magic Pixie Dust" anti-pattern of believing microservices alone will solve development problems without addressing underlying issues like code quality or deployment processes. It also discusses treating microservices as a goal in itself rather than focusing on enabling rapid delivery, and the risks of a scattershot or premature adoption of microservices before teams have the necessary skills. The document emphasizes that infrastructure should not be the focus, and that the number of services should be optimized rather than maximized. It warns against making changes without adjusting organizational processes and policies to support the new architecture.
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
Quantifying rapid, frequent
and reliable delivery
Velocity
Lead time - time from commit to deploy
Deployment frequency - deploys per developer per day
Reliability
Mean time to recover from a deployment failure
Change failure rate - % of deployments that cause an
outage
15. @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
17. -ilities of small monoliths
Maintainability
Testability
Deployability
…
https://en.wikipedia.org/wiki/Non-functional_requirement
😄
18. But eventually you end up in
monolithic hell
Application becomes extremely large => a big ball of
mud
Rapid, frequent and reliable delivery becomes
impossible
Technology stack becomes increasingly obsolete BUT
a rewrite is not feasible
20. The microservice architecture is
an architectural style
that structures an application as a
set of services that are organized
around business capabilities
21. @crichardson
Food to Go: Microservice
architecture
Browser
Mobile
Application
Content
Router
API
Gateway
Order
Service
Restaurant
Service
Delivery
Service
…
Service
Order
Database
Restaurant
Database
Delivery
Database
…
Database
HTTP
/HTML
REST
REST
Browse &
Search WebApp
Restaurant
Detail WebApp
….
JavaScript
22. @crichardson
A well-designed microservice
Highly maintainable and testable
Minimal lead time
high deployment frequency
Loosely coupled
independently deployable
Implements a business capability
Developed by a small team
23. @crichardson
API
The structure of a service…
Operations
Event
Publisher
Commands
Queries
Synchronous
REST/gRPC
Asynchronous
Messaging
Events
Event
Subscriber
API
Client
Invokes
Operations
Events
Service
Database
Private!
24. @crichardson
… The structure of a service
SLA
Telemetry
API
Telemetry: Metrics, exceptions
Externalized
configuration
Logging
Distributed
tracing
Heath Check
endpoint
25. Agenda
From monolith to microservices
Benefits and drawbacks of microservices
Technical anti-patterns
No so technical anti-patterns
26. Benefits of microservices
Improved maintainability
Each service is smaller and so
easier to understand and
change
Preserves modularity since a
service is a well-defined module
with an impermeable API
Improved testability:
Each service is small and so is
easier to test
Improved deployability
Each service can be deployed
independently
Easier to scale application
Improves fault isolation
Easier to experiment with new
technologies and evolve the
technology stack
28. @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. Challenging to implement
features that span services
Requires coordination and
planning across teams
If it happens frequently:
Distributed monolith?
Reconsider
decomposition
Service
A
Service
B
Service
C
Change
Team
A
Team
B
Team
C
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?
34. @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
35. Agenda
From monolith to microservices
Benefits and drawbacks of microservices
Technical anti-patterns
No so technical anti-patterns
36. Problem:
Developers treat services as if they are programming
language-level modules (that communicate via HTTP)
Consequences:
IPC is relatively expensive => high latency
Synchronous communication => temporal coupling
=> reduced availability
Anti-pattern: Distribution is
free
37. @crichardson
Example of temporal coupling
Order
Service
Customer
Service
GET /customer/id
availability =
availability(OrderService) x
availability(CustomerService) 😓
POST /order
* any synchronous IPC mechanism
39. Solution: self contained
services
Service that handles a synchronous request without needing response
from any other service
Synchronous request initiates saga OR Service has a replica of another
services data
Order
Service
Customer
Service
POST /order
Order created
Customer Validated
40. Anti-pattern: Shared
database
Problem:
A database table is accessed by multiple services/monolith
e.g Customer Service accesses the Order table
Consequences:
Changing Order table is no longer easy => requires coordination across
teams
Customer Service updates table => impossible to reason about Order
Service in isolation
Services are no longer isolated at runtime
45. Solution: Iceberg services
A service API should
encapsulate significant
business functionality
API = small
Implementation = large
Bundle data and behavior
API
Implementation
DB
waterline
48. Segment’s distributed
monolith
Segment routes messages
from customers to destinations
A service per destination
BUT
Common transformation logic,
e.g. event.name()
Change shared library =>
redeploy all services
Compounded by lack of
automated deployment
Service A
Library
Queue
Service B
Library
Queue
Service …
Library
Queue
Change
49. @crichardson
Avoiding the distributed
monolith anti-pattern
Apply the Common Closure Principle (CCP)
Things that change together should be packaged together
e.g. Segment could use a pre-processor that canonicalizes
event.name()
Understand the domain and how it evolves
Requires a crystal ball BUT the past can be a guide
50. Agenda
From monolith to microservices
Benefits and drawbacks of microservices
Technical anti-patterns
No so technical anti-patterns
51. @crichardson
Anti-patterns of microservices adoption
Magic pixie dust Microservices as the goal Scattershot adoption
Trying to fly
before you can
walk
Focussing on
technology
The more the
merrier
Red flag law
55. @crichardson
Common obstacles to rapid, frequent
and reliable software delivery
Slow, silo’ed, manual development, testing and deployment
process
Applications are big balls of mud
Stinky code
Duplicate code bases
…
57. @crichardson
Identify problems with
application and software
Slow, silo’ed, manual deployment pipeline DevOps: small
autonomous teams, automated deployment pipeline, etc.
Stinky code learn how to write clean code and enforce code
quality
Duplicate code bases combine and design extension points
…
Application is a big ball of mud rearchitect, maybe to
microservices
60. @crichardson
High-level support is essential
BUT…
Ignores other obstacles to rapid, frequent and reliable software
delivery
Process - waterfall process, manual testing, manual
deployment
Organization - silo’d teams
Software - big ball of mud, stinky code, …
Imposes an architecture on teams even when it does not make
sense
Teams might not understand the goal
61. @crichardson
Better goal: rapid, frequent
and reliable software delivery
Key metrics to track and improve:
Lead time - time from commit to deploy
Deployment frequency - number of deploys per day
Failure rate - how often deployments fail
Recovery time - time to recover from an outage
Application teams decide how to improve these metrics
63. @crichardson
* Perhaps because leadership made it
everyone’s goal
Multiple teams independently
adopting microservices with
no coordination*
64. @crichardson
Duplication of effort, e.g. building
infrastructure for deployment pipelines
and runtime environments
Development teams might not have the
skills to build infrastructure
65. @crichardson
Microservices
adoption
strategy
Define and communicate
strategy
Select candidate
monolith
Create infrastructure team
Define service and
team
Learn, document
and share
Expand to other
applications
Strangle the monolith
Establish key metrics:
Lead time, deployment frequency, …
Capable, motivated team
Technically a good fit
Able to generate short term wins
Refine infrastructure
Deployment pipeline
Runtime environments
69. Solution
Assess skill level of each
developer and team
Establish training etc.
program to improve skills
Re-evaluate whether you
still need the microservice
architecture
Clean code
Object-oriented
Automated testing
Domain-driven
DevOps and
Crawl
Walk
Jog
Run
Fly
71. @crichardson
Seriously cool technology 😎
+
vendors telling you to buy their cool stuff
Organizations focus on infrastructure not
application architecture
74. @crichardson
Focus on the essence of microservices:
service decomposition and definition
Build just enough infrastructure
* Avoid buying that $$$ infrastructure until you know
you need it
*
83. @crichardson
Summary
The Microservice architecture enables the rapid, frequent and
reliable of large, complex applications
It’s not a silver bullet or panacea
Make sure you have mastered the basics: e.g. automated testing
Focus on accelerating, reliable software delivery
Adopting the microservice architecture requires you to change
your process, policies and organization
Start simple and grow incrementally