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
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.