Stability comes from making changes - A tale of Infrastructure as Code
When mentioning code, it’s commonly understood as application code. What about the system your application runs on? Infrastructure as Code(IaC) applies the same software engineering principles used for application code to the infrastructure. Simply put, it means to codify your IT infrastructure to better manage large-scale, distributed systems and cloud-native platforms. In this article, I talk about the need for dynamic infrastructure to be able to handle change and point out some of the common objections to Infrastructure as Code.
The only constant in life is change - Heraclitus
In a production system, changes possess the biggest risk. However, changes are also inevitable due to the pace of agile engineering projects. Therefore, making changes is the ONLY way to improve the resiliency of your cloud infrastructure.
In the traditional approach, an application developer “asks for” an infrastructure for their code to run by opening a ticket. A team of operation folks provision that infrastructure either manually or running some scripts (which are customized to each ticket request). Now imagine a large team of developers working on a product that requires them to tear down the infrastructure frequently and provision new ones. The manual ticketing approach would soon become a bottleneck as the project would scale. With the wide adoption of the cloud, speed cannot be compromised when allocating required resources to the development team. This calls for a dynamic infrastructure where:
- System configuration is not only written as code but also version controlled
- Systems are provisioned and torn down frequently
- Change is expected rather than controlled
If you’re already planning to pitch about Infrastructure as Code to your customers, here are three common objections you might face:
“We don’t make changes often enough to justify automating them”
Your production code likely has many dependencies. Even if the code for one particular component does not change, one cannot ignore the possibility of changes in other parts of the application, or the platform, or the infrastructure. Some common examples of changes:
- Performance profiling shows that the current application deployment architecture is limiting performance. You need to redeploy the applications across different application servers. Doing this requires changes to the clustering and network architecture
- Your webservers experience intermittent failures. You need to make a series of configuration changes to diagnose the problem. Then you need to update a module to resolve the issue
- An essential new application feature requires adding a new database
“We should build first and automate later”
Automation should enable faster delivery, even for new systems. Adjusting to the Infrastructure as Code model for an existing system offers a much steeper curve than greenfield automation. Automation is a part of a system’s design and implementation. To add automation to a system built without it, you need to change the design and implementation of that system significantly.
We don’t have a < insert your favorite IaC tool here > expert and our system is running JUST FINE
This is similar to the above point where your design vision should encompass future scalability. Just because your team can work through manual provisioning does not guarantee that there won’t be future bottlenecks. If your team is in the business of building software products on the cloud; investing time/$$$ on people who can support the IaC journey will be one of the best investments you can make.
- Define everything as code; even the system that your applications run on.
- Changes are inevitable. Embrace changes by embracing a dynamic infrastructure.
- Understand the objections towards IaC and prepare to reason with those.
If you liked this article, please give me a shoutout.