One of the things I learned early on is to design systems that allow for easy ongoing change. How? Cloud or non-cloud system, you build for change by compartmentalizing system components so that they can be configured or changed on their own. A simplistic analogy would be how we can interchange car parts to mix and match system components, having the ability to replace or update components without redeveloping the entire vehicle.
Other approaches leverage services and microservices to centralize and reuse some application behavior and data. This means that updating a specific service in a single location will change the behavior of all systems using that service, for instance, replacing a tax calculation, changing a database model, or even updating a component’s enabling technology, such as moving to containers and container orchestration.
Thus, we have the ability to easily change a system to accommodate a business need without undue latency, cost, and risk. The trouble with this approach is not that it’s complex and difficult to carry out. It seems that many of those charged with architecting and building these net-new systems in the cloud are not making the ability to easily change their systems a priority in the overall design.
I understand why. When money is tight, time is short, or other obstacles get in the way, good system design practices are often cast aside. Although it’s easy to make the case that any effort and money put into designing a flexible system will come back to the business a hundredfold, it’s still a difficult argument to win when other pressing priorities take away focus on best practices. And the ability to design a system that’s dynamic and built to change to address any needs of the business is definitely a best practice.
How do we solve this problem? It’s an issue with people and culture as much as with technology. Indeed, this is about establishing expectations that systems are to be designed using this best practice. Moreover, you should set up policies and testing to ensure that designers and developers are designing and building cloud-based systems that can easily change.
This is much like the security and performance checks that we place in our devops toolchains these days. At the same time, check for design patterns that promote easy change and offer the ability to better improve the cloud-based systems that are being built and deployed.
Trouble doesn’t appear with the first generation of the cloud systems. However, when they must be changed for a business need, in many cases the design of the system will force a complete redevelopment and delay the needed change. If this happens even a single time, you’re removing business value from that cloud-based system.