Microservices rules #10: Make smaller, safer, and reversible changes - part 3
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 two articles, I described why it’s important to break what would otherwise be a big, risky and difficult to reverse change to your application, into a series of smaller, safer, and reversible changes. I also covered how each developer should strive to break their work into small, incremental changes that are deployed to production at least once a day.
In this article, I describe how to use the concept of smaller, safer, and reversible changes to update production by incrementally shifting traffic to the new version of a service.