Microservices Gone Wrong!
4 likes923 views
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.
Microservices Gone Wrong!
- 1. by Bert Ertman Those who stand for nothing, fall for anything - Alexander Hamilton Microservices Gone Wrong! @BertErtman
- 2. • Fellow, Director of 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 problems in 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 it come 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
- 8. Modularization • Divide and Conquer • Break down complex structures into smaller chunks that can be solved individually • Cohesion over coupling
- 9. How small is micro? • 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 a better SOA?
- 11. Services • Provide a public, 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 about Reuse Microservices are NOT about Reuse
- 15. What can we learn 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 we pretend 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 have successfully 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
- 19. *correction*
- 21. Conway’s Law “Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations" —M. Conway 1968
- 22. What it actually means… • 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. This is hard!
- 24. SOAAdoptionModel
- 25. So what should you 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 no single way to do microservices right!
- 27. There are many ways to do microservices wrong!
- 28. Many wrong ways to do microservices there are!
- 29. Struggles • Data Strategy • Orchestration vs Choreography • Re-use Traps • Test Strategy • Dealing with Failure
- 30. Resilience • The ability of a system to handle unexpected situations • without the user noticing it (best case) • with graceful degradation of service (worst case)
- 32. Isolation • Avoid cascading failures 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 coupling between failure units through: • asynchronous communication • location transparency • relaxed temporal constraints • idempotency • self-containment
- 34. Latency control • Detect and 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 to make code less breakable by correctly applying: - Encapsulation (OOP) - Open/Closed principle - Test Driven Development (TDD)
- 36. summary
- 37. Microservices are NOT the logical next step for enterprise architecture in every organization
- 38. Microservices • ..are suites of 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!