If you're a developer, an IT infrastructure engineer, a manager working on some infrastructure automation project, a business professional looking for a lead to begin with the IaC journey, or even just a person keen to know about IaC, then you have landed at the right place!
This blog series will be about Infrastructure as Code, popularly known as "IaC". It will mainly revolve around the available tools, best practices, coding methods with examples, recent trends, and so on.
You can follow through this whole series or skip to the specific IaC topic which you are interested in or looking for.
This blog, being the very first one in the series, will be an introduction to the IaC. We will try to find the exact need of IaC, how did it all start, and what are the approaches to use IaC.
Table of contents
- Introduction
- But, "What exactly is IaC"?
- Why do we need to use IaC in the first place?
- How did IaC come into existence and what's the way to use it?
- Conclusion
Introduction
"Infrastructure as Code" changed the way how we design, build and manage our IT infrastructure. Gone are the days, when we had to build and deploy physical servers and other resources and manage all the necessary configurations manually. It was all quite a time-consuming, unscalable, and ineffective solution, especially to meet the requirements of rapid software development cycles.
Infrastructure, being one of the principal aspects of the software development process, needs to be reliable, robust, available, and should be up and running within a fraction of time. For all these critical issues, IaC comes to the rescue.
But, "What exactly is IaC"?
Wikipedia defines IaC as:
Infrastructure as code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.
So, simply put, IaC is all about Infrastructure automation using code. It is used for configuring and managing the infrastructure in some sort of configuration files, to maintain it in a desired state.
The benefit of having it in the form of code is that it allows users to reuse, reconfigure, and distribute the configurations.
It also allows us to generate and deploy the same infrastructure as many times as we want, or just update the parts we need and a whole new environment is up and running within a few minutes. In short, we can create reproducible infrastructure configurations.
Why do we need to use IaC in the first place?
So, we should better now dig a bit deeper as to what is the need of having IaC, because we, anyways were able to manually create and manage the on-premise and cloud infrastructures very well. Well, to figure that out, let's look at how the scenario was before IaC was introduced and how it is now.
Before IaC
Downsides of this approach:
Repetitive and time-consuming process.
Unreliable and unscalable approach of infrastructure provisioning.
Management and maintenance of the whole infrastructure was a bit of overhead.
Replication of systems to other environments (dev, test, staging, or prod) for enhancements or bug fixes, or provisioning a new environment was quite tedious and difficult.
Changing the configuration of resources was prone to errors, because of the lack of standardization.
Costly to hire and manage a team to handle the infrastructure manually.
Difficult to handle the disparity that could happen when different people performed infrastructure management.
With IaC
Benefits of this approach:
Massively increases the speed of infrastructure deployment and delivery.
A scalable solution.
Operationally efficient, as it doesn't require management of the resources manually.
Replication of resources can be instantly done by reusing the same set of code/configuration in different environments (on-premise and cloud both).
The configuration files/code are considered as a single source of truth, maintaining minimum chances of errors.
Automated product lifecycle, which makes it efficient and cost-effective.
Desired state is maintained throughout the lifecycle of the infrastructure, even if different people work on the same infrastructure since the code/configuration is standardized.
With IaC in place, the configuration can be treated the same way that software source code is treated, allowing version control, test-driven development, CI/CD practices, etc., to be followed.
Long story short
Cloud computing has taken over the world, and the number of infrastructure components has grown immensely. Tons of applications are being released to production regularly, and with this, there is increase in the frequency of infrastructure being spun up, scaled, and taken down. Without an IaC practice in place, it becomes troublesome for the teams to manage the scale of infrastructure requirements.
How did IaC come into existence and what's the way to use it?
History of IaC
Let us see when and how the IaC came into the IT world, and how is it progressing further, as mentioned in a popular quote by Carl Sagan:
"You have to know the past, to understand the present"
The IaC tools came into existence with the very thought of automating some of the configuration management processes. But, later people realized the need of automating the whole procedure of infrastructure deployment and management, along with the configurations.
One of the earliest tools is Puppet, which was released around 2005, and one of the latest ones include Pulumi, which is an advanced tool supporting many programming languages and being developer-friendly. A lot of new features and advancements are yet to be seen in the future to come.
Approaches to IaC:
There are 2 ways of writing the infrastructure as code:
Imperative
The imperative approach is a "procedural" method of defining the set of commands to be run to achieve the desired state. It focuses on "HOW" the infrastructure can be modified.
Declarative
The declarative approach is a "functional" method of defining the desired state of the infrastructure. The steps/flow is not defined in this approach. It focused on "WHAT" the infrastructure should be like.
Based on these approaches, the IaC tools work, and it allows us to decide which one to use for our project.
Conclusion
Infrastructure as Code is the need of the time and will prevail in the time to come. It improves efficiency, productivity, and cost-effectiveness, and provides flexibility, and scalability to the cloud and on-premise infrastructure provisioning and management processes. It delivers the best results when used along with CI/CD, and other DevOps practices.
It has immensely benefitted the businesses which have already started using it, and more such companies are starting their journey to the IaC. As per the HashiCorp's State of the Cloud Survey, conducted in 2021, IaC is expected to be adopted by almost 60% of the enterprises by the next year. So, this is truly the future of Cloud and DevOps.
What's next?
In the next blog in this series, we will look at some of the popular IaC tools and compare them thouroughly. So, stay tuned!
Article by:
Atul Anand, Fellow
JTP Co., Ltd.
