The Machine Builder

How did we get here?

Before virtualization became commonplace in businesses and enterprises, admins needed to go through lengthy spec-build-procure-install cycles to add new hardware—and thus compute capacity— into an environment. This effort also required a strict understanding of the application requirements, network, and shared storage load these servers needed. The spec process alone could take weeks as you dug through software and operating system compatibility requirements. Then, multiple months later, the servers arrived, and there would inevitably be motherboard BIOS and firmware updates for RAID, network, and other subsystem cards. Then, do we even need to talk about the herculean effort to install and configure an OS on all those new servers? Even with things like PXE boot, it was still a long process. Once completed, your new servers could finally be put to work.

Five years down the road, it got a bit easier. We moved from physical hardware to virtual machines. VMs were newer technology, and instead of building physical machines, you clicked through a UI, chose the hardware configuration and virtually configured a machine. Everything from the memory, to the network interface card (did I mention we now have gigabit support?) was virtual—enabling new machine creation in minutes, no purchasing necessary.

Not many years later, Microsoft introduced System Center Virtual Machine Manager (SCVMM) and VMware brought the world vSphere. These were tools that applied an abstraction layer over designing and provisioning these types of infrastructure. With just a few clicks of a mouse button, you could create templates and deploy virtual machines that fit a pre-designed requirement. Not only did these management tools allow machine deployment in a more efficient manner, but they also took out many of the configuration missteps and hassle that used to be associated with one-off deployments of the ye older days.

‍

The latest step in the deployment of computers is Infrastructure as Code (IaC), where your virtual machines are created and deployed in the cloud, and defined entirely by code. Now, instead of clicking through a UI, or even issuing commands in a CLI, we create a configuration file that identifies the components and configuration—and the deployment is done behind the scenes with little to no interaction. Config file in, entire environments out.

Why do I need IaC?

One thing that IaC has ushered in is the ability to ensure that change management at the continuous deployment (CD) level is now adhered to. It also allows a much simpler way to check in code, which then has a trickle down effect on the infrastructure components that support our day-to-day operations. One of the greatest things about a version control system like git is that it can track every change, what that change should do (provided the comments are informative), and hopefully the outcome that is associated with it, not to mention the person who made the change. With IaC, the infrastructure can be updated automatically, with the simplicity of a code commit. A bonus to describing infrastructure in code, is the configuration files help to document the environment—virtual machines, networks, and their interactions. By looking at the structure, it's now much simpler to figure out the settings, templates and configurations associated with any ‌deployment you might make or any change you might want to implement.

How do I get started?

If you’ve gotten this far, then you’re probably ready to dip your feet into the IaC world and you understand the tools that it encompasses. Be it containers, git, nodes or YAML, there are a lot of moving parts to infrastructure as code. As with any successful project, IaC can be a phased approach. Start small by finding a quick-win project, such as a small development environment. Start with the lower environments and when you get code ‌you can deploy over-and-over, without error, and with the configuration as you expect, then it's time to take it to the next level. Use that same configuration and move it to your staging environment—with a subset of data that reflects a production environment. Once you’ve proven that the deployment is reliable, you’re ready to move on to a production environment. 

Do I need to replace everything?

As with every project, there’s a cool tool and there’s the right tool for you. Context is everything. There’s no need to over architect your environment just to retrofit an IaC deployment, when all you need is a simple virtual machine. As you look at every environment you have, it’s worth thinking about the value you could gain from modelling a ‘desired state’. In our experience, modelling environments as code almost always works great, but we also don’t want to advocate using a technology just because it’s cool! Ask yourself: will this deployment be repeated over and over again, or is there little benefit to automation? Of course, feel free to get in touch with us and ask for advice about your specific environment if you’d like help.

Putting it all together.

IaC is a great tool that can help save time and keep environments standardized. Infrastructure becomes easier to deploy, it can be automated, and you can be confident in its consistency. With code stored in a version control system, you automatically get change management processes, as well as immediate action. Lastly, we must recognise the simplicity of basic code that can deploy complex environments.

We recommend you start small with an achievable project and grow as needs dictate. The basics of modelling infrastructure as code mean you’ll automatically introduce a trustworthy development to staging to production workflow, with code centralization and history that colleagues can share, reuse and learn from.