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.

Lisbon DevOps: "Seven (More) Deadly Sins of Microservices"

374 views

Published on

All is not completely rosy in microservice-land. It’s often a sign of an architectural approach’s maturity that anti-patterns begin to be identified and classified alongside well-established principles and practices. Daniel Bryant introduces seven deadly sins from real projects, which left unchecked could easily ruin your next microservices project.

Daniel offers an updated tour of some of the nastiest anti-patterns in microservices from several real-world projects he’s encountered as a consultant, providing a series of anti-pattern “smells” to watch out for and exploring the tools and techniques you need to avoid or mitigate the potential damage.

Topics include:

Pride: the admission of the challenges with testing in a distributed system
Envy: introducing inappropriate intimacy within services by creating a shared “canonical” domain model
Wrath: failing to deal with the inevitable bad things that occur when operating new technologies, both from the people and technical aspects
Sloth: composing services in a lazy fashion, which ultimately leads to the creation of a "distributed monolith”
Lust: embracing the latest and greatest technology without evaluating the operational impact incurred by these choices.

Published in: Technology
  • Be the first to comment

Lisbon DevOps: "Seven (More) Deadly Sins of Microservices"

  1. 1. The Seven (More) DEADLY SINS OF Microservices @danielbryantuk
  2. 2. Previously, AT Devoxx UK & QCON NYC... 13/01/2019 @danielbryantuk https://www.infoq.com/presentations/7-sins-microservices
  3. 3. The Seven (more) Deadly Sins of Microservices 1. LUST - Using the (Unevaluated) latest and greatest tech… 2. GLUTTONY - Communication lock-in 3. GREED - What'S Mine is mine (within the organisation)… 4. SLOTH - Getting lazy with NFRs 5. WRATH - Blowing up when bad things happen 6. ENVY - The shared single domain (and data store) fallacy 7. PRIDE - testing in the world of transience 13/01/2019 @danielbryantuk
  4. 4. @danielbryantuk • Tech Consultant, Product Architect at Datawire • Agile, architecture, CI/CD, Programmable infrastructure • Java, Go, JS, microservices, cloud, containers • Continuous delivery of value through effective technology and teams 13/01/2019 @danielbryantuk bit.ly/2jWDSF7 oreil.ly/2E63nCR
  5. 5. 1. Lust - Using THE LATEST and Greatest Tech… 13/01/2019 @danielbryantuk
  6. 6. Microservices... They solve all of our problems, Right? 13/01/2019 @danielbryantuk
  7. 7. No... Not necessarily good for speed 13/01/2019 @danielbryantuk skillsmatter.com/skillscasts/6143-microservices-for-speed Additional Reading!! martinfowler.com/bliki/MonolithFirst.html segment.com/blog/goodbye-microservices/
  8. 8. No... Check your architecture/design skills “If you can't build a [well-structured] monolith, what makes you think microservices are the answer?” Simon Brown (bit.ly/1n7D0vp) 13/01/2019 @danielbryantuk
  9. 9. 13/01/2019 @danielbryantuk
  10. 10. No... Check your architecture/design skills 13/01/2019 @danielbryantuk
  11. 11. No... Operational maturity is vital 13/01/2019 @danielbryantuk martinfowler.com/bliki/MicroservicePrerequisites.html
  12. 12. Microservices are very useful But check your use case... ...Evaluation is a key skill Both for architecture and technology 13/01/2019 @danielbryantuk
  13. 13. Technology Evaluation “I will postpone using this new microservice framework until my peers have validated the proposed benefits with rigorous scientific experiments” - Said by no programmer …ever 13/01/2019 @danielbryantuk
  14. 14. AN example: To containerise, or not to containerise? (dockaH, dockah, dockah... Dockah?) 13/01/2019 @danielbryantuk
  15. 15. Strategy #fail 13/01/2019 @danielbryantuk
  16. 16. Architecture/ops: Expectations versus reality 13/01/2019 @danielbryantuk “DevOps”
  17. 17. 13/01/2019 @danielbryantuk developers.redhat.com/blog/2017/03/14/java-inside-docker/ https://www.youtube.com/watch?v=lviLZFciDv4 https://12factor.net/
  18. 18. 2. GLUTTONY - Communication lock-in 13/01/2019 @danielbryantuk
  19. 19. The ESB is dead - long live the esb! 13/01/2019 @danielbryantuk
  20. 20. The ESB is dead - long live the esb! 13/01/2019 @danielbryantuk
  21. 21. The ESB is dead - long live the esb! 13/01/2019 @danielbryantuk • Is this an ESB? • Or an API gateway?
  22. 22. The ESB is dead - long live the API Gateway! 13/01/2019 @danielbryantuk • Watch for the API Gateway morphing into an Enterprise service bus – Loose coupling is vital • But let me be clear... – The API Gateway pattern is awesome – Centralise cross-cutting concerns – Prevent wheel-reinvention (plugins) – Check out kong, apigee, Mulesoft etc
  23. 23. 3. GREED - What'S mine is mine... (within the organisation)… 13/01/2019 @danielbryantuk
  24. 24. Previously... • Conway'S Law • Microservices are about people, as much as they are tech – Maybe more – Particularly in a migration / transformation 13/01/2019 @danielbryantuk
  25. 25. We hear this a lot... “We’ve decided to reform our teams around squads, chapters and guilds” • Beware of cargo-culting – Repeat three times “We are not spotify” • Understand the practices, principles, values etc 13/01/2019 @danielbryantuk
  26. 26. 4. SLOTH - Getting Lazy with NFRs 13/01/2019 @danielbryantuk
  27. 27. Getting lazy with non-Functional Requirements “The driving technical requirements for a system should be identified early to ensure they are properly handled in subsequent design” Aidan Casey Guiding principles for evolutionary architecture 13/01/2019 @danielbryantuk
  28. 28. Getting lazy with NFRs - security 13/01/2019 @danielbryantuk www.slideshare.net/spnewman/appsec-microservices-velocity-2016 www.infoq.com/news/2016/08/secure-docker-microservices
  29. 29. Testing NFRs in the build pipeline • Security testing – Findsecbugs / OWASP Dependency check – Bdd-security (OWASP ZAP) / Arachni – Gauntlt / Serverspec – Docker Bench / Kube Bench 13/01/2019 @danielbryantuk
  30. 30. Static Image Scanning 13/01/2019 @danielbryantuk github.com/arminc/clair-scanner
  31. 31. 5. WRATH - Blowing up when bad things happen 13/01/2019 @danielbryantuk
  32. 32. Previously - Bring in Michael Nygard (Or some monkeys) 13/01/2019 @danielbryantuk
  33. 33. When bad things happen, people are always involved 13/01/2019 @danielbryantuk | @oakinger
  34. 34. People Pain point - How does Devops fit into this? • http://web.devopstopologies.com/ • Books 13/01/2019 @danielbryantuk
  35. 35. Devops - the 'fullstack engineer' myth “I'M sorry, but if you'RE not designing the computer chips and writing the website, then I don'T wanna hear from you” Charity Majors (@mipsytipsy), CraftConf 2016 http://www.ustream.tv/recorded/86181845 13/01/2019 @danielbryantuk
  36. 36. Devops - define responsibilities • Do you really want to build an entire microservices platform? • Focus on what matters – Ci/CD – Mechanical sympathy – Logging – Monitoring 13/01/2019 @danielbryantuk
  37. 37. Worth considering: Open source PaaS/FaaS/DBaas 13/01/2019 @danielbryantuk
  38. 38. 6. ENVY - The shared SINGLE domain (and Data Store) fallacy 13/01/2019 @danielbryantuk
  39. 39. Previously - One Model to Rule Them All... • One model… – Breaks encapsulation – Introduces coupling • Know your DDD – Entities – Value Objects – Aggregates and Roots 13/01/2019 @danielbryantuk
  40. 40. Context mapping (static) & event storming (dynamic) 13/01/2019 @danielbryantuk | @spoole167 40 www.infoq.com/articles/ddd-contextmapping ziobrando.blogspot.co.uk/2013/11/introducing-event-storming.html
  41. 41. Choose (and use) data stores appropriately • RDBMS – Valuable for structured data • Cassandra is Awesome – but don'T treat it like an RDBMS! • Don'T build a graph with RDBMS – Use neo4j, Titan etc • Beware of operational overhead 13/01/2019 @danielbryantuk
  42. 42. 7. PRIDE - testing in the world of transience 13/01/2019 @danielbryantuk
  43. 43. Testing: Core concepts 13/01/2019 @danielbryantuk /lisacrispin.com/2011/11/08/using-the-agile-testing-quadrants/martinfowler.com/bliki/TestPyramid.html
  44. 44. The test pyramid (is just a model) • This model was created before the rise in popularity of microservices… – …but after David Parnas’ modularity • Applies at system and service level • Probably needs updating… 13/01/2019 @danielbryantuk martinfowler.com/bliki/TestPyramid.html
  45. 45. New testing strategies for microservices 13/01/2019 @danielbryantuk https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16 http://distributed-systems-observability-ebook.humio.com/
  46. 46. Microservice test funnel 13/01/2019 @danielbryantuk https://medium.com/@copyconstruct/testing-microservices-the-sane-way-9bb31d158c16
  47. 47. Resources 13/01/2019 @danielbryantuk itnext.io/microservice-testing-coupling-and-cohesion- all-the-way-down-a9f100cda523 martinfowler.com/articles/practical-test-pyramid.html
  48. 48. Right, Let'S Wrap this up... 13/01/2019 @danielbryantuk
  49. 49. The Seven (more) Deadly Sins of Microservices 1. LUST - Using the (Unevaluated) latest and greatest tech… 2. GLUTTONY - Communication Lock-in 3. GREED - What'S Mine is mine (within the organisation)… 4. SLOTH - Getting lazy with NFRs 5. WRATH - Blowing up when bad things happen 6. ENVY - The shared single domain (and data store) fallacy 7. PRIDE - testing in the world of transience 13/01/2019 @danielbryantuk
  50. 50. Bedtime reading 13/01/2019 @danielbryantuk
  51. 51. THANKS... @danielbryantuk (Credit to Tareq Abedrabbo, opencredo for inspiration/guidance) 13/01/2019 @danielbryantuk

×