Microservices rules: What good looks like

My Berlin Java/Spring meetup

The microservice architecture has become increasingly popular over the past decade. Its key benefits include significantly improving the developer experience and accelerating software delivery. Sadly, however, microservices have often been widely misunderstood and used inappropriately. As a result, many organizations have struggled to benefit from their adoption. I’ve had numerous conversations where developers have complained that their new microservices-based applications are difficult to change. They have very quickly created an unmaintainable legacy application. To prevent this from happening, I’ve defined 11 development and architecture rules (a.k.a. best practices).

Transcript

1. @crichardson Microservices rules: what good looks like Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns chris@chrisrichardson.net http://adopt.microservices.io https://www.linkedin.com/in/pojos Copyright © 2025. Chris Richardson Consulting, Inc. All rights reserved
2. @crichardson “Our application is ‘****’, it's so complex and so dif fi cult to change” Architect of ancient legacy application Developer of a young microservices application
3. @crichardson Presentation goal 11 rules that prevent an organization from making a mess of its microservice architecture
4. @crichardson About Chris http://adopt.microservices.io
5. @crichardson About Chris https://chrisrichardson.net/
6. @crichardson Microservices Patterns, 2nd edition https://microservices.io/post/architecture/2025/06/26/announcing-meap-microservices- patterns-2nd-edition.html
7. @crichardson Microservices rules Architecture Architecture rules Software development rules Foundational rules Enables Monolith Microservices Defines Constrains Evolution strategy 2. Implement fast, automated deployment pipelines 1. Practice continuous delivery/deployment 3. Apply Team Topologies: organizing for fast flow 4. Provide a great developer experience (DevEx) 5. Use a deliberative design process 6. Design independently deployable services 7. Design loosely coupled services 8. Design testable services 9. Develop observable services 10. Big/risky change => smaller/safer and (ideally easily) reversible changes 11. Track and improve software metrics and KPIs Leaders must pay attention to software delivery Key development practices: DevOps and Team Topologies Essential characteristics of the microservice architecture Provides feedback from production: the second DevOps way Enables a fast deployment pipeline Elusive but essential Seems obvious but … Provides feedback about the adoption of a new architecture https://microservices.io/articles/microservices-rules/ index.html
8. @crichardson Software development rules 2. Implement fast, automated deployment pipelines 1. Practice continuous delivery/deployment 3. Apply Team Topologies: organizing for fast flow 4. Provide a great developer experience (DevEx) Key development practices: DevOps and Team Topologies Elusive but essential
9. @crichardson The software delivery feedback loop Development Production Changes: Features, defects, risk, tech debt Feedback Users IT
10. @crichardson Traditional software delivery: slow feedback loop Feedback Long Occasional Development Production Feedback Users QA Ops Slow Handoff Handoff Lots of meetings
11. @crichardson Volatile Uncertain Complex Ambiguous Building complex applications Often using new, unfamiliar technologies + Slow feedback loops = Build the wrong application, the wrong way
12. @crichardson Fast fl ow for business succe$$ in today’s VUCA world Development Production Continuous stream of small changes, many times a day Continuous feedback and learning https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance Users IT
13. @crichardson https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 The success triangle Process: Organization: IT must practice fast fl ow Businesses must be nimble, agile and innovate faster S/W VUCA Fast fl ow architecture: Monolith (small org/app) or Microservices (at scale) Enables Enables Principles and practices for fast fl ow Organizational patterns for fast fl ow
14. What is DevOps? Set of principles and practices where developers, testers (dev) and IT operations (ops) collaborate and communicate to deliver software rapidly, frequently, and reliably http://itrevolution.com/devops-handbook Three ways Flow Feedback Learning
15. @crichardson Rule #1: Practice continuous delivery/deployment The ability to get changes into production safely and quickly in a sustainable way. Code (Git) repository is the source of truth Software is always releasable Developers commit frequently - e.g. daily - to trunk Highly automated https://continuousdelivery.com/
16. @crichardson Rule #2: Implement a fast deployment pipeline Production Fast, automated deployment pipeline Developer laptop Application repository 15 minutes
17. Rule #3: Apply Team Topologies: organizing for fast fl ow
18. When necessary: create platforms to help the service teams An artifact that reduces the cognitive load of the stream- aligned teams https://microservices.io/post/architecture/2025/11/23/qconsf-2025-microservices-platforms.html
19. Microservices Platforms + Teams https://microservices.io/post/architecture/2025/05/06/microservices-platforms-team-topologies-patterns.html
20. @crichardson Rule #4: Provide a great DevEx DevEx Work environment than minimizes interruptions, meaningful work, … Minimize - simplify environment, automate, good documentation, … Fast feedback from colleagues, tools, deployment pipeline, production, users, … Feedback Flow Cognitive load https://premium.microservices.io/microservices-rules-4- provide-a-great-developer-experience/ Great
21. @crichardson “Developer experience isn’t just about making developers happy —it’s about removing friction that slows down your entire business.”
22. @crichardson Foundational rules 5. Use a deliberative design process 10. Big/risky change => smaller/safer and (ideally easily) reversible changes 11. Track and improve software metrics and KPIs Leaders must pay attention to software delivery Seems obvious but … Provides feedback about the adoption of a new architecture
23. @crichardson Architecture = series of design decisions https://premium.microservices.io/a-service-should-exist-to-solve-a-problem/
24. Irrational @FamousDev says X is good/bad X looks like a cool, new thing to try X would look good on my resume I’ve used X in my past 5 jobs Magical thinking: we can neglect architecture … https://microservices.io/post/architecture/2023/03/13/better-decision-making-with-patterns.html Requires knowledge Only you know this Rule #5: use a deliberative design process
25. @crichardson e.g.: Service exists to solve a problem Add new service If and only if the bene fi ts outweigh the drawbacks https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html Dark energy/Dark matter
26. @crichardson Architecture rules 6. Design independently deployable services 7. Design loosely coupled services 8. Design testable services 9. Develop observable services Essential characteristics of the microservice architecture Provides feedback from production: the second DevOps way Enables a fast deployment pipeline
27. @crichardson Microservice architecture: two or more components Production Deployment pipeline Service Repo Deployment pipeline Service Repo Deployment pipeline Service Repo Independently deployable Loosely coupled Svc Svc Svc Some system operations span multiple services
28. Rule #6: Design loosely (design-time*) coupled services * vs runtime and build-time coupling https://microservices.io/post/architecture/2023/03/28/microservice-architecture-essentials-loose-coupling.html Customer Service Customer Subdomain Order Service Order Subdomain API Stable Infrequent lock step changes
29. The problem with tight design- time coupling Changing services in lock step reduces productivity: API changes/evolution Complexity of non-atomic changes of independently deployable services Coordination between teams Worst case: distributed monolith! Therefore: Tightly coupled subdomains should be packaged together Order Service Customer Subdomain Order Subdomain Package together
30. Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change https://microservices.io/post/architecture/2023/03/01/geometry-of-microservices.html
31. @crichardson Rule #7: design independently deployable services https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html Production Order Service Order Service Deployment pipeline Test in isolation Test Service Test Double Service Sole criteria for release Includes contract- testing to enforce API interoperability Deploy automatically
32. @crichardson Why independently deployable services? De fi ning characteristic of the microservice architecture Enables teams to develop and deploy independently Testing a service in isolation Simpler testing set up using test doubles Fast Reliable Testing services together = distributed monolith = downsides of both with few of the bene fi ts By de fi nition: the output of a deployment pipeline is deployable
33. @crichardson Rule #8: Design testable services Automated - tests must be automated Fast - tests must execute quickly to provide fast feedback Reliable - tests must not be fl aky: failing test = real problem Locally executable - tests must run on a developer's laptop to provide fast feedback. Isolated - tests must use test doubles for the service's dependencies
34. @crichardson Rule #9: develop observable services Key Health check invoker, e.g. monitoring service Invokes Observable Service Health Check API Health Check API pattern Log file Logging server Log aggregation pattern Exception Reporter Exception Tracking Service Exception Tracking pattern Audit Database Adapter Audit Logging pattern Metrics Exporter Metrics service Application Metrics pattern Distributed Tracing Exporter Distributed tracing server Distributed tracing pattern Logging Aggregation Pipeline Logging Adapter Pattern Developer responsibility Operations responsibility Auditing Database Pattern Participant
35. Why observable services? Quick detect and rollback broken deployments (Fast) feedback is a foundation of DevEx and DevOps Quickly detect, diagnose and fi x production issues http://itrevolution.com/devops-handbook Flow Feedback Learning
36. @crichardson Foundational rules 5. Use a deliberative design process 10. Big/risky change => smaller/safer and (ideally easily) reversible changes 11. Track and improve software metrics and KPIs Leaders must pay attention to software delivery Seems obvious but … Provides feedback about the adoption of a new architecture
37. @crichardson Rule #10: Big/risky changes* => smaller/safer/reversible changes * Architecture changes, migrations
38. @crichardson Example: Incrementally migrate from a monolith to microservices 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 Service Service Service Service Service Service Service Service New features
39. Why is the Strangler Fig application pattern better than a big bang rewrite? Acknowledges that modernization is a process of discovery Immediate bene fi t from services Enables agility Early and continuous feedback and learning https://microservices.io/post/refactoring/2023/06/21/strangler- fi g-application-pattern-incremental-modernization-to-services.md.html
40. @crichardson Other examples of smaller/ safer/reversible changes Continuous deployment Canary deployments - incrementally shift traf fi c to new Incrementally migrating users from old to new Learning through continual experimentation
41. @crichardson DORA metrics: measuring performance https://dora.dev/ Metric Description Elite performance Deployment frequency How frequently changes are pushed to production Each commit Lead time Time from commit to deploy < 1 hour Change failure rate How frequently a change breaks production Very low Time to restore service How long to recover from a failed deployment Very short Move fast to not break things
42. @crichardson Assess DevEx https://queue.acm.org/detail.cfm?id=3595878
43. @crichardson Capture architecture metrics Key focus: design-time coupling between services Predict from design metrics Analyze inbound/outbound dependencies Observe actual issues Commits for multiple services for the same JIRA issue Frequency of breaking API changes
44. Organizational KPIs Software delivery performance impacts business success THEREFORE: Every leader including CxOs should pay attention Category KPI Delivery Lead time Deployment frequency DevEx Perceived ease of delivery Perceived productivity Architecture Degree of loose design-time coupling
45. @crichardson Microservices rules Architecture Architecture rules Software development rules Foundational rules Enables Monolith Microservices Defines Constrains Evolution strategy 2. Implement fast, automated deployment pipelines 1. Practice continuous delivery/deployment 3. Apply Team Topologies: organizing for fast flow 4. Provide a great developer experience (DevEx) 5. Use a deliberative design process 6. Design independently deployable services 7. Design loosely coupled services 8. Design testable services 9. Develop observable services 10. Big/risky change => smaller/safer and (ideally easily) reversible changes 11. Track and improve software metrics and KPIs Leaders must pay attention to software delivery Key development practices: DevOps and Team Topologies Essential characteristics of the microservice architecture Provides feedback from production: the second DevOps way Enables a fast deployment pipeline Elusive but essential Seems obvious but … Provides feedback about the adoption of a new architecture https://microservices.io/articles/microservices-rules/ index.html
46. @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? https://www.linkedin.com/in/pojos