Infrastructure as Code is becoming more and more important in the DevOps Context, due to the many benefits it brings.
Today I have for you a quick intro to the topic, so you can understand what it is and why more and more companies and developers are looking into adopting it.
I will not go into specific languages and tools but let me know in the comment section below if you'd like me to create another post, video, or a series about specific implementations.
Video
As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation.
Link to the video: https://youtu.be/fE4gY-SydKo
If you rather prefer reading, well... let's just continue :)
What
Infrastructure as Code (IaC) is the management of infrastructure (networks, virtual machines, load balancers, and so on so forth) in a descriptive model, using the same versioning as DevOps team uses for source code.
Like the principle that the same source code generates the same binary, an IaC model generates the same environment every time it is applied.
Why
Thanks to this, Infrastructure as Code solves the problem of "environment drift".
Without IaC, teams must maintain the settings of individual deployment environments. Over time, each environment ends up having a unique configuration that cannot be reproduced automatically. Inconsistency among environments can cause issues during deployments, and administration and maintenance of infrastructure involves manual processes which are hard to track and contribute to errors.
With IaC, instead, teams make changes to the environment description and version the configuration model, which is typically in well-documented code formats. The release pipeline executes the model to configure target environments. If the team needs to make changes, they edit the source, not the target.
Additionally, IaC enables DevOps teams to test applications in production-like environments early in the development cycle. These teams expect to provision multiple test environments reliably and on demand. Infrastructure represented as code can also be validated and tested to prevent common deployment issues. At the same time, the cloud dynamically provisions and tears down environments based on IaC definitions.
Teams who implement IaC can deliver stable environments rapidly and at scale. They avoid manual configuration of environments and enforce consistency by representing the desired state of their environments via code.
Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies.
DevOps teams can work together with a unified set of practices and tools to deliver applications and their supporting infrastructure rapidly, reliably, and at scale.
These are the reasons why IaC is a key DevOps practice and is used in conjunction with continuous delivery.
Conclusions
We should now have a clearer understanding of what Infrastructure as Code is, and of the benefits it provides.
Let me know in the comment section below if you have any question about IaC and, as I've mentioned before, if you'd like me to make another post or video about a specific tool or framework for Infrastructure as Code.
Like, share and follow me 🚀 for more content:
📽 YouTube
☕ Buy me a coffee
💖 Patreon
👕 Merch
👦🏻 Facebook page
🐱💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
Latest comments (2)
What are your thoughts on IaC security?
Traditionally security teams were in charge of hardening the environment where the application runs. With IaC should some of those items be considered by developers when they start building the app? If they're too relaxed they could find that security puts restrictions in place and the application will need some refactoring to reduce the attack surface.
I start from the idea that security is extremely important, and because of that it should be applied as soon as possible in the development process. (aka "Shift left on security")
And this applies also to infrastructure. In a "traditional" approach what you describe is the norm, but to me it is too late to apply security. Don't get me wrong, things like pen-test, red/blue teams, etc are still very important and should be applied continuously...
But with IaC teams have the change to ensure the environment is secure and secured even before it is created. Dev, Ops, and Security teams should collaborate from day 1 of the development on any and every aspect of the "application development", and that includes infrastructure.
They can use processes like Code Reviews in PRs for IaC, testing often, etc, and tools that can help you identify problem and issues in your IaC scripts and models (many tools nowadays can do that).
This is how REAL DevSecOps works. I know it sounds "too good to be true", but this is what I help the clients I work with achieve, so I know it is possbible and it works because I do it on daily basis :)