The world of IT Operations has been changing in many ways over the past few years. The rise of public cloud created an urgency for traditional operations teams to adapt their own systems and processes to either embrace a public cloud infrastructure, or to create a more cloud-like experience with their internal infrastructure to keep pace.
Public cloud is on a rocket rise in adoption but will not unseat every data center regardless of the rate of adoption. Many data centers are moving towards managed colocation and on-demand providers, mostly because it opens the door for more programmatic approaches to building and managing infrastructure and removes the overhead of managing environment (e.g. power, cooling).
Infrastructure-as-Code, or IaC, has become one of the most dominant features which allows for the accelerated and more consistent management of on-premises or public cloud infrastructure.
What Problems does Infrastructure-as-Code Help to Solve?
Codifying infrastructure allows for many advantages. Each organization may have specific targets for speeding up deployment or reducing the cost and overhead of day-to-day operations. Collaboration between teams such as development and operations folks, means reducing the friction and delay when standing up new infrastructure to build and deploy applications. After all, the prominent reason IT exists is to get business applications to production.
IaC tackles a lot of these challenges and delivers many valuable advantages including:
- Consistency of outcome – ensuring the same build processes occur every time across every environment (e.g. dev, QA, production)
- Collaborative processes – sharing a code base for IaC allows many team members to use a common and consistent approach
- Rapid Deployment – representing infrastructure as code enables automation and more rapid iteration when designing and deploying infrastructure
Infrastructure-as-Code is a Process, Not a Product
You may quickly jump to naming products when you think about what IaC is for you and your team. Products like Ansible, Terraform Chef, Puppet, and others are synonymous with Infrastructure-as-Code but often in different ways. This is where identifying the lifecycle phase helps to narrow down how to leverage IaC.
I like to look at Infrastructure-as-Code processes across three distinct phases:
- Build / Provision – the initial creation and provisioning of infrastructure and applications
- Configuration Management – managing and configuring infrastructure continuously
- Lifecycle management – systems which handle approvals and processes for deploying and de-provisioning infrastructure and applications
There are three phases because the processes you use are often specific to a particular use-case or part of the overall lifecycle of an application.
Building, testing, and deploying tackles the initial implementation. Configuration management is more about the ongoing processes as applications run which may including adding and removing resources, updating libraries, patching, etc.
IaC as a Phased Approach
You don’t need to be a card-carrying DevOps engineer to get value from IaC and the associated processes. Starting small is exactly how you will get better and more consistent adoption. By creating codified infrastructure, you enable consistent deployment processes with accountability for who and how it is built. That accountability and consistency allows the automation of these processes because you can trust the outcome. Automation then delivers the ultimate goal of increasing velocity inside your IT organization.
Pick a single application in your environment and think about these three phases of codifying and automating the process.
Phase I – Automate Provisioning of Dev/Test/Prod
Your first goal is to codify your application and the underlying resources. This could be using products like Terraform, CloudFormation, or Puppet for example. Building and deploying the infrastructure consistently using code means quickly getting your environments up and running. The same code can be used across the different environments as well. No more “it worked in my dev environment” as an excuse for why something acts up in production.
Bring your developers into the process too. This is the chance to collaborate on what the real requirements are for the application. The consistency and speed of provisioning will bring both time and cost savings.
Phase II – Performance, Patching, and Security
You’re building apps with code now. But that means you need to adapt continuous operations to match the speed and consistency of the initial deployment. This is where you leverage platforms like Turbonomic for continuous performance and resource management because you need performance with consistency and automation has to be a priority to get the most out of the apps.
Patching and security are also now able to be codified so that it’s not just DevOps but DevSecOps capabilities you are unlocking. Ensuring the network and security are wrapped inside your codified infrastructure will ensure the consistency and accountability extend to every aspect of the business and application requirements.
This is where you will see Ansible, Puppet, Chef, and SaltStack coming into play more. Each of these four products have some ability to do initial provisioning but are more geared towards continuous configuration management. They are also all open source which has additional advantages.
Phase III – Full lifecycle for a single app/environment
This is where you connect together all the parts. You’ve built your application using a programmatic method and have enabled the patching of the systems it operates on. The last phase will be putting the lifecycle process into a service desk or automation framework. Leveraging your service desk (e.g. ServiceNow, Remedy) for approvals and workflows takes the newly codified infrastructure a new level.
Now you can have your team members request resources and have the lifecycle management from implementation to operations to decommissioning all centralized into an auditable and automatable process. Pretty cool, right?!
Speed Needs Reliability and Consistency
Moving at the speed of business is not just about speed. Speed without reliability and consistency is reckless and risky. You’ve started with a single application in this example and you will quickly see how you can adapt other applications and processes using the same tools and techniques. Start small and reap the benefits. Then you will quickly find that the teams will want to accelerate adoption and automation. You can finally put that engineering talent back into innovation and get them out of the war room troubleshooting inconsistent application issues and performance.