By: Dave White On: October 15, 2020 In: Uncategorised Comments: 0

We have all heard the saying that “the cloud is just someone else’s data center.” While there is some truth to it, if all we do is manually lift and shift our VMs, this approach misses the myriad opportunities that the cloud operating model presents. For example, one of the key changes that the cloud brought us was the wholesale automation of the entire IT stack via full-service APIs. Building on traditional ad hoc automation approaches, like unattended software installs and scripting configuration changes, this new approach introduced a unified all-encompassing automation methodology. One that applies for every resource and service in a given cloud, rather than unqiue approaches for each. Put simply, APIs made it possible to combine the scripts, tools, and workflows that we use to automate disparate systems into a few workflows, or if we are lucky, just one. This workflow and the new approach that these tools enable are what we refer to as Infrastructure as Code, or IaC.

Now, automation tools are not new. In particular, configuration management tools like Ansible, Salt, Chef, and Puppet have been commonplace for some time. While these tools are still relevant and can certainly form a critical part of your strategy, it isn’t the tools that make up IaC. Rather, what sets IaC apart from traditional infrastructure automation is an automation-first approach combined with a methodology centered around a version control system, or GitOps. This unique combination offers significant benefits across a range of environments.

The Infrastructure as Code Model

In an IaC model the goal is to have all aspects of the infrastructure deployed, configured, and managed by tools that get all of their instructions from text files. These text files make up the “code” in Infrastructure as Code. The idea is that changes to the infrastructure are not made on the infrastructure systems themselves but to text files that the IaC tools read to update the state of that infrastructure. Once you have a definition of your environment as a collection of text files, you can check those files into a version control system like Git, which provides visibility, oversight, versioning, and collaboration advantages. It also introduces a range of new workflow options like Pull Requests (PRs) for oversight and peer review of changes.

There are many advantages to storing your infrastructure state in text-based templates:

  • The current state, past state, and proposed future states can easily be read in text format by anybody on the team.
  • States can be programmatically compared using diff tools to identify changes over time.
  • Changes to the environment can be audited with ease for compliance or governance reasons.
  • The infrastructure being used for environments from development to production can be verified to be the same. This eliminates configuration drift between UAT and Production and means that many unexpected production outages can be avoided.
  • If infrastructure is only deployed from versioned “code,” then roll back to the last known state or deployment of a known good and tested state are trivial. This reduces the time to recover from unexpected outages.
  • It allows for programmatic workflows, namely CI/CD pipelines, to take over from SSH/RDP jump hosts and manual configuration changes. This reduces the possibility of human error and significantly cuts lead times for application or infrastructure deployments.

IaC Isn’t Just for Cloud Environments

In its most basic form, IaC could include Bash, PowerShell, or similar scripts that are used to deploy or reconfigure systems. However, newer IaC tools expand that capability with idempotent declarative template-based workflows. Tools like Terraform, Ansible, CloudFormation, Helm, and many more give you additional functionality and provide a stateful system that makes managing configuration changes much easier than with traditional scripts.

While many of these new tools can be said to be Cloud Native and a few, such as Google Deployment Manger, are platform specific, IaC is by no means limited to cloud environments. In fact, using IaC to tame the complexity of deployment and configuration management in the datacenter is the ideal first step before tackling a move to Hybrid Cloud. Compute, Storage, Database, Network, and all the traditional disciplines of IT can benefit greatly from IaC tools and methodologies. In fact, most of the manufacturers of these systems provide all the APIs you need to make that happen.

Infrastructure as Code in Hybrid-Multi-Cloud Settings

As we have seen, IaC offers significant benefits in cloud environments. It can easily be applied to on-premise infrastructure to extend those advantages to traditional workloads as well. While there are significant advantage in both those areas, having a single management approach and set of tools across all your environments in a Hybrid-Multi-Cloud setting is absolutely critical. First and foremost, Hybrid-Multi-Cloud is not easy. With disparate tools and the need for a host of unique skills and expertise across each platform, it can be a serious challenge to find and keep enough specialists to cover all these areas. With all that complexity you need to reduce the risks inherent in managing distributed systems while finding a common set of tools, approaches, and workflows to manage all those environments so that your team(s) can work together effectively.

Conclusion

Ask yourself, how many outages have you experienced that were caused by people working at cross purposes? We have all seen this situation. One individual scripts a deployment while someone else logs in manually to change application settings. Does that change get tracked and does that setting change make it back into the script?  More often than not, the change doesn’t, becoming a timebomb waiting for the next deployment.

How many seemingly endless pre-deployment meetings have you sat through while each team goes over its own workflows? Each of these workflows need to be explained and then harmonized for a successful deployment. What does that do to your desire to deploy again anytime soon?

By standardizing your environments, builds, tests, deployments, configuration management and your approach to wrangling all that complex infrastructure using an IaC approach, you can reduce human error, eliminate the strife between teams, and shorten the lead time from business idea to customer value. Perhaps more remarkably, you can drastically reduce long-term management effort. To reap those long-term rewards however, you do need to invest time up-front and learn some new skills.

IaC is a big topic and certainly it is easier to talk about than to do. That said, it can and is being done all around the world by organizations like yours. Most importantly, when done well, it fundamentally changes the way an IT department delivers value to the business. It takes some discipline to make the switch, and organizations who rush headlong into an IaC approach often realize they weren’t adequately prepared for such a wholesale change. But if you start small and take an iterative improvement approach, adapting these techniques to your organization’s unique business challenges as you go, it very much can be done. As more organizations make that investment, it’s becoming clearer that IaC is worth the effort in the long term.

About the Author:

Dave White, Senior Analyst, MOBIA

Dave White is a Senior Solutions Architect with over 20 years of experience in the IT industry. Throughout his career, he has worked with a variety of organizations and a range of technologies — from traditional infrastructure to software development to public cloud. Dave is passionate about partnering with organizations to align business needs with technology to drive successful digital transformation. Outside of work, Dave enjoys spending time with his wife and teenage son.

Trackback URL: https://mobia.io/infrastructure-as-code-iac-the-foundation-of-hybrid-it/trackback/