Downloaded 10 times
Uploaded byBert Ertman
Microservices Gone Wrong!
Microservices are a software architecture style that enables the development of independently deployable services, promoting business agility and modularization. However, their successful implementation depends on organizational capabilities and cross-functional teams, as well as the strategic use of cloud technologies and continuous deployment practices. Misapplication of microservices can lead to costly challenges and operational nightmares, making their adoption unsuitable for every organization.
![20260201 [FOSDEM] gomodjail - library sandboxing for Go modules.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/20260201fosdemgomodjail-librarysandboxingforgomodules-260201225659-76609ec4-thumbnail.jpg?width=640&height=640&fit=bounds)
Microservices Gone Wrong!
- 1. by Bert Ertman Thosewho stand for nothing, fall for anything - Alexander Hamilton Microservices Gone Wrong! @BertErtman
- 2. • Fellow, Directorof Technology Outreach at Luminis • Background in all things Java since 1995 • Java Champion, JavaOne Rockstar Speaker, and a Duke’s Choice Award Winner • Involved in architecting and implementing dozens of large scale systems over the past 20 years or so • Book author for O’Reilly, speaker at many conferences
- 3. Cheaper Better Faster Stronger{ Most problemsin Computer Science have already been solved in the 60/70s
- 5. Say what? The term"Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. Source: http://martinfowler.com/articles/microservices.html
- 6. Where did itcome from? • Microservices-style architectures are a response to adjust software architecture to an ever-evolving spectrum. It addresses Business Agility through technology: • Usage of cloud-based infrastructure and services • DevOps • The need to scale up the number of people/teams • Client-side revolution both in technologies and devices
- 7.
- 8. Modularization • Divide andConquer • Break down complex structures into smaller chunks that can be solved individually • Cohesion over coupling
- 9. How small ismicro? • Small as in “single responsibility” • Each service only does one thing, and one thing well • Not about lines of code, but “small enough to fit in your head” • Maybe even small enough that you can throw them away – Rewrite over Maintain
- 10. Are Microservices abetter SOA?
- 11. Services • Provide apublic, versioned contract for a component • Have their own life cycle, so they can be separately deployed • Hide all implementation details
- 12. Comparing with SOA •SOA: dumb endpoints, smart routes • Endpoint is merely a remote procedure call • Routing done through ESBs providing location transparency and transformations
- 13. Comparing with SOA •Microservices: Dumb pipes, smart endpoints • Pipes: usually REST via HTTP(S) • No intelligence in the route, or at least no more than simple (persistent) queues
- 14. SOA is aboutReuse Microservices are NOT about Reuse
- 15. What can welearn from Amazon/Netflix? • They are not optimized for (saving) costs or overly structured • Focus on opportunities ahead instead of cost savings • Focus on speed to market (first mover advantage) • Organized like nature to facilitate insane growth • Cloud is their strategic advantage!
- 16. Why shouldn’t wepretend to be Amazon/Netflix? • Most normal companies ARE looking for cost savings and restructuring • Most normal companies don’t have the scale of Amazon/Netflix • Most normal companies see cloud still as a way to save costs • If you pretend you are…you get all of their infrastructural problems for free
- 17. Companies that havesuccessfully adopted Microservices have… • …determined that they are an IT company which happen to offer financial/healthcare/trading/shopping… services • …embraced Cloud (technologies) as a strategic advantage • …established solid CI/CD practices, and deploy to production multiple times per day
- 18.
- 19.
- 20.
- 21. Conway’s Law “Organizations whichdesign systems ... are constrained to produce designs which are copies of the communication structures of these organizations" —M. Conway 1968
- 22. What it actuallymeans… • Make sure the organization is compatible with the software architecture • If your (microservices) architecture does not reflect the way your organization is structured, don’t even bother going that way! • It also means that your teams should be cross-functional. Everyone you need to build, maintain and get it into production must be part of the team
- 23.
- 24.
- 25. So what shouldyou do? • Transform the organization along with the landscape • Microservices boundaries must be drawn around organizational capabilities • Alternatively, they could be drawn around particular development teams / features
- 26. There is nosingle way to do microservices right!
- 27. There are manyways to do microservices wrong!
- 28. Many wrong waysto do microservices there are!
- 29. Struggles • Data Strategy •Orchestration vs Choreography • Re-use Traps • Test Strategy • Dealing with Failure
- 30. Resilience • The abilityof a system to handle unexpected situations • without the user noticing it (best case) • with graceful degradation of service (worst case)
- 31.
- 32. Isolation • Avoid cascadingfailures by applying bulkheads: • In shipping: partition the load into sections allowing you to seal them off if there is a breach • In software: isolate services to prevent cascading failures to cripple the entire system Web Application thread pool • • • • Service bulkhead (size=3)
- 33. Loose-coupling • Reduce couplingbetween failure units through: • asynchronous communication • location transparency • relaxed temporal constraints • idempotency • self-containment
- 34. Latency control • Detectand handle non-timely responses to avoid cascading failures through: • Timeouts • CircuitBreaker • Fan-out & quickest reply • Bounded queues • Shed load InitiatingService CircuitBreaker TargetService try 1 try 2 try 3 try 83 exception exception exception exception try 1 try 2 try 3 exception exception exception circuit is CLOSED circuit trips and is OPEN circuit is HALF-OPEN
- 35. Anti-fragility • Try tomake code less breakable by correctly applying: - Encapsulation (OOP) - Open/Closed principle - Test Driven Development (TDD)
- 36.
- 37. Microservices are NOTthe logical next step for enterprise architecture in every organization
- 38. Microservices • ..are suitesof independently deployable services, organized around business capabilities • ..are small enough so they can ‘fit in your head’ and you can throw them away • ..are all about promoting modularity at the system level • ..are thriving on continuous deployment, DevOps, and infrastructure automation • ..are a legitimate way of achieving business agility in some organizations • ..will cause nightmares forever, when applied for the wrong reasons!
- 39.