Provisioning and Configuration Management

The New Managed Services Platform Takes Shape in Part 3 of our 4-Part Series

In my last post, I mentioned that I would take a deep dive in to portions of the new platform we’re implementing at ICF Olson Hosting Services and Managed services, and I think it makes the most sense to build on that topic from the ground up.

Infrastructure as Code (IaC) has been a hot topic for the last couple of years. While the idea that we can define infrastructure in a textual manner has existed for as long as documentation has existed, the idea that we can deploy infrastructure textually is somewhat newer, and has really grown up alongside virtualization (early), cloud adoption (current), and containerization (current and future).

Interestingly, when you most often hear people speak – or even look up definitions – about IaC, they’re specifically talking about configuration management. That makes sense, as configuration management (CFM) tools are the longest-existing and most mature of the IaC products, but they are not the only components. Tools in this group include the great granddaddy of CFM, CFEngine, along with Puppet, Chef, Ansible, and Salt. The newer additions include CloudFormation (AWS Specific), Cobbler (the elder statesman of the group), Terraform, or Vagrant, which are IaC provisioning tools.

It is easy enough to have one without the other, especially if you’re already in a “cattle not pets” mentality. For some organizations hosting legacy applications, “cattle not pets” is a dream, and so we have chosen a path that supports both cattle and pets for our new platform.

As a quick aside, it should be noted that a platform, when it comes to software and systems architecture, generally refers to a collection of tools that work together to perform a function. Our platform is just that, along with our own proprietary glue to have the tools work together.

For our IaC provisioner, the new platform uses Terraform from HashiCorp. We’ve found that this is generally the most versatile tool we’ve encountered to work across multiple cloud environments as well as common on-premises virtualization providers such as VMWare’s vSphere, Microsoft’s Hyper-V, and Citrix’ XenServer. This allows us to build a common pattern for application infrastructure and swap out the provisioning target as necessary, creating testable, modular, and reusable provisioning code.

For the CFM tool, we use Chef 12. It was selected for versatility across our target environments and its ability to work as a stand-alone CFM tool (chef zero, or local mode) or in a pull-based model. We had already been using Chef 11 at the core of our older platform, and the organizational knowledge that had been built around it was significant enough that being able to upgrade rather than migrate to a new configuration management tool was a simple one. There was no need to reinvent the wheel.

In my next post, I’ll cover the actual deployment and the monitoring/alerting methodology used for integrated notification and troubleshooting.  If you need to catch up on our blog series, read Part 1 and Part 2.