Microservices rules #10: Make smaller, safer, and reversible changes - part 1
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.
It’s quite common for software developers to make large, risky, and irreversible changes to their applications. An organization might, for example, spend months, or even years, doing a big bang modernization of their application. Nothing is released to users until the entire application has been rewritten. Moreover, users are often migrated to the new application in one go. At which point, everyone discovers that the new application is full of bugs and performance problems. The organization then spends months or years fixing the problems or scraps the new application entirely.
These problems occur to the intrinsic nature of software development. Software development is a series of a design decisions. Later decisions are made in the context of past decisions. The problem is that when you developing a complex application mistakes are inevitable. It’s essential to validate design decisions as soon as possible. Otherwise, you risk needing to do a significant amount of redesign.
What’s more, mistakes aren’t just limited to architecture and design. Bugs of all types are inevitable; coding, configuration, , etc. As a result, it’s important to make small changes to production that are easy to detect, diagnose, and reverse. Otherwise, you and your users are likely to suffer.
A much better approach to software delivery is 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. There are numerous ways to apply this idea. In this article, I describe how to apply this idea to application modernization. In later articles, I’ll apply this idea to other aspects of software delivery.
Let’s start by looking at the big bang rewrite (mostly) anti-pattern and why it’s appealing despite its drawbacks.