Helping you get to Infrastructure-as-Code

This is a guest post from Red Hat partner Arctiq.

Since you’re reading this post, you have likely heard of efforts towards automation, DevOps practices, and/or Infrastructure-as-Code (IaC) directives. Looking beyond the buzzwords, the underlying core concepts of IaC can help with speed, risk reduction and advanced deployment capabilities in any organization’s technology journey. This post will elaborate on this and provide some insight from Arctiq's real-world experience.

What is Infrastructure-as-Code (IaC)

IaC is about describing the desired infrastructure in a file, written in a structured manner (code), so that an automation tool or engine can take that description and provision the infrastructure, or reconfigure an already-deployed infrastructure so it matches that description.  

You can think of that codified description as something equivalent to a printing press die for a painting - once the die is made, you can create identical copies. Imagine being able to paint any number of:

• RHEL or Windows systems

• Hardware systems (yes, really!)

• Containerized workloads

• Network devices (yes!)

• API reachable software

• Storage (software-defined or not)

• Configuration files

Anywhere you have a copy of the painting die with the special machine present, you have the power to make the contents of the painting real. This ability to spawn and manage what you define as your infrastructure requirements is what we urge every technology organization to strive for. The benefits are absolutely worth the effort involved.

It takes planning and effort to realize IaC in an Enterprise

Enabling the true practice of IaC in the enterprise is unfortunately not as simple as any of the following:

• Top-down “mandating” infra-as-code

• Top-down “mandating” DevOps

• Buying into or consuming a set of automation tools before understanding them

• Outsourcing your infra-code development

• “Throwing Kubernetes at your problems” without understanding Kubernetes

• Insisting that only one automation tool will work for your organization

Better Practices

While the list above is a good indication of mistakes observed, it serves to help others learn and also paints a picture of better vectors to set in order to realize the benefits of IaC. We tend to see the following in better IaC practices:

• Using branchable, secure, integrated source code management (SCM) for source code and code that defines infrastructure; Git is the de facto choice for SCM.

• Selecting a carefully researched and understood toolset that composes the automation engines for the written infrastructure code; I would argue that Red Hat Ansible Automation is the essential solution in this space, covering the vast gamut of orchestration for the enterprise.

• Enabling end user teams to understand and use the tools in real-world situations

• Obtaining rapid feedback of the state of infrastructure as part of using relevant tools with infra-code

• Enabling both developers and infrastructure teams to collaborate and discuss infrastructure and application needs for successful application deployments

• Easily redeploy dev/sandbox environments to reduce workstation-bound testing (no more  “it works on my laptop, why not in production?”)

• A secure front-end, including RBAC with credential-management; Ansible Tower answers the call on this one.

• Last, but not least: Iteration. Try and try again, fail fast, and move forward.

Complex things are best digested in small pieces — where iteration plays best. Thanks to branches provided by git, the pieces can be minute.  This can speed-up development and help reduce the impact of failures. Branches for each new feature or capability is like its own “sticky note,” if you will. This diagram shows an example of this workflow.

Maintain the Die, Not the Individual Systems

It’s well known that there’s no magical tool to do it all, so finding a mix for us and for our customers has always been an interesting point of discussion. In Arctiq operations as well as for many of our customers, we’re proudly using a combination of Red Hat Ansible, Kubernetes (Red Hat OpenShift), Terraform and GitHub to define our infrastructure as code to enable repeatability, modularity, and auditability. 

It’s not surprising that most of our customers are shifting to focus on IaC practices to ensure successful projects, and report seeing positive outcomes in how change is made to infrastructure, while using this methodology. Additionally, since we don’t want customers rifling through the freshly architected, automated and deployed solutions by hand, we instead encourage customers to use the code to define changes (and use that practice itself) to become accustomed to it, providing a win-win scenario. 

Consider the time and effort that goes into preparing, installing and deploying complex architectures of multi-VM or multi-container applications. Then consider the benefit of having the same structure managed by code instead of relying on manual efforts compromised by forgetful human-error. We gain the ability to shift our focus to efficiently automating increasingly capable systems and applications instead of wasting time on busy-work.

One message rings true that we feel more businesses should strive to understand:

The most common thing to get in the way of infra-as-code practice adoption is leaving other departments out of the loop with how it will change workflows. 

The change in workflows are meant to assist with gaining speed, reducing risks, reducing blockers and promoting shift-left (meaning, to involve and automate requirements earlier rather than leaving them as afterthoughts) the considerations such as security and change controls, allowing automation to carry the burden of work, reducing potential human error. If processes aren’t adapted to accommodate the new workflow of IaC practices, then the outcomes will be much less attractive. In other words, plan accordingly, collaborate, and communicate effectively! 

Arctiq: Helping You Get There

Now that you’ve seen the path, take the first step. At Arctiq, we love to automate, collaborate and engage in the community of new open-source technologies, constantly challenging and changing the business world. 

Red Hat provides world-class enterprise software and support, and Arctiq brings experience and ecosystem-wide architectural insight. We deliver solutions to enterprises seeking to embark on cloud-native paths, infrastructure-as-code journeys, microservice transitions, and secure application pipelines. We help our customers not only implement these solutions, but also understand them. Our deep technical partnership with Red Hat allows our customers to take advantage of world-class global open source software, and boutique customer focused attention from Arctiq. 

Take the next step towards your Infrastructure-as-code journey!