This is the second part of the Managed Services Monday with VMware Aria blog series. You can find the first part here.
Being Cloud-smart requires Cloud Landing Zones
Adopting a cloud-smart approach necessitates the strategic selection of the optimal cloud and its capabilities for each unique workload. This approach is making multi-cloud the norm for most organizations. These organizations have come to realize that an initial single-provider, cloud-first strategy can swiftly lead to a variety of challenges. As reported by a recent Forrester study, 90% of respondents say multi-cloud “is helping them achieve business goals”.
The critical foundation for any multi-cloud journey is a cloud landing zone. Cloud landing zones are a set of services and guardrails, that allow cloud consumers to discover, deploy and use cloud services securely and reliably. They abstract and standardize the complexity of (multiple) cloud platforms into a service catalog that includes identity management, cloud resource management and their relationships, networking, security, and access controls. In a nutshell, it’s a set of programmatically deployable cloud resources governed through various policies that make it easy for users to consume services from the cloud.
To establish cloud landing zones and provide them as managed services to cloud consumers, VMware service providers must begin with Aria Automation. VMware Aria Automation is a multi-cloud infrastructure automation platform featuring event-driven state management and compliance. Its design aims to assist organizations in controlling and securing self-service clouds, offering multi-cloud automation with governance, and facilitating infrastructure delivery based on DevOps. As such, it forms an excellent foundation for building cloud landing zones.
“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
VMware Aria Automation Components
Aria Automation is available as an on-premises software deployment or as a SaaS offering, where it is based amongst others on the following services:
- VMware Aria Assembler: Orchestrates and expedites infrastructure and application delivery in line with DevOps principles
- VMware Aria Consumption: Aggregates native content from multiple clouds and platforms into a single catalog with tag-based policies
- VMware Aria Templates: A templating engine to create templates declaratively and collaborate with distributed version control systems
- VMware Aria Guardrails: A multi-cloud governance and policy management capability of VMware Aria Automation SaaS, that provides a foundation for public cloud guardrail configuration and enforcement. It helps automate the enforcement of cloud guardrails for networking, security, cost, performance, and configuration at scale for multi-cloud environments with an infrastructure and policy-as-code approach.
To build the platform to offer cloud landing zones as a managed service, service providers first need to decide between using VMware Aria software or VMware Aria SaaS services. In the case of VMware Aria software hosting on the service provider infrastructure, a base cost to set up the VMware Aria Automation platform is an important consideration. This task is typically required only once for internal service providers and once per customer or tenant in a VMware Cloud Service Provider environment. It includes provisioning of the required VMware Identity Manager instance, configuring load balancers needed by VMware Aria Automation, optionally installing VMware Aria Orchestrator, and configuring high availability where needed. From here, ongoing maintenance of the Aria components is another task required from the service provider. For providers choosing the SaaS version of Aria Automation, onboarding their tenants to the managed Aria cloud service in Cloud Partner Navigator (CPN) is the first step. An example walk-through of onboarding customers to Aria in CPN can be found here:
Challenges with Multi-Cloud Landing Zones
The Aria Automation platform brings all the capabilities to build a (managed) cloud landing zone for cloud adoption and migration. And it works across VMware-based Clouds and hyperscale public clouds. This contrasts with cloud landing zones built on any given hyperscale public cloud ecosystem, which is typically limited to each respective set of cloud services. Examples of cloud landing zones within hyperscale public clouds are amongst others available for Amazon Web Services, Microsoft Azure and Google Cloud Platform.
Looking at these examples, it becomes obvious that building a managed multi-cloud landing zone using native hyperscale public cloud services can become very complex and includes multiple redundant services, which further increases costs for the customer (Figure 2). This is where using VMware Aria Automation comes in. In fact, Aria Automation Guardrails, which builds on the Open-Source Project Idem, can create a standardized landing zone amongst others in native AWS, as detailed here.
However, the true value of Aria Automation is greatly improving standardization and avoiding duplicate efforts while giving customers the options to consume resources from multiple clouds, instead of just one:
Adding value for customers
Combining a wide set of services across multiple cloud platforms also increases pricing complexity and predictability. This is due to the various billing metrics, as outlined in figure 2. Aria Automation can, at least partially, help to reduce this complexity and providers can bundle everything required into a single metric pricing, which greatly improves predictability for customers.
Once the Aria Automation platform is available in either sourcing model, the management tools layer required to build a cloud landing zone is ready for further tool integration:
The integrations and setup tasks can be turned into value-added managed services. This also differentiates service providers from or on top of hyperscale public clouds:
- Setup and connection of identity sources, for example LDAP or Microsoft Active Directory
- Onboard tenant users and groups
- Integrate with CMBD, IPAM, Configuration Management, etc.
- Connect the underlying cloud accounts like VMware vSphere, VMware Cloud, Amazon Web Services, Microsoft Azure, Google Cloud Platform etc.
- Configure cloud abstractions like cloud zones, image and flavor mappings
- Define network and storage profiles
- Define policies around approval, day 2 operations, deployment leases, resource quotas and more
- Create and publish service blueprints and service catalogs for consumption
Publishing and maintaining the Service Catalog
Regarding the incorporation of DevOps practices for managed cloud landing zones and service catalog items, the last task stands out. “Create and publish service blueprints and service catalogs for consumption” is critical, because it creates most value for customers. The other tasks are typically one-time or less frequent activities. Yet creating and maintaining catalog items will be an ongoing service that determines which services the customer can consume. And the requirements for services will constantly change and evolve with business needs. Hence, managing this process in an agile and reliable way is a key requirement. Typically, providers do this through release pipelines and GitOps practices. And we will look at this in detail in the next blog post of this series.
Overall, the opportunity for providers lies in taking away the responsibility for these one-time or recurring tasks from the customer. The managed service delivers a ready to use cloud landing zone in accordance with best practices and customer requirements. This cloud landing zone is not limited to any given cloud but can span multiple VMware and hyperscale clouds. Likewise, it is not limited to any given form factor or abstraction of cloud resources. Service catalog items for consumption in the cloud landing zone can take various form factors. These range from single VMs, multi-tier VMs, container and Kubernetes workloads, native cloud IaaS and PaaS services. Also, custom scripts and automations may be needed to provision resources and applications. The service provider can expose all this through VMware Aria Consumption:
By now, you might have noticed that we left out two important aspects of the cloud landing zone. And these are orchestration and Infrastructure as Code. We will look at these in more detail in the next post about GitOps in a managed services setting.
If you missed the first part of the Managed Services Monday with Aria Series, you can find it here.
