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.

OReilly SACON London: Potholes in the road from monolithic hell: Microservices adoption anti-patterns

14,634 views

Published on

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.

Published in: Software
  • Be the first to comment

OReilly SACON London: Potholes in the road from monolithic hell: Microservices adoption anti-patterns

  1. 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. 2. @crichardson About Chris http://learn.microservices.io ctwsaconuk18
  3. 3. @crichardson Businesses must innovate faster Software Deliver software rapidly, frequently and reliably
  4. 4. @crichardson BUT an enterprise application is typically a large, complex monolith Development, testing and deployment is slow and painful
  5. 5. @crichardson Escaping monolithic hell seems like a good idea BUT… Team Team Team microservices.io
  6. 6. @crichardson The road from monolithic hell
  7. 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. 8. @crichardson Anti-pattern: Magic pixie dust
  9. 9. @crichardson Believing a sprinkle of microservices will solve your development problems
  10. 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. 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. 12. @crichardson Migrate to microservices Disappointment The problems remain or Get worse! * Flying before you can walk anti-pattern *
  13. 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. 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. 15. @crichardson Anti-pattern: microservices as the goal
  16. 16. @crichardson Leadership announces a microservices transformation initiative Bonus ∝#microservices
  17. 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. 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. 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. 20. @crichardson Anti-pattern: Scattershot adoption
  21. 21. @crichardson * Perhaps because leadership made it everyone’s goal Multiple teams independently adopting microservices with no coordination*
  22. 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. 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. 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. 25. @crichardson Anti-pattern: Trying to fly before you can walk
  26. 26. @crichardson A organization attempts microservices while lacking key skills, e.g. clean code object-oriented design automated testing …
  27. 27. @crichardson Migrate to microservices Disappointment Development problems remain or Get worse!
  28. 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. 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. 30. @crichardson Anti-pattern: Focussing on technology
  31. 31. @crichardson Seriously cool technology 😎 + vendors telling you to buy their cool stuff Organizations focus on infrastructure not application architecture
  32. 32. @crichardson Infrastructure = undifferentiated heavy lifting
  33. 33. @crichardson Big upfront investment = Decision made without experience
  34. 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. 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. 36. @crichardson Anti-pattern: The more the merrier
  37. 37. @crichardson Planning to have a large number of services Risk of unnecessary complexity Risk that changes impact numerous services
  38. 38. @crichardson Service per team Service Small, autonomous team Service Service Service & team mitosis
  39. 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. 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. 41. @crichardson Adopting microservices without changing process, policies and organization Silo’d teams Manual testing Monthly deploys at midnight …
  42. 42. @crichardson Disappointment Fewer benefits of using microservices Business might view the migration effort as a failure
  43. 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. 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. 45. @crichardson @crichardson chris@chrisrichardson.net https://learn.microservices.io Thank you! ctwsaconuk18 Meet the experts table @ 10.15am today

×