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.

Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability


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.

In this talk I describe the essential characteristics of the microservice architecture.You will learn about its benefits and its drawbacks. I describe 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
  • D0WNL0AD FULL ▶ ▶ ▶ ▶ ◀ ◀ ◀ ◀
    Are you sure you want to  Yes  No
    Your message goes here
  • 'd definitely check some of these figures. They seem ripe for mis-communication. Deployment every 11.6 seconds is different to (we had one day where we deployed every 12 seconds). That is just shy of 7,450 deploys per day. It might help to know how many developers and timezones that would be over. A company with 50 devs, should know how many devs these giants have so the figures can be expressed as a scaled unit.
    Are you sure you want to  Yes  No
    Your message goes here

Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decomposing for testability and deployability

  1. 1. @crichardson Microservices adoption anti- patterns: obstacles to decomposing for testability and deployability Chris Richardson Founder of Founder of the original Author of Microservices Patterns and POJOs in Action @crichardson Copyright © 2019. Chris Richardson Consulting, Inc. All rights reserved
  2. 2. @crichardson Presentation goal Essential characteristics of the microservice architecture And adoption anti-patterns
  3. 3. @crichardson About Chris
  4. 4. @crichardson About Chris Consultant and trainer focussed on helping organizations adopt the microservice architecture (
  5. 5. @crichardson About Chris Founder of a startup that is creating an open-source/SaaS platform that simplifies the development of transactional microservices (
  6. 6. @crichardson About Chris 40% discount with code ctwmelmsajan19
  7. 7. About Chris: Microservices pattern language Articles Code examples Microservices Assessment Platform - http://
  8. 8. Agenda From monolith to microservices Benefits and drawbacks of microservices Technical anti-patterns No so technical anti-patterns
  9. 9. @crichardson + Businesses must innovate faster Software Deliver software rapidly, frequently and reliably
  10. 10. @crichardson Quantifying rapid, frequent and reliable delivery Velocity Lead time - time from commit to deploy Deployment frequency - deploys per developer per day Reliability Mean time to recover from a deployment failure Change failure rate - % of deployments that cause an outage
  11. 11. @crichardson Deliver software rapidly, frequently and reliably Process: DevOps/Continuous Delivery & Deployment Organization: Small, autonomous teams Architecture: ???
  12. 12. @crichardson Application architecture must enable rapid, frequent and reliable delivery
  13. 13. Required architectural quality attributes (-ilities) Development velocity Maintainability Testability Deployability
  14. 14. @crichardson Let’s imagine that you are building a cool new food delivery application….
  15. 15. @crichardson Tomcat/App. Server Food To Go: Monolithic architecture Browser/ Client WAR/EAR MySQL Database Delivery management Order Management Kitchen Management Web UI Restaurant Management HTML REST/JSON The application
  16. 16. @crichardson The monolithic architecture is an architectural style that structures the application as a single executable component Implementation view
  17. 17. -ilities of small monoliths Maintainability Testability Deployability … 😄
  18. 18. But eventually you end up in monolithic hell Application becomes extremely large => a big ball of mud Rapid, frequent and reliable delivery becomes impossible Technology stack becomes increasingly obsolete BUT a rewrite is not feasible
  19. 19. @crichardson Use the microservice architecture
  20. 20. The microservice architecture is an architectural style that structures an application as a set of services that are organized around business capabilities
  21. 21. @crichardson Food to Go: Microservice architecture Browser Mobile Application Content Router API Gateway Order Service Restaurant Service Delivery Service … Service Order Database Restaurant Database Delivery Database … Database HTTP /HTML REST REST Browse & Search WebApp Restaurant Detail WebApp …. JavaScript
  22. 22. @crichardson A well-designed microservice Highly maintainable and testable Minimal lead time high deployment frequency Loosely coupled independently deployable Implements a business capability Developed by a small team
  23. 23. @crichardson API The structure of a service… Operations Event Publisher Commands Queries Synchronous REST/gRPC Asynchronous Messaging Events Event Subscriber API Client Invokes Operations Events Service Database Private!
  24. 24. @crichardson … The structure of a service SLA Telemetry API Telemetry: Metrics, exceptions Externalized configuration Logging Distributed tracing Heath Check endpoint
  25. 25. Agenda From monolith to microservices Benefits and drawbacks of microservices Technical anti-patterns No so technical anti-patterns
  26. 26. Benefits of microservices Improved maintainability Each service is smaller and so easier to understand and change Preserves modularity since a service is a well-defined module with an impermeable API Improved testability: Each service is small and so is easier to test Improved deployability Each service can be deployed independently Easier to scale application Improves fault isolation Easier to experiment with new technologies and evolve the technology stack
  27. 27. @crichardson Deliver software rapidly, frequently and reliably Process: DevOps/Continuous Delivery & Deployment Organization: Small, autonomous teams Architecture: microservices Testability Deployability Enables Autonomy
  28. 28. @crichardson Loosely coupled teams and services Order Service Orders Team Automated deployment pipeline Source code repository Kitchen Service Kitchen Team Automated deployment pipeline Source code repository Delivery Service Delivery Team Automated deployment pipeline Source code repository Working independently > 80% of the time
  29. 29. @crichardson Modern software development: moving fast and not breaking things! 46x 440x 24x 5x lower Amazon: ~0.001% Netflix: 16 minutes Amazon: every 11.6 seconds
  30. 30. @crichardson
  31. 31. @crichardson Drawbacks of microservices Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
  32. 32. Challenging to implement features that span services Requires coordination and planning across teams If it happens frequently: Distributed monolith? Reconsider decomposition Service A Service B Service C Change Team A Team B Team C
  33. 33. @crichardson When using microservices: How to decompose an application into services? How to deploy an application’s services? How to handle cross cutting concerns? Which communication mechanisms to use? How do external clients communicate with the services? How does a client discover the network location of a service instance? How to prevent a network or service failure from cascading to other services? How to maintain data consistency and implement queries? How to make testing easier? How to understand the behavior of an application and troubleshoot problems? How to implement a UI screen or page that displays data from multiple services?
  34. 34. @crichardson Microservices pattern language: Splitting Reassembling Operations Architecture Microservice patterns Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backend for front end Event sourcing Aggregate Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit BreakerAccess Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Domain event Consumer-side contract test Sidecar Service mesh Application patterns Infrastructure patterns Application Infrastructure patterns Log deployments and changes
  35. 35. Agenda From monolith to microservices Benefits and drawbacks of microservices Technical anti-patterns No so technical anti-patterns
  36. 36. Problem: Developers treat services as if they are programming language-level modules (that communicate via HTTP) Consequences: IPC is relatively expensive => high latency Synchronous communication => temporal coupling => reduced availability Anti-pattern: Distribution is free
  37. 37. @crichardson Example of temporal coupling Order Service Customer
 Service GET /customer/id availability = availability(OrderService) x availability(CustomerService) 😓 POST /order * any synchronous IPC mechanism
  38. 38. Solution: careful interaction design Carefully consider how your services interact Coarse-grained interactions Preferably asynchronous
  39. 39. Solution: self contained services Service that handles a synchronous request without needing response from any other service Synchronous request initiates saga OR Service has a replica of another services data Order Service Customer
 Service POST /order Order created Customer Validated
  40. 40. Anti-pattern: Shared database Problem: A database table is accessed by multiple services/monolith e.g Customer Service accesses the Order table Consequences: Changing Order table is no longer easy => requires coordination across teams Customer Service updates table => impossible to reason about Order Service in isolation Services are no longer isolated at runtime
  41. 41. Solution: database per service Each table is only accessed by a single service Services collaborate only through APIs
  42. 42. Anti-pattern: Unencapsulated service Problem: Service has a large API that encapsulates very little Consequences: Service API is frequently changing incompatibly forcing consumers to upgrade Defeats the purpose of microservices
  43. 43. Example Entity Service Thin wrapper around a database CRUD operations Change schema => change API
  44. 44. @crichardson Solution: encapsulation Hide as much of the implementation as possible Prevents changes from impacting consumers => loosely coupled teams
  45. 45. Solution: Iceberg services A service API should encapsulate significant business functionality API = small Implementation = large Bundle data and behavior API Implementation DB waterline
  46. 46. Anti-pattern: Distributed monolith Problem: Two or more services implement the same concept Consequences Must change in lock step
  47. 47. @crichardson
  48. 48. Segment’s distributed monolith Segment routes messages from customers to destinations A service per destination BUT Common transformation logic, e.g. Change shared library => redeploy all services Compounded by lack of automated deployment Service A Library Queue Service B Library Queue Service … Library Queue Change
  49. 49. @crichardson Avoiding the distributed monolith anti-pattern Apply the Common Closure Principle (CCP) Things that change together should be packaged together e.g. Segment could use a pre-processor that canonicalizes Understand the domain and how it evolves Requires a crystal ball BUT the past can be a guide
  50. 50. Agenda From monolith to microservices Benefits and drawbacks of microservices Technical anti-patterns No so technical anti-patterns
  51. 51. @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
  52. 52. @crichardson Anti-pattern: Magic pixie dust
  53. 53. @crichardson Believing a sprinkle of microservices will solve your development problems
  54. 54. @crichardson The Microservice architecture solves the problem of how to accelerate the development of a large complex application
  55. 55. @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 …
  56. 56. @crichardson Migrate to microservices Disappointment The problems remain or Get worse! * Flying before you can walk anti-pattern *
  57. 57. @crichardson Identify problems with application and software 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
  58. 58. @crichardson Anti-pattern: microservices as the goal
  59. 59. @crichardson Leadership announces a microservices transformation initiative Bonus ∝#microservices
  60. 60. @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
  61. 61. @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
  62. 62. @crichardson Anti-pattern: Scattershot adoption
  63. 63. @crichardson * Perhaps because leadership made it everyone’s goal Multiple teams independently adopting microservices with no coordination*
  64. 64. @crichardson Duplication of effort, e.g. building infrastructure for deployment pipelines and runtime environments Development teams might not have the skills to build infrastructure
  65. 65. @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
  66. 66. @crichardson Anti-pattern: Trying to fly before you can walk
  67. 67. @crichardson A organization attempts microservices while lacking key skills, e.g. clean code object-oriented design automated testing …
  68. 68. @crichardson Migrate to microservices Disappointment Development problems remain or Get worse!
  69. 69. 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 Automated testing Domain-driven DevOps and Crawl Walk Jog Run Fly
  70. 70. @crichardson Anti-pattern: Focussing on technology
  71. 71. @crichardson Seriously cool technology 😎 + vendors telling you to buy their cool stuff Organizations focus on infrastructure not application architecture
  72. 72. @crichardson Infrastructure = undifferentiated heavy lifting
  73. 73. @crichardson Big upfront investment = Decision made without experience
  74. 74. @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 *
  75. 75. @crichardson Anti-pattern: The more the merrier
  76. 76. @crichardson Planning to have a large number of services Risk of unnecessary complexity Risk that changes impact numerous services
  77. 77. @crichardson Service per team Service Small, autonomous team Service Service Service & team
  78. 78. @crichardson Anti-pattern: Walking in front with a red flag Anti-pattern: Red flag law
  79. 79. @crichardson Adopting microservices without changing process, policies and organization Silo’d teams Manual testing Monthly deploys at midnight …
  80. 80. @crichardson Disappointment Fewer benefits of using microservices Business might view the migration effort as a failure
  81. 81. @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
  82. 82. @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
  83. 83. @crichardson Summary The Microservice architecture enables the rapid, frequent and reliable of large, complex applications It’s not a silver bullet or panacea Make sure you have mastered the basics: e.g. automated testing Focus on accelerating, reliable software delivery Adopting the microservice architecture requires you to change your process, policies and organization Start simple and grow incrementally
  84. 84. @crichardson @crichardson Questions? 40% discount with code ctwmelmsajan19