Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability

@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

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

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

@crichardson
About Chris
Founder of a startup that is creating
an open-source/SaaS platform
that simpliﬁes the development of
transactional microservices
(http://eventuate.io)

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

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

Agenda
From monolith to microservices
Beneﬁts and drawbacks of microservices
Technical anti-patterns
No so technical anti-patterns

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

@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

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

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

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

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

@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

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

-ilities of small monoliths
Maintainability
Testability
Deployability
…
https://en.wikipedia.org/wiki/Non-functional_requirement
😄

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

@crichardson
Use the microservice
architecture

The microservice architecture is
an architectural style
that structures an application as a
set of services that are organized
around business capabilities

@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

@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

@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!

@crichardson
… The structure of a service
SLA
Telemetry
API
Telemetry: Metrics, exceptions
Externalized
conﬁguration
Logging
Distributed
tracing
Heath Check
endpoint

Beneﬁts of microservices
Improved maintainability
Each service is smaller and so
easier to understand and
change
Preserves modularity since a
service is a well-deﬁned 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

@crichardson
Deliver software
rapidly, frequently
and reliably
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy

@crichardson
Loosely coupled teams and
services
Order
Service
Orders
Team
Automated deployment pipeline
Source code repository
Kitchen
Service
Kitchen
Team
Delivery
Service
Delivery
Team
Working independently > 80% of the time

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

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

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

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

@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?

@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

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

@crichardson
Example of temporal coupling
Order
Service
Customer 
Service
GET /customer/id
availability =
availability(OrderService) x
availability(CustomerService) 😓
POST /order
* any synchronous IPC mechanism

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

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

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

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

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

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

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

Solution: Iceberg services
A service API should
encapsulate signiﬁcant
business functionality
API = small
Implementation = large
Bundle data and behavior
API
Implementation
DB
waterline

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

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

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

@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

@crichardson
Anti-patterns of microservices adoption
Magic pixie dust Microservices as the goal Scattershot adoption
Trying to ﬂy
before you can
walk
Focussing on
technology
The more the
merrier
Red ﬂag law

@crichardson
Anti-pattern: Magic pixie dust

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

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

@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
…

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

@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

@crichardson
Anti-pattern: microservices as the goal

@crichardson
Leadership announces a
microservices
transformation initiative
Bonus ∝#microservices

@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

@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

@crichardson
Anti-pattern:
Scattershot adoption

@crichardson
* Perhaps because leadership made it
everyone’s goal
Multiple teams independently
adopting microservices with
no coordination*

@crichardson
Duplication of effort, e.g. building
infrastructure for deployment pipelines
and runtime environments
Development teams might not have the
skills to build infrastructure

@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

@crichardson
Anti-pattern: Trying to
ﬂy before you can walk

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

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

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

@crichardson
Anti-pattern: Focussing on
technology

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

@crichardson
Infrastructure
=
undifferentiated heavy lifting

@crichardson
Big upfront investment
=
Decision made without experience

@crichardson
Focus on the essence of microservices:
service decomposition and deﬁnition
Build just enough infrastructure
* Avoid buying that $$$ infrastructure until you know
you need it
*

@crichardson
Anti-pattern: The more the merrier

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

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

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

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

@crichardson
Disappointment
Fewer beneﬁts of using
microservices
Business might view the migration
effort as a failure

@crichardson
Improve process, organization, and
architecture
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy
Deliver complex
software rapidly,
frequently and
reliably

@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

@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

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

Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability

Recommended

More Related Content

What's hot (20)

Similar to Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability (20)

More from Chris Richardson (20)

Recently uploaded (20)

Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability