DevOps Technology: Everything as Code – VMware Cloud Community

Application developers have long known the benefits of maintaining application code and configuration variables in a standardized text format – allowing efficient code sharing, versioning, and reuse. Modern infrastructure tooling has evolved to similarly drive the management and configuration of infrastructure components “as code”. But what does this mean, and why is it an essential capability of The Cloud Operating Model?

Back in the day

In my first IT role, to install a server, switch, firewall, or any other infrastructure component, the process was simple but not efficient. Essentially, I unboxed and racked the device, connected it to power and network, and installed the operating system from a pile of floppy disks. Initial configuration was done from a physically connected terminal, wheeled from device to device. I spent more time working directly in the datacenter than I care to remember (in one early role, my desk was actually IN the datacenter, between the noisy racks).

Then came virtualization

The first major innovation to change this way of working was virtualization. Prior to virtualization each infrastructure element was a physical device. By abstracting the physical device into multiple, virtual representations of that device, we were not only able to increase the utilization of the physical device but manage the virtual device entirely as software – which enabled additional innovation, for example vMotion and DRS for vSphere virtual servers.

The Software Defined Datacenter (SDDC)

Rapid innovation across the datacenter drove the concept of the SDDC, where additional virtualization across networking and storage components vastly increasing the flexibility around infrastructure management, enabling a model where infrastructure functionality could be automated and be delivered as a service.

API First

APIs (application programming interfaces) have long been used by software developers to enable the integration of different software programs via a standard framework. The rise of the API in the datacenter led to infrastructure providers enabling APIs as the primary interface for configuring and integrating with their solutions, making the automation of these components much easier.  It means that you have direct access to the same operational capabilities that the provider themselves is likely using behind their own GUI. No more executing remote scripts via SSH or relying on some third-party integration agent.

Cloud

Cloud is essentially a self-service SDDC, consumed via API, and billed by utilization. That loose definition is certainly open to debate, but you may not change my mind.

Infrastructure as Code (IaC)

So, if virtualization essentially represented infrastructure functionality as software, and software is code, it could be argued that virtualization is “Infrastructure as Code”. But just like virtualization alone does not equal cloud, neither does it equal IaC.

IaC typically describes an additional abstraction, one I first introduced in Continuous Everything, where I described it as “the functionality that allows an infrastructure resource (or set of resources) to be defined in a (subjectively) human-readable text file.”

This abstraction allows the desired state of infrastructure components to be defined in code (usually YAML or JSON). Deploying the code definition drives the provisioning and maintenance of the environment by triggering automation that results in the desired state.

Common implementations of infrastructure as code include vRealize Automation, Terraform and AWS CloudFormation.

The above table shows examples of commonly used IaC solutions and their cloud infrastructure targets. It includes a (simplified) snippet of the code used by each to deploy a simple VM.  While the code may look similar at first glance, a template formatted for one engine will not work on another.

A notable exception here is vRealize Automation, which allows you to include Terraform Configurations within your vRA cloud templates , and to broker AWS CFTs directly from the vRA service catalog.

Configuration Management

Configuration management (CM) has been around in one form or another since I was hand-loading floppies into servers back-in-the-day. However, today when we talk about “configuration management” we are typically referring to a new generation of CM tools that, like infrastructure as code, allow desired state to be defined in code with the implementation engine doing the heavy lifting of implementing and maintaining that state.

Configuration management is primarily used to manage operating system and application configuration, whereas infrastructure as code typically manages the virtual infrastructure.

Common implementations of configuration management include vRealize Automation SaltStack Config, Chef, Puppet and Ansible.

Here again, code formatted for one configuration management tool is unlikely to work with another configuration tool.

And again, a notable exception is vRealize Automation, which includes native integrations with the common configuration management tools, allowing the inclusion of those configuration definitions within your vRA cloud templates.

To further confuse matters, there can be overlap – some configuration management tools are capable of provisioning infrastructure components, and vice versa.

Regardless of the infrastructure as code or configuration management implementation that you choose, the goal is the same – full application stack automation, built and maintained from desired state definitions expressed as code. And some automation platforms – like vRealize Automation – allow policy and governance components to be maintained “as code” too.

Managing environments through code brings many operational benefits, including:

• Highly automated, scalable management of infrastructure and applications.
• Self-documenting (and always current) environment definitions.
• Consistent, predictable environments and configuration drift remediation.
• Simple environment replication for auto-scaling, availability and disaster recovery.

Additionally, “as code” environments enable the application of software best practices to infrastructure and configuration management:

• Collaboration through code sharing.
• The implementation of configuration version control and rollback capabilities.
• The incorporation of infrastructure components into software integration, testing and delivery pipelines.

The Cloud Operating Model

Once your infrastructure constructs are provisioned and managed through code, the opportunities for additional automation are endless.  And with relentless automation being at the heart of both the Cloud Operating Model and a core DevOps principle, infrastructure as code and configuration management are the logical next step for cloud infrastructure management – be that the private, hybrid, or public cloud environments that your teams are juggling.

Modernizing infrastructure tools and processes brings efficiency, consistency, and agility to your environments and services. But more importantly, it allows your people to gain valuable new skills, concepts, and best practices, and to reprioritize their scarce time resources from reactive infrastructure management to proactive service building.

More so, these modern tools and concepts spawn additional opportunities for infrastructure modernization, like immutable infrastructure and GitOps. These core capabilities are also central to extending DevOps processes and principles to the infrastructure components of an application, which I cover in my next post “DevOps for Infrastructure”.

VMware vRealize Cloud Management

If your teams are closer to the manual data center than to the self-driving datacenter and would like to hear more about VMware’s modern infrastructure automation platform, visit us at https://www.vmware.com/products/vrealize-automation.html

Five Strategic Automation Use Cases for Your Business

IDC Worldwide IT Automation and Configuration Management Software Market Shares, 2019

DevOps Blog Series: