VMware Cloud Well-Architected Framework- Automation of Infra, Workload, and Security Services for Azure VMware Solution
Build Pillar – Automation
Automation is the practice of using programming languages or dedicated tools to deploy infrastructure, perform configuration or execute other operational tasks. Cloud automation is primarily accomplished by interacting with one or more endpoints. An API, or application programming interface, is a documented interface to interact with software. REST APIs are exposed via a web server and use the same HTTP concepts as a web browser. Virtually every operation in the cloud results from a REST API call, from creating accounts to provisioning infrastructure. Using code to interact with an API allows organizations to quickly provision complex, repeatable infrastructure in the cloud.
There are several benefits to embracing automation:
- Elimination of human error – Using automation eliminates the chance of a mistake on the part of an operator/administrator when performing a task
- Repeatability and consistency – Automating a laborious or complex task makes it easy to repeat and ensures the result will always be the same
- Reduced toil – By automating manual, time-consuming operational tasks, employees have time to provide value to the business instead of wasting time on undifferentiated heavy lifting
- Speed – Automation is faster than manually provisioning infrastructure in the cloud
- Compliance – Organizations can use automation workflows to ensure security requirements and other best practices are always configured as expected
While APIs are the fundamental technology to enable automation in the cloud, organizations don’t need to be experts in APIs or programming languages to leverage automation. Several open-source and commercial automation frameworks simplify the complexity of communicating with an API. These tools fall into two general categories:
- Infrastructure as Code (IaC) – Generally focuses on provisioning, modifying, and destroying primitives in an environment, like networking, storage, and compute resources.
- Configuration Management - Configuration Management generally focuses on managing the configuration of a resource already deployed, like an operating system or a networking device.
These categories are helpful when identifying which automation tools are the best fit for a specific task, but organizations should be aware that many automation tools have capabilities that could be categorized as both IaC and Configuration Management. In other words, the lines are frequently blurred between these two categories, but it is still worth understanding the difference between the two.
There are a handful of automation concepts that organizations should be aware of to ensure success.
When it comes to automation, idempotence means that once a specific task is run, rerunning it will not alter the initial result. For example, if idempotent automation exists to deploy three virtual machines, running the automation will result in three deployed virtual machines. Rerunning the automation, whether once or a thousand times, will not alter the environment. Conversely, if non-idempotent automation exists for the same task, it will deploy three new virtual machines each time it is run.
Automation tools are either idempotent or non-idempotent, so organizations should choose a tool that best aligns with their operational practices. The advantage to using idempotent tools is that they prevent unexpected results when automation is run inadvertently. Organizations that require fine-grained control over every step taken by an automation tool may prefer a non-idempotent tool. Still, it is prudent to test both idempotent and non-idempotent tools to find the best fit.
Expressing how to automate a given task is done via a data model. Data models follow a syntax that is readable by both humans and computers. They are frequently referred to as a “language,” even though they are not always actual programming languages. Standards-based data models include JSON and YAML. HashiCorp HCL (HashiCorp Configuration Language) is an example of a proprietary data model.
Automation tools and their associated data models can be declarative or imperative. Imperative automation is like a recipe or directions to a destination. Each task that needs to be executed is specified, as is the order to execute them. Declarative automation specifies the desired end state, and it is up to the automation tool to determine what needs to be done to reach that state.
Using the same example automation that creates three virtual machines, in an imperative model, three new virtual machines would be created each time the automation is run. In a declarative model, three new virtual machines would be created the first time the automation runs, but no new virtual machines would be created on subsequent executions. Now, suppose the automation was updated to create five virtual machines. In an imperative model, an additional five virtual machines would be created. In a declarative model, only two new virtual machines would be created since three virtual machines have already been created.
As with idempotence, organizations should choose a tool that fits the model best aligning with their operational practices. Declarative tools are typically easy to use but are not as flexible as imperative tools. Organizations that require fine-grained control over every step taken by an automation tool may prefer an imperative tool. The same advice given for idempotence applies. Organizations should test imperative and declarative tools in a sandbox environment to weigh the pros and cons.
Automation data models and other configuration information are saved in files. Storing these files in a source control system, like , provides several benefits. Developers use source control to track and review changes to source code and collaborate with other developers. Organizations implementing automation should follow these same practices by storing all automation-related files in a Git repository (or similar solution).
Git can be combined with a Continuous Integration/Continuous Development (CI/CD) pipeline to trigger automation whenever the data models stored in source control are changed. This practice allows for the automation data models to represent the “source of truth” for the desired state of an organization’s infrastructure. Whenever a change is needed, a typical Git workflow is followed to review proposed changes and merge them into the repository. Accepting a merge request (a.k.a. a pull request) triggers the pipeline to execute, running the automation to adjust existing infrastructure based on the changes to the data model.
Combining source control and pipelines for automation requires planning and testing to be successful, but the result is a compelling model for deploying and maintaining cloud-based infrastructure and services.
Automation enables organizations to embrace the practice of immutable infrastructure. Traditionally, infrastructure components are mutable, which is another way of saying that the components can be changed or reconfigured. Virtual machines and other components are deployed, configured, and reconfigured over long periods of time. These environments are susceptible to configuration drift, slow memory leaks, or full disks. Immutable infrastructure is used to mitigate these issues. With immutable infrastructure, existing components are decommissioned, and new components are deployed whenever a change is needed. The same process is followed when a component is unhealthy – it is simply removed and redeployed. Automation drives the deployment of components and ensures that the environment is in its desired state.
Several open-source and commercial tools are available for automation. Building custom automation from scratch is feasible for organizations with a mature team to support the effort. Organizations must determine which tool(s) will meet their needs or if they need to develop automation functionality in-house. Consider these rules of thumb to help determine the correct tool:
- Find a tool that fits your existing operational processes well and is compatible with your technology stack (cloud providers, infrastructure software, preferred operating systems, etc.)
- Focus on tools that are actively developed and have a large community of users
- Avoid tooling sprawl by committing to one, or at most two, automation tools
- Determine if you need technical support. Some open-source tools have commercial support options, as do virtually all commercial tools. Large or mature organizations may be able to support open-source tools internally.
Automating the Deployment of VMware Cloud Environments
Organizations that wish to automate the deployment of VMware Cloud environments should begin by understanding any prerequisites that must be satisfied before deploying a VMware Cloud environment. These prerequisites vary between cloud providers, and organizations may have additional requirements to fulfill. Generally, a basic networking configuration is required, whether that is within the cloud environment or a new connection provisioned to the cloud provider.
VMware Cloud is powered by multiple APIs:
- Cloud Provider API – This is the API used to configure native cloud resources to satisfy any prerequisites for the VMware cloud environment, as well as deploying the actual environment. Documentation and developer resources are available in each cloud provider’s documentation portal.
- VMware APIs – Each VMware product, like vSphere, NSX, or HCX, has one or more APIs available for use. Documentation and developer resources are available at .
- Satisfy any prerequisites by using the Cloud Provider API or an automation tool that supports this API. This API will also be used to deploy and perform the initial configuration of the VMware Cloud environment. Once deployment is completed, organizations can automate against the various VMware APIs to configure compute, storage, networking resources in the new environment.
An Azure VMware Solution private cloud exists as a resource within the Azure Resource Management (ARM), allowing interaction via several different automation tools. First-party Microsoft tooling generated from the ARM specifications tends to support features shortly after being released. From an automation perspective, the considerations provided within this document are provided in a way that can be applied across different toolsets.
- Utilize Azure CLI, PowerShell, or a declarative template such as ARM Templates or Bicep Templates to deploy AVS in an automated manner.
- Where possible, utilize ‘what-if’ to confirm changes before execution, pausing on resource deletion for verification.
- For operations that will be single deployment but still require infrastructure as code, utilize Azure Blueprints, allowing for stamped & repeatable deployments without the need for automation pipelines.