Microservices rules #10: Make smaller, safer, and reversible changes - part 1
This is the third 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 2 - continuous delivery/deployment
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.