A lot of times when discussing Infrastructure-as-Code, the context is often running your applications and infrastructure in either a cloud or Kubernetes environment, neither of which are a “traditional data center” setting. While Kubernetes can run in a traditional data center, however, the servers that comprise a Kubernetes cluster are more of what’s in question here – non-cloud and non-Kubernetes systems.
For anyone not already familiar with Infrastructure-as-Code, or “IaC,” it’s a mechanism where hardware and environment configurations are created through scriptable, repeatable processes. In other words, rather than picking up the phone, calling your vendor and asking that they send you four new servers, waiting for them to arrive, putting them in the server rack, and logging on to each one individually to manually configure them as needed, you’ll instead write out a grocery list of servers and hardware you want with their associated configurations in a text file. That text file is then sent to an IaC provider to convert it into provisioned servers, thus turning your wish-list into a reality.
But, you can’t just create servers out of thin air! Well, not in a “traditional” data center anyway. IaC does depend on virtualization, whether that be on-prem or in the cloud. Even in the cloud, physical servers do exist and need to be purchased from manufacturers or distributors.
Virtualization has been around for a relatively long time now (at least 14 years), so hopefully even in a “traditional” data center this technology is available through something similar to VMware or Hyper-V.
Through Virtualization, the IaC provider is able to launch servers on-demand making the traditional data center not all that different from a cloud provider.
Fortunately, there are IaC frameworks that are capable of deploying to non-cloud environments. Terraform and Ansible are the two most common for that particular use case. Using either of these frameworks and writing your IaC templates in their respective syntax will allow you to procure new infrastructure within your traditional data center, virtually. With that in mind, let’s see how you too can realize benefits of IaC in a non-cloud environment.
As seen in Sketch’s **webinar**(link), spinning up an entirely new environment for your application – whether for a client sales opportunity, load testing, or QA – takes minimal time and effort when leveraging the IaC template for your app.
If your environment has tens (or hundreds) of servers, that would typically take days to weeks to properly provision. This time is often spent by a system administrator logging on to each server individually to properly configure things. Conversely, with those configurations being established in an IaC template (text file), these settings can easily be copied, replicated, or reused throughout the template. The IaC provider can run this template and provision pieces in parallel, which drastically reduces the amount of time required to get things up and running.
Additionally, using a template to create the infrastructure ensures proper configuration of all its pieces; you get roughly a clone of your other environments without the fear of system settings being “fat-fingered.” This parity removes time spent troubleshooting environment-specific issues that sometimes arise once the development teams get their application installed on the resulting machines.
One other area that sees huge speed boosts is the clean-up of environments. When not using IaC, you don’t typically see entire environments spun-up and later torn back down. But, when considering the example of your sales team wanting a demo environment specifically for a potential client, after that demo is done the demo space is no longer needed. IaC providers are just as fast (if not faster) at tearing down infrastructure as they are at building it. This frees up resources in your traditional data center that can be used for more important things.
In the cloud, savings can be seen in tearing down environments and not paying for those servers anymore, as we just discussed. But, in a traditional / on-prem data center, you still have, own, and maintain the physical hardware whether or not it’s running n-number of demo environments.
The primary realization of savings in this case comes directly from the speed offered by IaC. The time not spent by your operations team performing repetitive tasks, the time not spent by your QA and developers troubleshooting why things are broken in UAT yet work fine in QA and Production, these are where savings can be reaped in a traditional data center.
Regardless of cloud or traditional, by leveraging Infrastructure-as-CODE, you can start to leverage security benefits inherent in software development because you’re now dealing with code yourself!
Traditionally, operations engineers could log on to systems and make changes. Each change would generally correspond to a request ticket for tracking, but the engineers are, in essence, on the honor system that they only make modifications that there are tickets for. By using IaC instead, the templates can be saved in a Source Control Management (“SCM”) system like Git or Subversion. The key security feature here is that SCM tracks who made a change, when they changed it, and what, exactly, they changed. You can even track why, but that does require the honor system and agreed conventions. The main takeaway is that there is full auditability offered when infrastructure changes occur within IaC using SCM. Look into “GitOps” for your organization to fully leverage this security aspect of IaC.
Does it really matter where your data center or infrastructure is for you to reap the benefits of IaC? Not really!
Normally, when we talk about IaC, our brains default to cloud environments. That’s most likely because the cloud is the new, shiny technology, and the cloud makes IaC easy. But, there are IaC frameworks that have existed for a while already that support deployments into on-prem environments. So, there’s really nothing stopping you from using IaC in a traditional data center.
What’s more, the bulk of the benefits offered by IaC are simply benefits inherent to IaC. There’s hardly any difference to the speed, savings, or security you gain using Infrastructure-as-Code if you’re deploying to a traditional data center vs. the cloud. So, if you’re running in a traditional data center today, you ought to consider building new infrastructure using IaC…with a few tweaks it’ll make your plunge into the cloud that much faster when you’re finally ready to take that dive!
To watch our on-demand webinar at any time discussing "How To Improve Security, Speed, and Savings with Infrastructure-as-Code" click here!