The document discusses the pros and cons of using microservices architecture. It notes that microservices introduce more complexity, including issues with API evolution, error handling, distributed tracing, and deployment. It recommends starting with a monolith and adopting microservices gradually, after establishing continuous delivery capabilities. Microservices may be worthwhile for large teams, shared services, isolated new functionality, or very high load apps, but the document warns of risks from operational complexity if prerequisites and culture are not in place.

1. The Case Against Microservices
Leeds DevOps
Feb 2019
Aled Sage

2. What are Microservices?
Dave Kerr, https://dwmkerr.com/the-death-of-microservice-madness-in-2018/

3. What are Microservices?
* Loosely coupled service oriented architecture
with bounded contexts
If you have to know too much
about surrounding services, you don’t
have a bounded context
If many services have to be
updated at the same time,
it’s not loosely coupled

4. Is it Microservices?
MicroserviceMonolith

5. When are Microservices Right?
Great idea!Terrible idea!
Grey:
Many considerations

6. Example Microservices
Adrian Cockcroft, Migrating to Microservices
Don’t try
this
at hom
e

7. What are the Goals?
* Deploy things faster
* Get new features out quicker
* Control scaling

8. What to improve
* Be metrics-driven…
* Biggest pain points?
* What are microservices
solving?
* At what cost?
* https://xkcd.com/1319/

9. Write Better Systems

10. Write Better Systems

11. Write Better Systems

12. Write Better Systems

13. Write Better Systems

14. Write Better Systems
Caption contest: DRY (Don’t repeat yourself)
Blast radius?

15. Why this talk?
* Help address the balance of talks!
* https://speakerdeck.com/paddycarey/from-monolith-to-
microservices-and-back-again-twice

16. Getting Started
* Always start with a monolith
* https://martinfowler.com/bliki/MonolithFirst.html
Did you get the bounded
contexts right?!
Make refactoring easy!

17. Getting Started
* Write well-structured modular code
* What well-understood stack works for you?
* e.g. app-servers + redis + postgres
* Stateless
* What does your team know well?

18. Getting Started

19. Before Considering Microservices
* Microservice Prerequisites
* https://martinfowler.com/bliki/MicroservicePrerequisites.html

20. Before Considering Microservices
* Become great at deploy/rollback of your “monolith”
* https://www.dibbern.biz/2017/07/30/the-colour-of-devops-continuous-delivery/

21. Before Considering Microservices
* Monitoring
* Automated recovery
*
* ca.com/cloud-monitoring

22. Benefits of microservices
* Benefits of microservices
* Agility
* Inovation
* Quality
* Scalability
* Availability
https://docs.aws.amazon.com/aws-technical-content/latest/microservices-on-aws/
benefits-of-microservices.html

23. Benefits of microservices well-written code
* Benefits of microservices well-written “monoliths”
* Agility
* Inovation
* Quality
* Scalability
* Availability

24. Benefits of microservices well-written code
* Inovation
Startups: undefined
product; it’s experimental
Evolving bounded
contexts

25. Microservices Introduce Complexity
* API evolution and backwards compatibility
I miss compile-time errors
I miss IDE refactoring
for internal APIs.

26. Microservices Introduce Complexity
* Error handling
* What timeouts, what retries
* e.g. circuit breaker pattern
* e.g. Envoy (AWS App Mesh)
Com
plexity!

27. Microservices Introduce Complexity
* Distributed tracing of transactions
* Rollback / checkpoint?
* Debugging
Com
plexity!

28. Microservices Introduce Complexity
* More to be deployed / managed
Com
plexity!
* Service discovery

29. Fallacies of Distributed Computing
* The network is reliable.
* Latency is zero.
* Bandwidth is infinite.
* The network is secure.
* Topology doesn't change.
* There is one administrator.
* Transport cost is zero.
* The network is homogeneous.
The more distributed,
the more these will affect you

30. Reliability
* “Simplistic” implementation:
* More instances involved in each request
* More likely upgrade/rollback leads to incompatible APIs
* “Complex” implementation:
* needed to get benefits

31. Operational Risk
* Have you written a 3-tier web-app before?
* Have you operated / upgraded a 3-tier web-app
many times before?
* Have you written a microservices architecture before?
* Have you operated / upgraded a microservices
architecture many times before?
Low risk
Low/medium risk
High risk
Very high risk

32. Use well-understood approaches
* Beginnings of trend at conferences:
* Don’t do something just because
it works for unicorns
* Don’t underestimate cost of learning new things
* Use well understood technologies
* Don’t change too much at once
(incremental improvements)
Don’t

33. * Different teams work on different parts of
the product
* Different languages, "best tool for the job”
* Upgrade microservices independently
* Different teams work on different parts of
the product
* Different languages, "best tool for the job”
* Upgrade microservices independently
Why would I use Microservices
Really?!
Really?!
Really?!

34. * Pre-requisites:
* Start with a “monolith”
* CI/CD
* Monitoring
* Automated recovery
* Organisation’s structure/culture can handle it
* Adopt microservices gradually
Why Would I Actually Use Microservices?

35. * Many developers
* e.g. > 50?
Platformmaintenance
costperperson
#devs
Microservices
Monolith
Why Would I Actually Use Microservices?
* Shared service
* Using 3rd party services

36. Why Would I Actually Use Microservices?
* Adding very specific (isolated) functionality
* e.g. Lambda to generate different sized images, on upload
* Separation for security/compliance/batch-processing
* e.g. write to SQS for billing purposes

37. Why Would I Actually Use Microservices?
* Very high-load apps:
* separation to optimise/scale better (e.g. needs GPUs)
* Different languages, when big benefits
* e.g. team more skilled in different language than legacy app

38. Why Would I Actually Use Microservices?
* Dependency hell
* e.g. offering different versions of app for backwards
compatibility
* Unmaintainable legacy systems?!

39. Beware complexity

40. Resources
* Monolith First
* https://martinfowler.com/bliki/MonolithFirst.html
* Microservice Prerequisites
* https://martinfowler.com/bliki/MicroservicePrerequisites.html
* The Death of Microservice Madness in 2018
* https://dwmkerr.com/the-death-of-microservice-madness-in-2018/
* It’s time to stop making “Microservices” the goal of modernization
* https://medium.com/@rbarcia/its-time-to-stop-making-microservices-the-goal-of-
modernization-71758b400287
* When not to use microservices
* https://www.feval.fr/posts/microservices/
* Failing at Microservices. Please avoid our mistakes!
* https://rclayton.silvrback.com/failing-at-microservices
* Goodbye Microservices: From 100s of problem children to 1 superstar
* https://segment.com/blog/goodbye-microservices/
* From monolith to microservices and back again, twice
* https://speakerdeck.com/paddycarey/from-monolith-to-microservices-and-back-again-twice?slide=2

41. The End