Advanced Automation Requirements
In part two of this series, we discussed how to build managed cloud landing zones with service catalogs using VMware Aria Automation Guardrails, Assembler and Consumption.
However, we have so far relied on the out-of-the-box capabilities of Aria Automation and its WebUI. This approach is a great starting point for managed service providers. And it will likely address the biggest part of customer use-cases when consuming multi-cloud resources. However, for certain use-cases it can be limiting in the following way:
- Aria Cloud Assembler supports a wide subset of available hyperscale public cloud native services out-of-the-box, for example the ones shown in Figure 1 on the right. It also got improved through the plugin framework, which helps more quickly and thoroughly support cloud provider capabilities. Yet picking the very best cloud and service for any given workload, which is a key aspect of becoming cloud smart, may require additional native services not currently supported.
- For the service provider to populate and maintain the service catalog at scale and with agility, manually building and maintaining catalog items and services may not be sufficient.
- To consume the service catalog items at scale and across many teams and projects in a reliable and automated may, customers may need to have the deployments incorporated into their own automation tools and practices, instead of manually deploying them from a UI catalog.
Figure 1: Native Services
GitOps Capabilities
To solve that limitation, this blog post focusses on delivering and consuming advanced services in a managed multi-cloud landing zone via a GitOps approach. It focusses on the main GitOps capabilities orchestration, Infrastructure-as-Code (IaC), configuration management (CM) and version control.
These GitOps capabilities have an impact across several layers of the managed services stack and span provider and consumer responsibilities. Starting from the management and optimization of the managed multi-cloud platform, GitOps capabilities will help to configure and maintain the different services and resources across multiple clouds in a scalable way. In most cases, this will be the responsibility of the service provider. Populating and maintaining the cloud service catalog will typically also be the provider’s responsibility in a managed services setting. But it might also be a shared responsibility or entirely owned by the customer. Either way, GitOps and DevOps processes will help enable this at scale and in a reliable way:
Figure 2: Shared responsibility model with GitOps capabilities
The VMware Aria solutions we will to add to the previously described Aria Automation stack to enable GitOps are:
- VMware Aria Automation Orchestrator: Workflow orchestration that simplifies the automation of complex IT tasks
- VMware Aria Pipelines: Speeds up infrastructure delivery and streamlines troubleshooting with release pipelines and analytics
- VMware Aria Automation Config: Event-drive software configuration management for virtualized and multi-cloud deployments – powered by Salt
“The new Aria branding replaces three existing cloud management brands: vRealize portfolio, CloudHealth by VMware Suite, and Tanzu Observability by Wavefront.”
https://blogs.vmware.com/management/2023/04/aria-rebranding.html
Let’s look at how these solutions create value for managed services customers and providers along the three use-cases described above.
Advanced Service Items via Infrastructure as Code (IaC)
The key questions here is how can a service provider, whether internal or external, add advanced services to the service catalog in Aria Consumption for deployment in the consumers cloud landing zone? Advanced in this context means including any resource or configuration that Aria Automation Assembler does not support out-of-the-box via the service canvas, as we have seen in the previous blog.
The first option is using native public cloud IaC templates, for example AWS CloudFormation (CF). CloudFormation is an IaC engine in AWS that supports a wide range of AWS services and resource types, as you can see here. The managed service provider can therefore create CloudFormation templates for advanced services and publish them for consumption in the service catalog (Figure 3).
As the second option, the service provider can use Aria Orchestrator workflows and publish them in Aria Consumption. Orchestrator comes with a set of relevant plug-ins pre-installed, for example Active Directory, AMQP, HTTP-REST, SSH and PowerShell. The latter two can be used in combination with PowerShell Plug-ins and CLIs for Azure, AWS, GCP and other providers to create advanced services using the full set of available cloud offerings from these providers. Beyond that, additional plug-ins are available from VMware Cloud Marketplace.
There are more options to publish advanced services and automations into the Aria Consumption service catalog, like ABX and pipelines, which can be found here.
Figure 3: AWS CF in Aria
What all of these have in common is that they allow the managed service provider to build and publish various kinds of advanced services in the catalog for consumer deployment in the cloud landing zone. Besides basic setup and management of the required components, service providers can build a range of value-added services around this:
Figure 4: Base and value-added managed services for advanced service catalog items
Service Catalog Items via GitOps Pipelines
We have now seen multiple ways of populating the service catalog with advanced managed services and cloud resources. The second key question to building a scalable managed services business around this is how the managed service provider can incorporate GitOps principles into the process.
To achieve this, the managed service provider can leverage a Git repository to store and version control the various IaC files. This would typically be a private repository, which is used to trigger a pipeline that builds, tests, and populates the services in the catalog using continuous integration and continuous delivery (CI/CD). An example of this is depicted in Figure 5.
Figure 5: Example Pipeline
The tool that enables service providers to do so is VMware Aria Pipelines. The managed service provider must first model the release process of services in the catalog. This includes the various stages like development, build, test, approve and deploy. The approval process may include service provider stakeholders e.g. to review code, ensure service quality and successful testing etc. It can also involve costumer stakeholders e.g. to oversee maintenance windows and changes etc.
Figure 6: Endpoints in VMware Aria Pipeline
The service provider also needs to ensure that the required endpoints for the Pipeline are added. Out of the box, these can be based on various tools like Bamboo, JIRA, Gerrit, GitHub Actions, or Jenkins as well as SSH, PowerShell or Rest Agents.
Aria Pipelines also allows the service provider to use dashboards and metrics as part of their quality assurance practice. Key metrics supported out of the box include Average CI time and mean times to delivery (MTTD), between deliveries (MTBD), to failure (MTTF) and to recovery (MTTR).
There are multiple use-cases where this pipeline automation with Aria is essential in the managed service provider setting. For example:
- Image management: The managed service provider will usually be responsible for providing secured, compliant, and supported images. These are used for deployment in the managed multi-cloud environment. Via the pipeline approach, the service provider can automate the creation, customization, and distribution of these images.
- Update service catalog: The service provider can automate the testing and release of blueprints and workflows that are published as services in the Aria Consumption service catalog.
- Update Deployments: The service provider can automate the update and existing customer deployments with new blueprints and images.
Figure 7: Base and value-added managed services for GitOps Pipelines
From here, the customer can consume their advanced services from the Aria Catalog. And inline with GitOps principles, service deployment can be automated via APIs. As the next step, the customer can use VMware Aria Automation Config powered by SaltStack to apply and manage the desired configuration to the service or machine, install software and more. We are going to look at this next step in a GitOps practice from the perspective of the cloud consumer. Yet the responsibility for configuration management may lie with the provider or the costumer. This will again depend on the shared responsibility model of the managed service.
Consuming Services as part of a GitOps Pipeline
As illustrated in figure 2, many of the managed services layers impacted by GitOps capabilities can be either the responsibility of the service provider or the service consumer. In many cases, layers higher up the stack are more likely to be the (partial) responsibility of the customer. This is because they are more specific and harder to standardize in a managed services business. Therefore, we are going to look at configuration management with Aria Automation Config powered by Salt from the customer perspective.
Figure 8: Aria Automation Config Architecture
We already covered three main techniques of GitOps: Source Control, IaC and pipelines. The final one is configuration management. While IaC and pipelines focus on deploying a standardized set of resources, configuration management adds consumer-specific configuration to those resources. To enable this based on Aria Automation Config, the service provider must first set up the Aria Automation Config cloud services tenant, or alternatively install it in their own environment. The provider then needs to install Salt master(s) for the costumer environment(s) and connect these components. Optionally, the Salt minion instances for the management of machines can be installed and managed as a value-add, as well. Since these are part of the VMware Tools, it may, however, be the responsibility of the customer.
Once up and running, Aria Automation Config allows to query and execute commands on individual VMs, or groups of VMs, provision, configure, and deploy software and define and enforce optimal, compliant software states across the entire environment. Configuring and managing this can yet again be a value-added service of the provider. Or it can remain the responsibility of the customer. In either case we have to capability to create tickets in JIRA or other issue tracking tools. As with other steps covered already in this blog series, this is important to ensure service quality in the process.
“,”content”);]]>
Figure 9: Base and value-added managed services for Configuration Management
Conclusion
In this third part of the blog series, we covered advanced orchestration and GitOps practices. These help to handle the deploy and management of multi-cloud services, as well as the underlying infrastructure and platform. From here, a wide range of more in-depth value-added operations services become feasible for service providers. We will cover these services in the subsequent parts of this blog series – starting with managed infrastructure.
If you want to learn more about how to build a managed services business, please out to your account team.
