When software developers write about their work, it’s often so laced with jargon that other stakeholders in the business can’t understand what the piece is about or how it relates to business goals. There are two components of this problem. One is technical terms, which can be hard to get around and sometimes do require a certain level of technical understanding to grasp. The other, completely avoidable source of confusion, though, is buzz words. So let’s start by defining common ones you hear all too often.
Agile: A change in the way businesses work together. In the software development process, this usually means delivering new software in small increments and working on tight timeframes, called sprints. Agile is most popular in IT departments but is certainly not limited to IT—marketing, sales and other business groups also use agile methods. The goal is to get frequent, rapid feedback from end users and make adjustments based on that feedback.
DevOps: Bringing the development and operations roles together to create more cohesive software development teams that are responsible for the entire application lifecycle. DevOps is an automation-driven model for collaboration across the IT organization, including development, quality assurance, operations, and security – as well as an increasing level of collaboration with people in customer-facing roles that represent the ‘business.’
Infrastructure as Code: Treating infrastructure changes in the same way as code changes, often having them go through the same pipeline for deployment from Development to Production.
Infrastructure Automation: The ability to apply one or more changes to infrastructure without human interaction. This almost always requires an infrastructure as code set-up.
Code Repository: Infrastructure automation requires that changes and configurations be stored in code, which in turn needs to be hosted somewhere. The place where code ‘lives’ as developers work on it is called a code repository. Git is the most widely known code repository but there are many others around. The code repository is a place to work on a change, get peer review and group approval before the changes are integrated into the deployment pipeline. This process is second-nature for developers but new for most infrastructure and operations professionals.
Diving into Infrastructure Automation
Infrastructure automation removed much of the complexity behind infrastructure management, allowing non-specialists to make infrastructure changes through a set of pre-configured options.
How is this possible?
Infrastructure automation makes it possible to give anyone the ability to change infrastructure at the push of a (pre-configured) button. These buttons make infrastructure changes and declarations using standard programming languages.
If you hand-craft a system from scratch, it’s often impossible for another person, other than the original builder, to replicate the system or even to repair it or create replacement parts. If you assemble a system from pre-made components, it’s easy to assemble and can be done without a high level of expertise. In addition, repairing, replicating and switching out components is much easier. This is how infrastructure automation works. The parts come from a code repository like Git; the assembly instructions are also in the repository.
Scripts are like hand-crafted parts to a custom-made machine—they can not be reused to build other machines. Rewriting or refactoring the scripts as code is not a best practice, either. Rather, chunks of code should be designed from the beginning to be interchangeable components that can be reused in multiple projects.
Tools like Agile Stacks can be used to automate the creation of standard, interchangeable parts, as well as for managing the act of swapping out those parts in any given infrastructure.
Ten years ago, one script might have been written to deploy a Linux or Windows server. Overtime, this is creating a huge business risk, since any change would put the entire server at risk. Today, each step should be its own, versioned code chunk. If any step is bad, we can fix the bug and save it as a new version, which allows for granular testing. This reduces the risk of bad infrastructure changes infiltrating a production environment.
Infrastructure as code (IaC) templates are like parts lists (also known as manifests) with the parts stored in a box (Repository) with version and description details.
Here are some of the most common tools used to create infrastructure tasks:
Infrastructure automation and composition is like storing the assembly instructions in the box (in the repository). Here are some of the stack composition tools available:
- Agile Stacks SuperHub
- XebiaLabs Morpheus
Infrastructure automation is possible when you use standard coding language to create pre-configured code chunks that can be used to make infrastructure changes in a repeatable way. This makes it possible for teams to control infrastructure changes, ensure that all infrastructure changes are made using best practices and that the resulting changes match the intention of the requestor. Particularly when working with large, distributed teams, this is the only way to ensure that infrastructure is consistently managed and updated to keep it secure, compliant and on-line.