The ReleaseTEAM Blog: Here's what you need to know...
What the hex is going on
How Does IaC Work?
Infrastructure as Code helps automate the configuration and deployment of systems through the use of configuration files. There are two main approaches to Infrastructure as Code: imperative and declarative.
- Imperative IaC is a sequence of commands used to provision the resource. It defines what should happen at every step, which creates a "known" state for the resource. If you're looking to control every aspect, imperative is a good choice.
- Declarative IaC describes the desired end state but doesn't tell the program the exact steps to get there. Declarative IaC scales better than imperative commands.
Still confused? Let's substitute a person for the program to understand the differences better. Let's say you hired an employee to cook, assemble, and serve hamburgers. In an imperative environment, you'd give the employee a checklist that the employee would have to follow in order to create your restaurant's famous hamburger. They would not be allowed to deviate from that checklist, so if they didn't have the tomato available at the right time, production might halt until the tomatoes were found. In a declarative environment, you'd show the employee what a "successful" hamburger looks like, and the employee would be trusted to put it together and adapt to changing inputs -- as long as the end product was your restaurant's famous hamburger.
As your environment scales, it becomes more and more difficult to predict every situation that your program may encounter. Imperative IaC may not be the best fit for those environments.
Why IaC for DevOps?
DevOps seeks to automate repetitive tasks, reduce errors, continuously monitor, and continuously improve. These goals enable shorter development cycles with fewer errors. Infrastructure as Code removes the manual steps involved in provisioning servers and resources.
Improved Productivity:Removing the manual steps and dependencies on human admins means developers get the resources when they need them instead of waiting.
Increased Time to Market: Automating repetitive tasks - like provisioning servers - can reduce downtime for developers, testers, and deployment engineers. This allows them to focus on the activities that provide value.
Less Configuration Drift: Because configuration files are used, and human error is removed, developers can count on the infrastructure acting in a specific way. And, because the configuration files are subject to the same DevOps processes of testing and continuous improvement, there is no need to wait for manual change management approvals.
Reduced Costs: Because IaC does not depend on admin labor, your organization can quickly provision resources without the need to hire additional admins.
Traceability: IaC configurations are easier to trace and monitor because the program executes in a predictable manner. However, you may need new monitoring tools that can keep up with the speed of IaC versus the monitoring tools you used when admins provisioned servers manually.
These tools can manage physical resources (bare metal, network, servers, storage), virtual resources, and operating systems.
IaC falls in with many other great technologies that can, along with DevOps principles, enhance repeatability, time to market, and overall productivity. It's like peanut butter and chocolate – they both stand on their own but are also great together.