What is Infrastructure as code? / Where is it coming from?
To understand what Infrastructure as Code (IaC) is, we need to understand first where it’s coming from, and why it was created.
How things were before.
Traditionally, when managing the applications server infrastructure, the first step is to design the most suitable architecture for your application, i.e: a simple server to host your application and a database to store the data.
After choosing a provider, everything has to be created and set up manually on the go. Buying the servers, connecting to them, installing or updating the missing dependencies to get it up to date and ready to use, uploading and configuring the app, etc.
Ideally, this whole process should be well documented in an understandable way, so any engineer should be able to replicate it in case of need. But unfortunately, that is not always the case.
Imagine that after a few months you have a couple of hundred users using your product, and you get really scared when realizing new functionalities into production because guess what? Sometimes it breaks! And the system is down for a couple of hours.
The solution would be to create a new environment exactly like production but with no users access, just for developers to try and debug new features. But this means to get another server, set it up manually, deploying the application, etc. And guess what? that takes a lot of time!
Or maybe just want to:
- Upgrade your server dependencies to avoid security issues
- Fix a bug
- Add a new library/dependency
This process becomes a pain because there is no way you can change your configuration easily. You might think, “well, there is a document that explains how to set up a server so it shouldn’t be as painful or time-consuming as the first time”, in theory, that’s right but…
Maybe the app has changed so much after those months that it requires different dependencies or versions that are not in the documentation, or is written in a specific language that is not easy to understand for other team members, or even there might not be any document at all!
But there is a light at the end of the tunnel
Infrastructure as code comes as the solution to all those cases forehead mentioned.: the architecture configuration is code-written in files that will be uploaded to an interpreter service, that will create all those resources for you programmatically.
So in this case, you also start with the first step of thinking about your application architecture design, but the second step is very different.
After choosing a provider, you create some template files compatible with the provider’s interpreter service. Once your architecture definition has been written you just need to upload it to the interpreter service, and it will take care of deploying and configuring all those services for you.
Once everything is set, you can upload your code separately but there are interesting tools to deploy your code in the process, so you can deploy all at once.
This provides the possibility of creating new environments easily from the same piece of code, that will be identical to the production environment to be able to debug an error or try out new features. Furthermore, those files are usually stored in a version control system, so all the team can have access and be synchronized and it gets really easy to roll back to a previous configuration if you want to get rid of an issue you didn’t spot before or just ditch a change.
Many cloud providers offer this option to manage their services, i.e: AWS CloudFormation, Azure Resource Manager.
This has opened the market for “provider-agnostic” tools such as Serverless Framework and Terraform that allows you to write your infrastructure code once, and it will be translated into any provider you want to deploy to! 🤯
In conclusion
Teams who adopt IaC are able to build, deploy and replicate faster and more trustable environments where the “it works in staging but it fails in production” situations are not in the table anymore.
That’s what we do in The Agile Monkeys, we always bet for the most trustable and resilient technologies, to maximize the quality of everything we build.
We really encourage you to step into the IaC world if you're interested in DevOps, it is really a game-changer!
Latest comments (0)