Cloud infrastructure automation is a category of software tools to help organizations manage their cloud infrastructure. Since we discussed how cloud storage impacts current storage admins in a previous post, it may be good to explore this topic to understand if current knowledge and skills can be extended to this domain.
Disclosure: The main example I’ll use in this post will be HashiCorp. I was part of Cloud Field Day 8, and HashiCorp presented. They did not pay me or have any input to this post. They did send me some nice swag, including a cool Yeti cup that I use pretty much every day.
What is Cloud Infrastructure?
Let’s start with the basics: what is cloud infrastructure? This definition is from the SNIA Dictionary:
The referenced ISO standard goes into greater detail about key characteristics, roles, capability types and services, and deployment models. This is a great vendor-neutral resource if you need to write about anything cloud.
In general, most of us recognize cloud deployment models as the public cloud (AWS, Google, and Microsoft Azure are the dominant players in the US), private clouds (cloud environments used and controlled by a single customer and operated by that organization or a 3rd party). Hybrid cloud uses at least two different deployment models. [ISO/IEC 17788]
The thing to remember is that cloud infrastructure is infrastructure. Infrastructure exists to host applications. The applications are evolving, they can handle more and extremely diverse sets of data that scale enormous file systems. Many require powerful compute methods, so it’s only logical that the underlying infrastructure needs to evolve as well.
What is Cloud Infrastructure Automation?
Since cloud infrastructure is designed to be automatically provisioned by developers and the workloads they create, the infrastructure needs to be able to deliver various components as they are needed.
This can’t happen like it did when I was a sysadmin, and we manually racked, stacked, and cabled (not to mention configured) the servers, storage, and networking required to host a stack of applications that made up a workload. These days, developers (we used to call them engineers) self-provision cloud infrastructure, and those components are virtualized and containerized to support the workloads they build.
Someone is designing the architecture so that the self-provisioning works seamlessly, so cloud consumers can click a button and virtual machines with the correct resources become available. It’s not magic, it’s ops. And it is supported with infrastructure automation.
Cloud Infrastructure Automation Tools
Fortunately, there are many cloud infrastructure automation tools from which to choose. How do you narrow your selection down?
According to Gartner, Infrastructure Automation (IA) tools should have these capabilities: multi-cloud/hybrid cloud infrastructure orchestration, support for immutable infrastructure (container-native), support for programmable infrastructure, self-service and on-demand environment creation, resource provisioning, and configuration management.
Let’s talk about one of them: HashiCorp.
How Does HashiCorp Support Cloud Infrastructure Automation?
HashiCorp provides cloud infrastructure, in private, public, and hybrid modalities. They help customers with process transformation, from ITIL/ITSM to agile/devops/self service. They help organizations build a cloud operating model.
Here is the HashiCorp portfolio:
- Terraform: Provisioning, think building buildings or city planners. IT Ops are generally the consumers of this product.
- Vault: Security from perimeter-centric scope. Security operations folks use this.
- Consul: Connectivity. Used by networking ops teams.
- Nomad/Kubernetes: a runtime tool. Used by developers and ops.
Here’s a video from one of the founders on the HashCorp portfolio.
Automating the Networks for New Workloads
Most of these new workloads are not meant to just stay in one location, in one cloud. In fact, many of the can be used by other workloads to accomplish a task. HashiCorp’s Consul is a tool for connecting applications across clouds and runtimes and operationalizing them, especially as applications begin to scale.
Consul focuses on the concept of first-class support for all runtimes (Kubernetes, VMs, bare metal, Docker). It crates consistency between inconsistent environments by taking the approach that Service Mesh should be global out of the box, by putting workflows over technologies.
What is interesting about this approach is that it doesn’t ignore the fact that operators are dealing with old and new, and old that is propped up as new. It takes into consideration that while the edges of a private cloud are probably automated, the middle (or the core of the private cloud) probably is not.
That could be a problem if you have an application that needs to traverse clouds or even edge to cloud. That part could still require tickets and SLAs that really slow things down. Consul helps bridge that gap.
Check out the presentation (mostly a demo!) here.
Play in the Shipyard
Shipyard is an environment made up of blueprints that allow you to run cloud native apps on your computer. It allows you to stand up environments with pre-configured YAML in Docker. This is a great way for operators to get stick time with tools that may be new to them, like Consul.
This is a great demo:
Cloud infrastructure is infrastructure. Cloud infrastructure automation is a requirement for these infrastructures to support the new, modern applications that are being created by developers.
The good news? The fundamental principles of ops haven’t changed. Infrastructure has always existed to host applications, and operations people have decades of experience managing infrastructure for various types of workloads. While the types of workloads has changed, the basics of managing infrastructure has not. Use tools like Shipyard to understand what is new, extend your knowledge, and apply your experience to the new world.