Microservices rules #10: Make smaller, safer, and reversible changes - part 4
This article continues the series on microservices rules: what good looks like, a collection of principles and practices that help teams adopt microservices successfully.
The articles in the series are:
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 - part 1, part 2, part 3
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
Microservices rules #10 is Make smaller, safer, and reversible changes.
In the previous article, I described why canary releases - progressively routing traffic from the old version of a service to the new version - improves the safety of production updates and enables easier rollbacks. But let’s imagine that you have reimplemented a new billing service for your customers. Since each implementation has its own database, it’s no longer a simple matter of randomly load balancing requests between the two. Instead, you must carefully migrate customers from the old service to the new one. Let’s look at how you can accomplish a migration starting with traditional approach before exploring how you can do it incrementally.
