Currently, we hear a lot about infrastructure as a code and its evolution to everything as a code. Understanding infrastructure as code to the deployment and provisioning of our infrastructure from code which we can submit to the same quality control as any application code, then …
Why not package infrastructure, communications and application in a single project? Let’s talk about this movie…
A long time ago, in a galaxy far, far away … It is a period of technology war. Rebel DevSecOps, striking from a hidden base, have won their first victory against the evil sysadmin Empire.
During the battle, Rebel DevSecOps managed to steal secret plans to the Empire’s ultimate weapon, the manual deployment Death Star, an armoured manual procedure with enough power to create an entire planet of virtual boxes, but they got a GitHub full of Everything as Code deliverables … Let the force be with you …
How many times have we received the request to enable manual intervention for people through provisioning portals due to ‘we are in a hurry’ ‘time is on top of us’ ‘it’s gonna be faster’? That’s no longer an excuse anymore…
Main benefits of Infrastructure as Code:
The first significant benefit IaC provides is speed, yes, you’re reading well, if you spend some time doing it in a development environment you don’t need to spend the same amount of time recreating it at each environment manually. Infrastructure as code enables you to quickly set up your complete infrastructure by running a script. You can do that for every environment, from development to production, passing through staging, QA, and more. IaC can make the entire software development lifecycle more efficient.
Manual processes result in mistakes, period. Humans are fallible. Our memories fault us. Communication is hard, and we are in general pretty bad at it. As you’ve read, manual infrastructure management will result in discrepancies, no matter how hard you try. IaC solves that problem by having the config files themselves be the single source of truth. That way, you guarantee the same configurations will be deployed over and over, without discrepancies.
This one is quick and easy. Since you can version IaC configuration files like any source code file, you have full traceability of the changes each configuration suffered. No more guessing games about who did what and when.
?? More Efficiency During the Whole Software Development Cycle
By employing infrastructure as code, we can deploy your infrastructure architectures in many stages. That makes the whole software development life cycle more efficient, raising the team’s productivity to new levels.
We could have programmers using IaC to create and launch sandbox environments, allowing them to develop in isolation safely. The same would be true for QA teams, who can have perfect copies of the production environments in which to run their tests. Finally, when it’s deployment time, we can push both infrastructure and code to production in one step.
This is one of the biggest benefits, we can create parametrizable artefacts that we can reuse anywhere and repeat at any time the same stuff.
How does It work?
IaC tools can vary as far as the specifics of how they work, but we can generally divide them into two main types:
- the ones that follow the imperative approach. The imperative approach “gives orders.” It defines a sequence of commands or instructions so the infrastructure can reach the final result.
- and the ones who follow the declarative approach. A declarative approach, on the other hand, “declares” the desired outcome. Instead of explicitly outlining the sequence of steps the infrastructure needs to reach the final result, the declarative approach shows what the final result looks like.
If you think the categories above have something to do with programming language paradigms, then you’re spot on!
Due to the reason above we have selected Terraform (Declarative) for our IaC environment, let’s talk about the benefits of keeping the state of your deployment in next Posts…