What Is Infrastructure as Code (IaC)?
Put in the simplest terms, infrastructure as code means using code, you define
the infrastructure that needs to be deployed in a descriptive model. Similar to
code for applications, the code for the infrastructure becomes part of the project
and is stored inside your version control system (or VCS).
For example, consider that you have developed a web application. That web
application needs to be hosted on infrastructure somewhere to be consumed.
Using IaC you could define things like where the infrastructure is deployed to,
such as a public cloud provider like Microsoft Azure, Amazon AWS, or Google
Cloud, and what type of service your web application will run on, such as an
Azure web app, or an AWS S3 Storage account. Further to this, you can then
define the settings required for the web app, which might include things like how
much server compute power is required (in terms of CPU and memory), how the
networking is secured, and how the domain name for your app will be exposed,
to name a few among many other considerations.
Benefits of Infrastructure as Code
Infrastructure as Code solves several key problems in managing IT infrastructure
by automating and standardizing provisioning processes. It eliminates manual
configurations, reducing human error and improving consistency across
environments. IaC also addresses configuration drift by ensuring that
infrastructure remains aligned with the defined source code over time.
Here are the key benefits of using IaC:
1. Simplified provisioning: New environments or infrastructure can be
provisioned easily from your IaC configuration code.
2. Repeatability: Infrastructure deployments are consistent and repeatable,
ensuring no discrepancies between environments.
3. Scalability: Manually configured environments are difficult to scale. With
environments provisioned using IaC, they can be deployed and scaled
rapidly.
4. Change management: If you want to make changes to the existing
infrastructure that has been deployed with IaC, this can be done in code,
and the changes will be tracked.
5. Environment drift detection: When IaC is used with a declarative tool (it
describes the state you want your environment to look like), you can detect
and correct environment drift. If a part of the infrastructure is modified
manually outside of the code, it can be brought back in line with the
desired state on the next run.
6. Idempotence: Changes can be applied multiple times without changing the
result beyond the initial application.
7. Error prevention: With IaC, you can avoid manual configuration of
environments, which can typically introduce mistakes due to human error.
8. Consistency: IaC is a means to achieve consistency across environments
and infrastructure. The code can be reused.
9. Cost efficiency: Infrastructure costs are lowered as the time to deploy, and
effort to manage, administer and maintain environments decrease.
10. CI/CD integration: IaC can be used in Continuous Integration /
Continuous Deployment (or CI/CD) pipelines. The main benefit of doing
this is to automate your Infrastructure deployments.
11. Early testing: DevOps teams can test applications in production-like
environments early in the development cycle.
12. Version control: With your Infrastructure configuration code held in
your version control system alongside your application source code,
commonly in the same repository. Now everything can be held together.
13. Increased productivity: Productivity will increase due to a
combination of all the benefits of using IaC.
14. VCS benefits: As the code is held in your version control system, it
gains all the benefits of the VCS. More on that in the next section.
Challenges and Limitations with IaC
The adoption of IaC is not without its challenges.
Typically, traditional infrastructure or operations teams within organizations may
not be familiar with version control systems, use of Git, or be comfortable using
tools for code editing such as visual studio code.
Further to this, there is certainly a learning curve when it comes to the adoption
of new technology within an organization. Training will be required and time will
be needed to develop the appropriate skills.
Skills in IaC and DevOps are currently highly sought after in the industry and so
therefore it may be difficult to hire staff with these skills.
The journey to managing your environments using IaC will typically start with a
small deployment of new resources to your chosen cloud platform, and from
there once adoption within the organization grows, more of your infrastructure
can start to be deployed and managed in code. Eventually, when your
organization is mature and comfortable with the principles and operation of your
chosen IaC systems and tooling, existing resources can be brought under IaC
control.
Check out this video where we explore the issues related to managing IaC at
scale:
Why Should I Store My Infrastructure as Code
in a Version Control System (VCS)?
Without diving too deeply into the benefits of using a VCS in this article, we will
summarise them here as storing your IaC in a VCS automatically gives you a raft
of additional benefits.
In summary, a VCS enables developers and organizations to work more
efficiently in improving the quality of their product while recording and evaluating
a detailed history of their improvements that will lead to a successful end product.
In short, using a VCS enables governance, versioning, and increases
collaboration.
1. Efficiency
As configuration files are amended incrementally with changes, testing becomes
easier as rollback to previous versions is possible. New features can be built up
over time.
2. Tracking & Versioning
Track who made the change, and in which version of the file. Comments can be
added to each code change (or commit).
3. Collaboration
Multiple people can work on the configuration files at the same time using
branching. Changes can be merged together using pull requests.
4. Governance & Compliance
Tracking changes automatically gives you a powerful audit trail, enabling risk
management.
5. Management
A management overview becomes possible through being aware of the author of
the configuration, how long it took to make changes, the timeline and its impact.
6. Reduces Duplication
Multiple and out-of-date configuration files are reduced.
7. Backup
Users will typically clone the repository their configuration code is held in and
work on it locally. The code then exists locally and in the VCS. The VCS itself is
also backed up.
Declarative vs. Imperative Approaches
There are 2 approaches to the templates used when writing IaC configuration
files. Different tools use different approaches, which are listed in the next section.
Declarative — you define the desired state of the final solution.
The tool or automation platform determines how the goal is reached, the step-by-
step executions are handled by the tool and hidden from the user. Declarative
tools are the most popular and most dominant in the IaC space. They are most
useful when changes or updates need to be made to your solution.
Declarative tools are idempotent because you are defining the required state of
the solution. Idempotency refers to a process that can be executed multiple times
with the same result.
Imperative — you define the steps to execute in order to reach the desired
solution.
An imperative approach allows you to build up multiple layers of commands to
reach the end goal. Imperative tools give you more control over how the goal is
reached. These tools are most useful when you need to deploy and not update or
change the solution in the future.
Imperative approaches may not lead to idempotency, the end goal may be
different depending on the starting point, as a series of steps form the process.
Consider a process with 10 steps, for example, starting from step 1 would lead to
a different result compared to starting with step 6.
