A typical mission-critical enterprise application is a large, complex monolith developed by large team. The velocity of software delivery is usually slow, and the team struggles to keep up with the demands of the business. Consequently, many enterprise applications are good candidates to be migrated to the microservice architecture. As you might expect, migrating to microservices requires an enterprise to tackle numerous technology-related challenges. But enterprises often encounter obstacles that have less to do with technology and more to do with strategy, process, and organization. Chris Richardson details several anti-patterns of microservices adoption that he’s observed while working with clients around the world. You’ll learn the challenges that enterprises often face and how to overcome them as well as how to avoid the potholes when escaping monolithic hell.

1. Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
@crichardson
chris@chrisrichardson.net
http://learn.microservices.io
Potholes in the road from monolithic
hell: microservices adoption anti-
patterns

2. @crichardson
About Chris
http://learn.microservices.io ctwsaconuk18

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

4. @crichardson
BUT an
enterprise
application is
typically a
large, complex
monolith
Development,
testing and
deployment is
slow and
painful

5. @crichardson
Escaping
monolithic
hell seems
like a
good idea
BUT…
Team
Team
Team
microservices.io

6. @crichardson
The road
from
monolithic
hell

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

8. @crichardson
Anti-pattern: Magic pixie dust

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

10. @crichardson
Deliver complex
software rapidly,
frequently and reliably
Process: DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous teams
Architecture:
microservices
Testability
Deployability
Enables
Autonomy
Application
has outgrown
its monolithic
architecture
Refactor to
microservices

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

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

13. @crichardson
Identify problems with application and
software delivery process and fix them
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

14. @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

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

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

17. @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

18. @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

19. @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

20. @crichardson
Anti-pattern:
Scattershot adoption

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

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

23. @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

24. @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

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

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

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

28. 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 design
Automated testing and CI
Domain-driven design
DevOps and Microservices
Crawl
Walk
Jog
Run
Fly

29. @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

30. @crichardson
Anti-pattern: Focussing on technology

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

32. @crichardson
Infrastructure
=
undifferentiated heavy lifting

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

34. @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
*

35. @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

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

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

38. @crichardson
Service per team
Service
Small, autonomous
team
Service
Service
Service & team mitosis

39. @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

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

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

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

43. @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

44. @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

45. @crichardson
@crichardson chris@chrisrichardson.net
https://learn.microservices.io
Thank you!
ctwsaconuk18
Meet the experts table
@ 10.15am today