As the DevOps culture grows, the term “Infrastructure as Code” or “IaC” becomes so popular.
In this blog post, I’ll try to simplify the need for infrastructure as code, what it does, and the challenges it resolves.
Why does it matter?
If you’re one of those old-school IT engineers who used to manage servers in traditional datacenters, you probably understand how difficult and time-consuming it was. Even if you’re not directly responsible for racking up servers, routing cables, and installing any additional piece of hardware, you still have to write and maintain the configuration documentation and invest so much of your time in installing & configuring OS, deploying software, updating & patching the systems, etc.
On top of that, what if your organization wants to leverage the power of the latest technologies? Then, you must perform upgrades of older hardware and software to cater to changing business needs. It really requires huge planning to define the end-to-end upgrade process without having an adverse impact on the running infrastructure, which ends up with a huge expenditure in terms of cost, time, and human efforts.
And then the cloud & virtualization together have taken up these challenges. With cloud & virtualization, you just have to pay for the instances (hardware & software) consumed without worrying about the underlying platform’s maintenance and upgrade, patching, etc. Cloud & virtualization give you the freedom of provisioning servers, databases, applications, and other infrastructure components efficiently. So, technically, this should simplify the IT operation work. IT engineers now should spend less time on fixing those long-standing issues and have enough time to plan their upgrades, migrations, improvements over existing infrastructure, and testing disaster recovery scenarios to help their organizations keep up with the ever-changing needs of the modern IT world.
But even with the latest and greatest tools available, systems aren’t configured in a way that is more consistent and reliable. In fact, these latest tools often introduce a new set of problems, which makes it even worse. The ease of provisioning infrastructure, configuring systems, and deploying software, patches, etc. has largely increased the systems portfolio, which requires a lot of time to keep it updated and away from breaking it completely. This is even riskier while performing an automated task, which is difficult to control and can potentially collapse everything.
To overcome such challenges, it takes people to think and apply some standards, practices, and governance in place that don’t come out of the box with software. Some organizations leverage change management in response to these challenges, but while the change management struggles to handle the changes offered by cloud, virtualization, & automation technologies, it still needs a major improvement over how it manages, documents, and audits the ever-changing landscape of infrastructure components, and this is where “Infrastructure as Code” practices help businesses to cope with the ever-changing nature of IT Word.
What is an IaC?
As the name implies, Infrastructure as Code, or IaC, is the concept of applying software development practices to infrastructure, which means transforming an infrastructure component into machine-readable yet simple-to-understand code (like JSON, RUBY, YAML, etc.) so it becomes testable, repeatable, and auditable using the same versioning systems (such as GIT, Bitbucket, etc.) as the DevOps team uses for source code management.
Infrastructure as Code (IaC) provisions, configures, and manages infrastructure (virtual machines, packages such as software, drivers, updates, etc., networks, security policies, load balancers, and other infrastructure components) in the form of code, documented well in templates or scripts. These can then be automated by utilizing a CI/CD (Continuous Integration & Continuous Deployment) pipeline, in the same way it’s used for application code testing, integration, and deployment. IaC templates/scripts typically follow a declarative approach, meaning you specify the desired state of an infrastructure component’s configuration, and the IaC tool automatically handles the implementation to achieve that desired state.
Idempotence is the key principle of Infrastructure as Code. An idempotent operation can be repeated an arbitrary number of times, and the result will be the same as if it had been done only once. In arithmetic, adding zero to a number is idempotent. Idempotency is accomplished by either configuring the current system to match a defined desired state or by discarding the existing environment and creating a new one from scratch.
Benefits of IaC:
There are many benefits of using IaC; below are the major ones:
Single source of truth:
With IaC, an IT engineer defines the desired state of configuration in the form of code documented well in a template or script. For example, to install an IIS server and enable & start a service, you can write up fairly simple code and version it appropriately using version control systems (VCS). If there is a newer version of IIS available, you’re just required to explicitly mention the version in a code instead of changing a configuration on targets. If you’re using VCS, then you can bump up the version of your code file (cookbooks for CHEF, playbooks for Ansible, etc.), and the next time your IaC tool runs, it’ll apply the latest code to upgrade an IIS to the latest version specified, thus providing a single source of truth for your infrastructure configuration.
Consistency:
If your infrastructure is relatively small and you’re the only IT administrator to maintain it, then you probably configure the infrastructure as ideally as possible. But if your infrastructure is big enough to have multiple IT engineers to maintain and support it, then you can’t guarantee the same kind of configuration applied to the systems. Also, you may alter some settings to fine-tune one of your web servers to cater to the increased traffic, which leads to the inconsistency in the infrastructure configuration. But with IaC, you can apply the exact same configuration to as many nodes as you want by just applying the templates/scripts, and you can also easily roll back to the previous version of the infrastructure stack if any anomalies are found.
Scalability & Reliability:
Using IaC, you can deliver stable environments rapidly and at scale. This helps to avoid manual configuration of environments and enforce consistency by representing the desired state of your infrastructure via code. Infrastructure deployments with IaC are repeatable and prevent runtime issues caused by configuration drift or missing dependencies.
Minimum expenditure:
IaC provides the way to thoroughly test the infrastructure before it replicates to production environments, thus minimizing the production downtime and the operational cost as well as the time required to upgrade a production system.
CI/CD & Versioning:
Teams that implement IaC generally use continuous integration and continuous delivery pipelines the same way they’re used in software developments to test, build, and deploy the code. Together with CI/CD pipelines, a version control system (VCS) can be integrated to version the infrastructure code that creates a set of versioned infrastructure stacks, which is an easy rollback approach.
Compliance:
An IaC template or script can be used to deploy the security best practices identified by NIST/CIS to harden the systems, thus achieving a higher level of compliance and proactively mitigating the security loopholes at all times.
And then there are drawbacks too:
Along with the benefits, a technology or tool has some kind of drawback; have a look at the below ones:
Specialized Tool:
To implement IaC, you need to have some sort of configuration management tool. Tools like Chef, Ansible, Puppet, and Salt predominantly lead the IaC revolution, and they require an appropriate working culture to support the functioning of the tool of your choice.
Learning Curve:
Infrastructure as Code is a new concept that brings together two different skill sets (operations and development). You must have skilled resources to carry out the transformation of infrastructure into code. This involves a significant learning curve and can lead to many mistakes, particularly in applying code designs and patterns, code security, code adaptability, etc.
DSL:
Learning to code is not enough. There are multiple moving parts in IaC, and almost every tool used to implement IaC has its own Domain-Specific Language (DSL). Learning the DSL is a must to leverage the full power of the tool of your choice.
Infrastructure as Code is indeed the future of how IT infrastructure is provisioned, managed, and monitored, though it also presents some challenges to mitigate. However, with appropriate planning, execution, and a thorough understanding of the tool itself, an individual or organization can effectively cope with the ever-changing dynamics of business and technology.
Happy coding!