Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Microservices Gone Wrong!

433 views

Published on

With popular poster children such as Netflix and Amazon, using microservices-based architectures seems to be the killer approach to twenty-first-century architecture. This session goes over the benefits, but more so the pitfalls, of using a microservices-based architecture. What impact does it have on your organization, your applications, and dealing with scale and failures, and how do you prevent your landscape from becoming an unmaintainable nightmare?

Published in: Software
  • Be the first to comment

Microservices Gone Wrong!

  1. 1. by Bert Ertman Those who stand for nothing, fall for anything - Alexander Hamilton Microservices
 Gone Wrong! @BertErtman
  2. 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. 3. Cheaper Better Faster Stronger{ Most problems in Computer Science have already been solved in the 60/70s
  4. 4. 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
  5. 5. 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
  6. 6. Microservices are about Business Agility
  7. 7. Modularization • Divide and Conquer • Break down complex structures into smaller chunks that can be solved individually • Cohesion over coupling
  8. 8. 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
  9. 9. Are Microservices a better SOA?
  10. 10. Services • Provide a public, versioned contract for a component • Have their own life cycle, so they can be 
 separately deployed • Hide all implementation details
  11. 11. Comparing with SOA • SOA: dumb endpoints, smart routes • Endpoint is merely a remote procedure call • Routing done through ESBs providing location transparency and transformations
  12. 12. 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
  13. 13. SOA is about Reuse Microservices are NOT about Reuse
  14. 14. 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!
  15. 15. 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
  16. 16. 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
  17. 17. Microservices require DevOps
  18. 18. *correction*
  19. 19. Microservices require BizDevOpsSec
  20. 20. 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
  21. 21. 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
  22. 22. This is hard!
  23. 23. SOAAdoptionModel
  24. 24. 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
  25. 25. There is no single way to do microservices right!
  26. 26. There are many ways to do microservices wrong!
  27. 27. Many wrong ways to do microservices there are!
  28. 28. Struggles • Data Strategy • Orchestration vs Choreography • Re-use Traps • Test Strategy • Dealing with Failure
  29. 29. Resilience • The ability of a system to handle unexpected situations • without the user noticing it (best case) • with graceful degradation of service (worst case)
  30. 30. Anti-fragility Isolation Loose-coupling Latency
  31. 31. 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)
  32. 32. Loose-coupling • Reduce coupling between failure units through: • asynchronous communication • location transparency • relaxed temporal constraints • idempotency • self-containment
  33. 33. 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
  34. 34. Anti-fragility • Try to make code less breakable by correctly applying: - Encapsulation (OOP) - Open/Closed principle - Test Driven Development (TDD)
  35. 35. summary
  36. 36. Microservices are NOT the logical next step for enterprise architecture in every organization
  37. 37. 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!
  38. 38. Microservices Gone Wrong! Thank you! @BertErtman

×