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.

1. @crichardson
Microservices adoption anti-
patterns: obstacles to decomposing
for testability and deployability
Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of Microservices Patterns and POJOs in Action
@crichardson
chris@chrisrichardson.net
http://learn.microservices.io
Copyright © 2019. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson
Presentation goal
Essential characteristics of the
microservice architecture
And
adoption anti-patterns

3. @crichardson
About Chris

4. @crichardson
About Chris
Consultant and trainer
focussed on helping
organizations adopt the
microservice architecture
(http://www.chrisrichardson.net/)

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)

6. @crichardson
About Chris
https://microservices.io/book
40% discount with code
ctwmelmsajan19

7. About Chris: microservices.io
Microservices pattern
language
Articles
Code examples
Microservices Assessment
Platform - http://
microservices.io/platform

8. Agenda
From monolith to microservices
Benefits and drawbacks of microservices
Technical anti-patterns
No so technical anti-patterns

9. @crichardson
+
Businesses must innovate faster
Software
Deliver software
rapidly, frequently
and reliably

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

11. @crichardson
Deliver software
rapidly, frequently
and reliably
Process: DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous teams
Architecture: ???

12. @crichardson
Application architecture
must enable
rapid, frequent and reliable delivery

13. Required architectural
quality attributes (-ilities)
https://en.wikipedia.org/wiki/Non-functional_requirement
Development
velocity
Maintainability
Testability
Deployability

14. @crichardson
Let’s imagine that you are
building a cool new food
delivery application….

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

16. @crichardson
The monolithic architecture
is an architectural style
that structures the application
as a single executable
component
Implementation view

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

19. @crichardson
Use the microservice
architecture

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

27. @crichardson
Deliver software
rapidly, frequently
and reliably
Process: DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy

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

29. @crichardson
Modern software development: moving
fast and not breaking things!
46x
440x
24x
5x lower
Amazon: ~0.001%
Netflix: 16 minutes
Amazon: every 11.6 seconds

30. @crichardson
http://en.wikipedia.org/wiki/Fred_Brooks

31. @crichardson
Drawbacks of microservices
Complexity
Development: IPC, partial failure, distributed data
Testing: Integration, end to end, …
Deployment
…

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

38. Solution: careful interaction
design
Carefully consider how your services interact
Coarse-grained interactions
Preferably asynchronous

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

41. Solution: database per
service
Each table is only accessed by a single service
Services collaborate only through APIs

42. Anti-pattern:
Unencapsulated service
Problem:
Service has a large API that encapsulates very little
Consequences:
Service API is frequently changing incompatibly
forcing consumers to upgrade
Defeats the purpose of microservices

43. Example
Entity Service
Thin wrapper around a database
CRUD operations
Change schema => change API

44. @crichardson
Solution: encapsulation
Hide as much of the implementation as possible
Prevents changes from impacting consumers => loosely
coupled teams

45. Solution: Iceberg services
A service API should
encapsulate significant
business functionality
API = small
Implementation = large
Bundle data and behavior
API
Implementation
DB
waterline

46. Anti-pattern: Distributed
monolith
Problem:
Two or more services implement the same concept
Consequences
Must change in lock step

47. @crichardson
https://segment.com/blog/goodbye-microservices/

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

52. @crichardson
Anti-pattern: Magic pixie dust

53. @crichardson
Believing a sprinkle of
microservices will solve
your development problems

54. @crichardson
The Microservice architecture
solves the problem of how to
accelerate the development of a
large complex application

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
…

56. @crichardson
Migrate to microservices
Disappointment
The problems remain
or
Get worse!
* Flying before you can walk anti-pattern
*

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

58. @crichardson
Anti-pattern: microservices as the goal

59. @crichardson
Leadership announces a
microservices
transformation initiative
Bonus ∝#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

62. @crichardson
Anti-pattern:
Scattershot adoption

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

66. @crichardson
Anti-pattern: Trying to
fly before you can walk

67. @crichardson
A organization attempts microservices
while lacking key skills, e.g.
clean code
object-oriented design
automated testing
…

68. @crichardson
Migrate to microservices
Disappointment
Development problems remain
or
Get worse!

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

70. @crichardson
Anti-pattern: Focussing on
technology

71. @crichardson
Seriously cool technology 😎
+
vendors telling you to buy their cool stuff
Organizations focus on infrastructure not
application architecture

72. @crichardson
Infrastructure
=
undifferentiated heavy lifting

73. @crichardson
Big upfront investment
=
Decision made without experience

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
*

75. @crichardson
Anti-pattern: The more the merrier

76. @crichardson
Planning to have a large number of
services
Risk of unnecessary complexity
Risk that changes impact
numerous services

77. @crichardson
Service per team
Service
Small, autonomous
team
Service
Service
Service & team

78. @crichardson
Anti-pattern:
Walking in front
with a red flag
https://www.dedionboutonclub.co.uk/imperial_institute_page1.html
Anti-pattern:
Red flag law

79. @crichardson
Adopting microservices without
changing process, policies and
organization
Silo’d teams
Manual testing
Monthly deploys at midnight
…

80. @crichardson
Disappointment
Fewer benefits of using
microservices
Business might view the migration
effort as a failure

81. @crichardson
Improve process, organization, and
architecture
Process: DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy
Deliver complex
software rapidly,
frequently and
reliably

82. @crichardson
Do it incrementally!
Monolith
Time
Monolith
Service
Monolith
Service
Service
Monolith
Service
Service
Service
Service
…. Monolith
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
Service
….
Strangler application
The strangler application grows larger over time
The monolith shrinks over time
Legacy process
and organization
Devops, small,
autonomous
teams, etc

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

84. @crichardson
@crichardson chris@chrisrichardson.net
http://learn.microservices.io
Questions?
40% discount with code
ctwmelmsajan19