A Guide to Infrastructure Automation in 2020
Even though IT operations now takes advantage of highly adaptable platforms for IT infrastructure, they struggle more than ever with environment drift. It’s easy for development teams to spin up new virtual servers and systems, but this just means that there is more “stuff” for the ITOps team to maintain. Configuration of various elements of IT infrastructure will gradually wind up with hand-tweaked variants that can lead to downtime when equipment is swapped out or capacity is expanded by loading new server instances.
The promise of infrastructure automation, also called IT automation or infrastructure as code, helps IT operations teams define systems configuration at scale and then automates the work to deploy and maintain the systems in an exact, well-defined architecture. Part of the process is automated server provisioning, a concept and practice that has been with us for some while, as well as day-two maintenance and security. Likewise, network automation follows similar processes for the remote interrogation and automated configuration of network architecture components.
Infrastructure automation is the umbrella term for cost-effective, full lifecycle control of all data center components to keep digital business at scale reliable and secure.
Two faces of automation
There are two components of data center infrastructure that require task automation and coordinated orchestration for an IT team to have any chance of creating a production-ready, innovation-delivering IT platform. First, the actual hardware that hosts and runs the packets around needs to be configured, and this work is generally called infrastructure automation. The scope of hardware in a typical data center includes network gear like switches and routers, firewalls, public cloud infrastructure, data storage systems, and on-premises and virtualized servers.
Second, the hardware infrastructure is useless unless it is running software and code in the form of operating systems, containers, and applications needed by the business. There are millions of moving parts in any typical enterprise infrastructure that need to be provisioned, maintained and secured. The work of IT operations teams is extremely complex and requires automation.
The type and scope of infrastructure varies from data center to data center, but in every case automation and orchestration are intertwined and power the ability of an IT operations team to provision, maintain, and secure infrastructure at scale in a reasonable and efficient way. Ideally, the same IT automation and orchestration toolset is used to accomplish infrastructure automation tasks across a very diverse mix of infrastructure hardware and software types.
To learn about the benefits of infrastructure automation as experienced by companies like Liberty Mutual Insurance, IBM Cloud, and NICE Nexidia, read this white paper titled, “Measuring the Economic Impact of SaltStack IT Automation.”
How infrastructure automation works
There are a handful of reasons why an IT team might want to change infrastructure: security patches, adding new IT capacity and capabilities, workload reassignment.
You can always try a hosted instance of SaltStack Enterprise for a first-hand, self-guided tutorial.
But typically IT operators work to keep infrastructure static and reliable. Moving parts and unwanted deltas between systems are the enemy to a reliable data center infrastructure. The term “immutable” is often used to describe infrastructure meant to be kept unchanged as much as possible. Likewise, data center operators use the term “idempotence“ to describe actions that are intended to keep infrastructure in a known, reliable state.
Infrastructure automation can therefore be used to make light work of data center change, maintenance or security, or IT automation can be used to keep infrastructure in a known-good state that never deviates from its purposeful and intended state.
The principles of infrastructure automation and configuration management are often integrated to deliver infrastructure as code, where a configuration management coding language is used to define the desired state of the infrastructure and automation is used to execute the configuration instructions on the managed system.
Within the infrastructure as code and configuration management discipline (terms often used interchangeably) there are two different but common approaches typically aligned with the automation tool being used. The imperative approach to configuration automation specifies a series of steps or commands that ultimately create the infrastructure needed. A declarative approach to configuration automation describes exactly the desired state of the infrastructure. Imperative and declarative configuration approaches can be two different paths to the same infrastructure defined as code.
Without belaboring the point, the declarative approach is often preferred for this one simple reason described in this more-tangible example. If you have a set of imperative instructions that say the heat should be turned up ten degrees, then running that instruction set twice will raise the temperature twenty degrees. This is not usually the desired result.
On the other hand, if you take a declarative approach and say that the temperature should be 80 degrees Fahrenheit, then the system can evaluate what the current temperature is and react accordingly. If the current temperature is 75 degrees, what you actually want is not a ten degree increase, but a five degree warmup. To take it even a step further, If you wanted the temperature to maintain a constant 80 degrees, then you could use an event-based automation approach to detect temperature deviations and provide automated actions that allow the system to put itself back to 80 degrees.
Tying all of these infrastructure automation concepts together, the idea that multiple runs of a command or configuration process should leave the same results is called idempotence. The key idea is that you wind up with the same system state whenever the process is invoked.
You may be thinking that the declarative approach—especially an event-based one—sounds more complicated, but that’s the point of doing it in an automated way using a tool. You describe what your IT infrastructure paradise looks like, then let the tool periodically check, create, and maintain that paradisiacal state as needed.
Infrastructure automation tools
As you’d expect, we’re deferential to the SaltStack infrastructure automation products and tools built on the open-source Salt automation engine. We’ll get to why that is in a moment, but first we should mention other tools in the interest of more comprehensive view of the market:
- Hashicorp Terraform is designed to efficiently provision and de-provision public cloud infrastructure with extensive support for AWS. Many DevOps and ITOps teams will use Terraform to spin up cloud on day 0 and then use SaltStack to automate cloud image security and the ongoing day two maintenance of the infrastructure.
- Ansible is an open-source configuration management tool used primarily for smaller scale Linux environments and network infrastructure automation. It implements a declarative language via “playbooks,” which describe desired infrastructure state. Ansible is well know for an agentless approach to systems management which many would argue is easier to implement than an agent-based architecture. However, what is gained with simple tool deployment may cause issues when more powerful, or more scalable infrastructure automation is required. While Ansible is open source, it was acquired by IBM Red Hat in 2015. Ansible, like SaltStack, is written in Python and leverages a YAML configuration language. The high-speed, massively scalable SaltStack event-driven automation engine is often used to supplement Ansible implementations that have hit the upper limits of scale. Likewise, Ansible is sometimes used to simplify a SaltStack implementation.
- Chef, like Ansible, is a favorite of developers, but unlike Ansible, is a favorite of Ruby-oriented teams. No doubt Chef was an original infrastructure as code offering. Chef recipes use a Ruby-consistent configuration language that describe deployment and configuration routines. While Chef automation supports certain elements of a declarative approach, the general approach is imperative.
- Puppet, like Chef, is based on a domain-specific configuration language that is similar to Ruby. Puppet, unlike Chef, is more popular with IT operators and system administrators. Puppet uses agents on the servers it manages but has recently introduced an agentless alternative. Like Ansible, Puppet implementations are often integrated with and managed by SaltStack automation.
What about SaltStack?
SaltStack was built to help IT operations teams automate infrastructure of all types and at all levels of scale. SaltStack is also extremely modular and flexible to work for just about any IT, DevOps, SecOps, NetOps, or CloudOps use case. For example, SaltStack configuration language is typically declarative but it can also be run in an imperative mode using Salt requisites. SaltStack can also automate IT via agents, agentless, or proxy (API-based) control for unique network gear.
SaltStack infrastructure automation is most capable when running the Salt Minion, or agent, on the managed device. The Salt Master sends commands and updates to Salt Minions and the minions do the work asynchronously. A persistent, real-time connection between the Salt Master and the Salt Minions allows for extremely fast and scalable IT orchestration and automation and makes event-driven automation possible. Event-driven automation comes in very handy when specific files need to be monitored closely, when auto-scaling infrastructure is necessary, or when self-healing infrastructure is desired.
A unique aspect of the SaltStack platform is its remote execution event bus which provides SaltStack users the advantage of high-speed, extremely scalable automation. While beneficial to all IT environments, large-scale, enterprise infrastructure stands to benefit most. Organizations like eBay, LinkedIn, Oracle, are using SaltStack to automate the management of hundreds of thousands of systems. The LinkedIn site reliability engineering team reports the use of SaltStack auto-remediate about 2,500 IT service tickets each day.
Security and compliance represents a continual demand on the IT operations team. Infrastructure automation is essential in helping ITOps teams stay ahead of the crush of work associated with vulnerability remediation and enforcement of continual compliance. Automated security operations, or SecOps, and an acknowledgment of the notion of “infrastructure security as code,” or just “security as code,” has never been more top of mind for CIOs and CISOs. SaltStack offers a SecOps product suite that takes full advantage of the SaltStack automation platform to create a discipline of collaborative and fully automated information security between the IT and security operations teams. Learn more about the concept of security as code here.