Microservices rules #10: Make smaller, safer, and reversible changes - part 4
This is the sixth article in the series about microservices rules: what good looks like, which are a set of principles and practices for using microservices effectively.
The other articles in the series are:
- Microservices rules #2: Implement fast, automated deployment pipelines
- Microservices rules #5: Deliberative design
- Microservices rules #10: part 1 - incremental architecture modernization
- Microservices rules #10: part 2 - continuous delivery/deployment
- Microservices rules #10: part 3 - canary deployments
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.
