Infrastructure as Code (IaC) is the managing and provisioning of hosted systems through a series of machine-readable configuration files. These configuration files can include anything relating to your environments, making IaC applicable to any business. Due to its simple to maintain, quick to implement, and easy to track nature - IaC is the future of business infrastructure.

The Old Way

“This whole process could take weeks, sometimes even months, going back and forth with clients and different departments.”

Traditionally, commissioning new systems meant the beginning of a mammoth process. Provisioning hardware, setting up software, and a vast number of other time consuming tasks would be required before the process could begin.

Estimating usage and hardware requirements early in the project lifecycle is a difficult process, but in the past this would be the only way to ensure there were no hold-ups later down the line. This method nearly always ended up with over-provisioned hardware and time consuming discussions.

When replica environments were required for dev, staging or UAT it resulted in the trebling of cost, effort, and future management of any associated infrastructure. Despite the fact that they would only be utilised a small proportion of the time. This also meant that an accurate estimation of any growth in usage would be needed in advance, otherwise additional nodes would have to be sourced and added. Often, front-end nodes could be added quite trivially, but many database technologies often require vertical scaling or worse, re-architecting.

This whole process could take weeks, sometimes even months, going back and forth with clients and different departments. Even once decisions have been made, arranging large infrastructure deploys can take a long time when having to work across multiple teams and departments.

What makes IaC better?

“After adopting IaC, new systems and setups become considerably easier and faster to build”

IaC enables software or operations engineers to provision, manage and deploy their technology stacks using descriptive files or scripts. An engineer might write a file or process that enables all infrastructure required to be created on demand including networks, firewalls, virtual machines and databases. This can then be stored alongside the source control repository to enable easy and consistent creation of new environments. This is in comparison to traditional environments, where teams would be required to provision and configure discrete hardware devices and components each time a new environment is needed.

Below are just some of the benefits of migrating to IaC.

Speed to market

One thing that helps any business grow is the ability to adapt and move quickly. Being capable of reacting quickly to opportunities and marketplace changes is vital. Before IaC, new systems would often involve configuration and setup by multiple team members, sometimes taking days or even weeks to implement. New deployments would involve:

• obtaining new hardware,
• testing to check for any manufacturer faults,
• deploying and patching any of our standardised hardened builds,
• installing and patching any additional software that may be required.

After adopting IaC, new systems and setups become considerably easier and faster to build. Software Engineers can define requirements directly in the configuration files, this means lower impact on core infrastructure teams, resulting in faster setup and deploys of new systems. If any new software is required, this can be written as a one-off or shared from previous setups, meaning only the bare minimum of additional setup is required. Once completed, this can be fully tested in staging/UAT environments that can be generated at the push of a button, with the creation of the live system equally quick.

Deployment consistency

Many servers in localised data centers are based on a set of builds which should be patched and hardened to an industry build standard. This can involve repetitive setup tasks which results in user error and misconfiguration, requiring peer review to mitigate. Replacing this process with IaC, machine builds can be automated and more importantly, consistent. Since the same source files and shared configuration are being used, you can guarantee that replicating a machine build will result in an identical output. As build standards are refined and updated, any changes can also be reliably rolled out to all machines in your infrastructure, resulting in a consistent environment across your entire infrastructure, regardless of size and complexity.

Simpler documentation

Writing and maintaining documentation is a sizeable task. Not only does documentation for new infrastructure take time to write, it also requires extensive research and review to ensure it is accurate. Manual updates are also prone to mistakes, with things being missed or misunderstood and the real consequences only being discovered much later. With IaC, the configuration files can safely be shared with all members of the team resulting in no need to maintain such documentation. If information is needed, the configuration files can be used and can include additional comments or notes. With this approach, there’s no need to manually keep anything up to date as there is one single source of truth. You can be confident that the configuration files match what’s actively deployed on your infrastructure.

Improved security

It’s important to keep up to date with the constantly improving security recommendations for infrastructure. This could include anything from important software or operating system updates, to configuration recommendations. Sometimes security updates can apply to as much as 50% of running systems, with changes needing to be made to hundreds of processes. While there are tools available, such as Windows Server Update Services (WSUS), these typically only cover a small portion of infrastructure.

By using IaC, you can reduce the time it takes to deploy important updates by only needing to configure or update once, before rolling out to all applicable nodes. This has resulted in faster deployment times and a much lower window of opportunity for any potential attackers to take advantage of known vulnerabilities.

Provider agnostic

At Avco, we like to keep our options open wherever possible. We’ve always been big advocates of cloud technology, giving us the ability to provision large networks cheaply and quickly where needed. However this has often come with the downside of vendor lock-in. Any resources created and provisioned would be restricted to that single provider, meaning to transfer a system to another provider due to reasons such as cost, would take a large amount of research and development.

By using non-vendor specific IaC frameworks, it’s possible to support a number of different cloud providers at multiple locations. This enables us to easily host our clients data at numerous locations as well as in-house, increasing our options in the event of any Disaster Recovery situation. It also enables us to easily switch to alternative cloud providers if needed, giving the potential to reduce costs or improve reliability.

Scaling

Estimating usage has always been a difficult task. You can either under-estimate on your projections and risk having to build up additional nodes or supporting infrastructure, which takes time, or you can overestimate and increase your costs by having under-utilised hardware. The whole process also requires long discussions with various teams to try and produce something agreeable. These often don’t look further than the first three years, meaning costly changes may well be needed.

A key advantage of many IaC frameworks is the ability to tweak your resource requirements per system without requiring downtime. This could be as simple as a new server to handle more requests, or increasing the performance of some of your key nodes. Even if this facility may not be fully supported or implemented in your setup, additional nodes can be added simply by duplicating the configuration of your existing nodes, with the knowledge that these will be consistent with any existing hardware.

Endless Options

Partly due to its recent popularity, there are currently a number of IaC offerings available. These vary from independent frameworks such as Chef, Ansible, Puppet, and SaltStack with the ability to support local as well as cloud based Data Centers, to vendor specific frameworks such as AWS CloudFormation, or Azure Resource Manager Templates. All options have different approaches, and the varying pros and cons should be assessed before making any decisions. For example, some options typically run much faster but are perhaps less configurable, while others have improved documentation and support available, making it particularly easier to learn and find information. Avco adopted SaltStack as it was the best fit for our systems, but strongly recommend investigating all the most popular options.

Summary

Introducing Infrastructure as Code into a business can be quite daunting. With all the options available and the possibility of committing to the wrong framework, it can be easy to continue with business as usual and ignore the benefits of IaC. However, once the plunge is made, IaC can significantly improve the infrastructure of a business in a cost effective way. For teams, it engages consistency in processes, removing human error and allowing teams to depend on reliable documentation. IaC creates opportunity for a more secure system, with processes being simple to update. Most importantly, IaC enables business infrastructure to be scalable, elastic to the needs of a business and opens doors to migration.

If your business is looking for support with finding the best Infrastructure as Code solution for you, Avco is here to help. Contact us on 01753 213 700 or via our contact page.