3 min read

Microservices rules: part 1 - overview

Microservices rules: part 1 - overview
Microservices rules: part 1 - overview

I recently gave a presentation about microservices rules, a set of 11 best practices that organizations should follow when adopting the microservice architecture:

1. Practice continuous delivery/deployment

2. Implement fast, automated deployment pipelines

3. Apply Team Topologies

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 - part 1 - incremental architecture modernization, part 2 - continuous deployment, part 3 - canary releases, part 4 - incrementally migrating users, part 5 - smaller user stories

11.Track and improve software metrics and KPIs

These rules grew out of my frustration with the way that many organizations have adopted microservices. I’ve had numerous conversations where developers have complained that their new microservices-based applications are difficult to change. Some developers had even quit projects out of frustration. This is not right: the goal of adopting microservices is to improve the developer experience and accelerate software delivery.

The goal of these rules is to prevent organizations from making a mess of their microservice architecture. This article is the first in a series of articles that describe these rules in detail. In this article, I provide an overview of the rules and explain why they are important.

This post is for paying subscribers only