The term “Infrastructure-as-Code” is often associated with DevOps. But if you’ve ever wondered what exactly is involved, and how it can benefit your enterprise, then read on…
Why you need Infrastructure-as-Code
Cloud computing, containers, virtualization and software-defined networking (SDN) have all reduced the time and effort needed to provision systems. The problem is that along with this simplicity of provisioning came growth in the numbers and scale of portfolios. This, in turn, led IT operations teams to experience considerable difficulty maintaining their infrastructure and its configuration. The majority of enterprises still configure much of the infrastructure and applications manually, which I don’t need to tell you is time-consuming, error-prone and complex. I might also add that it’s an unsustainable way of doing things, too, when you consider the future of systems management is getting more complex, not less. That’s where Infrastructure-as-Code comes in.
Infrastructure-as-Code (IaC) is the mechanism to create and apply changes to the system by treating it as software data. With IaC, the environment is managed and provisioned through templates and definition files, rather than physical hardware configuration or interactive configuration tools. The beauty of this approach is that it consists of creating consistent and repeatable routines for changing infrastructure state and configuration of the infrastructure. Being code itself, it can be versioned by making it part of a Version Control System. This allows it to take advantage of development practices like test-driven development, continuous integration and continuous deployment (CI/CD).
What you need to know about IaC
Much discussion has focused on this topic. There are papers, books and hackathons devoted to the subject, but here’s our quick take. Bear in mind there are three key practices to master if you’re serious about IaC:
1. Every configuration should be part of the configuration code; no one should be able to login to the system and make changes manually. This practice makes sure that both provisioning and configuration are repeatable and consistent.
2. Code itself becomes a self-explanatory document and process. Prior to IaC, every configuration had to be released with a document, which every deployment engineer was required to follow as part of release or provisioning.
3. Small changes should be applied to code rather than big batches. The bigger the configuration update, the more likely it is to contain an error, and the more difficult it is to detect errors.
What are the benefits?
Where do I start?
Popular tools for getting IaC up and running include Chef, Puppet, Terraform, AWS CloudFormation, Microsoft Azure Resource Manager, Ansible, SaltStack, Docker and Vagrant. Infrastructure-as-Code is often viewed as part of a wider DevOps transformation, so if you want to ensure you’re choosing the best tools to integrate, say, with your CI/CD or other DevOps initiative, why not get in touch? Our impartial guidance is based on 13+ years of experience!
Continuous delivery has become fundamental to business agility in the digital age. Accelerating release cycles enables organizations to meet increasing customer demand, respond to...
“We’re not ready for such a big change to our application development.” “Not another software upheaval!” “I can’t find the budget or the resource to make the...
How do you build a DevOps team from scratch? Or even, how do you improve the efficiency of an existing team? Hiring a DevOps specialist seems an obvious place to start. Budget and...