In the first three posts on managed services with VMware Aria, we have shown how internal and external service providers can build and offer a comprehensive cloud landing zone across multiple clouds. This includes a service catalog for easy consumption, guardrails to ensure compliance as well as advanced automation and GitOps capabilities. Managed service providers thereby can deliver cloud resources in any form factor, from VMs to containers and native cloud service as well as entire applications and automated business processes.
Adding VMware Aria Operations
The next critical part in a managed services business model is managing these resources through value-added services. As a foundation, this fourth part of the series will look at managed infrastructure services through the following VMware Aria solutions:
- Aria Operations: A unified, AI-powered self-driving IT operations management platform for private, hybrid & multi-cloud environments.
- Aria Operations for Logs: Log analysis tool that delivers heterogeneous and highly scalable log management with intuitive, actionable dashboards, sophisticated analytics and broad third-party extensibility, providing deep operational visibility and faster troubleshooting.
- Aria Operations for Integrations: Extends Aria Operations via management packs that aggregate operations data from the leading network, connectors, database, and applications for rich analytics.
Expansion and Synergy Opportunities
Besides the value-added services offered around cloud landing zones and GitOps, service providers can use these solutions to build additional services. Starting from infrastructure and platform operations to troubleshooting, log management, capacity management and more:
Figure 1: Shared responsibility model for managed Infrastructure
For internal and external service providers, offering managed infrastructure services holds the potential for synergies with their own platform operations. This blog series focusses on value-added services from the cloud customer’s perspective. As depicted in figure 1 (solid red line), this involves mainly the management of what the consumer perceives as the cloud resources. It covers VMs, disks, operating systems as well as the configuration of base cloud services.
However, the service provider needs to apply similar practices to the backend systems that make up their own, non-hyperscale clouds. In figure 1, this involves the hardware infrastructure and cloud service operations – marked with a dotted red line. Even though the end-customer does not worry about these aspects of the cloud, the providers do. They have service level agreements to comply with, which require managing their infrastructure thoroughly. And in a multi-cloud environment, operating customer-owned private and edge clouds including the underlying systems is an additional opportunity to expand business for service providers. Through the Aria solutions discussed in this blog post, service providers can benefit from the synergies of addressing all these areas with one solution stack:
Figure 2: Business expansion and operational synergies with Aria Operations
Setting up the Base Service
The first step in building a managed services business around (multi-cloud) infrastructure, is delivering and exposing the required toolset. For a service provider leveraging Aria Operations on-premises in their own datacenter, this means installing, integrating, and maintaining the required components, which include:
- Aria Operations Analytics primary node, primary replica node and data nodes
- Aria Operations Witness node for continuous availability
- Aria Operations Cloud Proxies for remote data collection
- Aria Operations for Integrations Management Packs
- Aria Operations for Logs Virtual Appliance
Service providers leveraging Aria Operations SaaS can consume these components as cloud services and instantiate the platform using Cloud Partner Navigator (Link to video):
“,”content”);]]>
The service provider now established a base managed service, which gives their cloud consumers access to the required management tools. From here, customers could conduct self-service multi-cloud infrastructure management. At this most basic level, the service provider remains in charge of operating and maintaining these tools as a managed service, but let’s the customer handle configuration of the tools and the infrastructure operations task. This base managed service is on-par with the experience customers get from native hyperscale services.
Delivering managed Cloud Infrastructure services
Yet to differentiate and provide additional value to customers, the service provider will need to deliver value-added services:
Figure 3: Value-Added managed Infrastructure Services
For offering managed infrastructure services, those can be grouped into three areas:
- Systems Management: The service provider focuses on managing systems at an operating system level by monitoring events, alerts, capacity, and performance, as well as the associated logs. This is mainly based on Aria Operations and Aria Operations for Logs.
- Cloud Management: The service provider monitors the customers’ systems “from the outside”, meaning on an IaaS Cloud level and using metrics and logs from each respective Cloud’s compute, storage and networking services. In a multi-cloud environment, this can require a range of different sources to be monitored, for example public-cloud-specific service like AWS EC2, Azure Virtual Machines and Google Compute Engine. Aria Operations in the Enterprise Edition comes with management packs for AWS, Azure and GCP out of the box, which only need to be enabled. Further, this also involves the underlying systems that make up any given private or hosted cloud. For example physical servers, storage systems and networking equipment, which may require Aria Operations management packs included in Aria Operations for Integrations Standard Edition.
- Platform Management: The final stage for managed infrastructure is touching the platform and PaaS layers of a multi-cloud environments. It covers components that sit between the infrastructure and the applications. This includes for example Kubernetes, Databases, Web Services and Application Platforms. Like the Cloud-level, many of these components are support by Aria Operations Enterprise Edition, while some require the Aria Operations for Integrations Add-Ons in the Enterprise Edition. For some use-cases, Aria Operations and Aria Operations for Integrations may seem to overlap and support the same services. However, Aria Operations for Integrations provides deeper visibility into dependency mappings and allows for more effective root cause analysis (figure 4). This makes it the tool of choice for complex environments and more advanced managed services.
Figure 4: Aria Operations and Operations for Integrations
Bringing it all together
Aria Operations and Aria Operations for Integrations will typically support a wide subset of systems that need to be managed. This is similar to Aria Automation capabilities described in previous posts. If additional services and components must be supported, the service provider can make use of Telegraf Agents or Aria Operations for Applications, which we will look at in a subsequent blog post on managed applications.
The following demo video outlines how the service provider, or the customer in a self-service model, would onboard a cloud for management with Aria Operations and Aria Operations for Logs. The example focuses on Google Cloud VMware Engine mainly. But around 00:30, we can observe how Aria Operations also has various native AWS, Azure and GCP accounts connected. We also see private cloud accounts, as well as back-end systems which are supported through Aria Operations for Integrations. And from 01:45, we can see how Aria Operations for Logs displays a range of possible log sources. These include native AWS, Azure and GCP services and platform services. It also shows DevOps-related services like GitHub, GitLab, Jenkins and JIRA. These will be important to build reliable and scalable services and practices.
This should give a good overview of the experience and tasks required to build managed infrastructure services with Aria Operations. From 04:00, we can actually see many of the tasks that would typically be pro-active value-adds of the provider (Link to video):
“,”content”);]]>
Shared vs. dedicated Services
Building these value-added managed infrastructure services can generally be done in a shared or dedicated fashion. The base managed service requires customers to have access to the Aria Operations interfaces. Hence, it will typically mean deploying dedicated instances per customer. However, when offering purely value-added managed services, the service provider can choose to leverage a shared instance of Aria Operations to fulfill the managed service. This may help reduce costs for the service provider due to lower overhead, especially in non-SaaS deployments. However, it usually also means preventing the customers from using Aria by themselves.
This decision is closely linked to the exact service and unit of sales that the provider wants to offer:
- The provider may offers to actively monitor the systems and only notify the customer of anomalies and issues. Covered areas can include alerts, logs, performance, capacity, security and more. From there, the customer will still require access to the Aria Operations tools in order to act accordingly and fix the issues. The charge for this model is typically on a per-system basis. Yet the service may also be designed in a more granular fashion. Examples include charging per metric, logs, alert etc., which is similar to how AWS, Azure and GCP charge comparable services.
- If the provider offers pro-active resolution of anomalies, the service is usually backed by an SLA and resolution times. In this case, there is typically no need for the customer to ever access the Aria Operations interfaces. The provider may only publish specific dashboards or reports that outline compliance with the agreed SLA to the customer.
Multi-Cloud Managed Service Considerations
It is important to understand that Aria Operations still relies on AWS CloudWatch, Azure Monitor and GCP Cloud Monitoring to monitor native public cloud services. These services therefore continue to incur charges themselves, too. However, many of the resources used in a managed services business can be offloaded from the specific public cloud platform and be federated in the Aria Operations Suite. These include for example dashboards, alarm, logs, insights, analytics and more. This approach can significantly reduce the complexity of cost modelling the managed service, compared to relying on the full set of solutions across multiple clouds. Even further, service providers are in the unique position to hide that complexity altogether and offer the managed service with an easier-to-predict pricing metric. Such a customer-focused packaging and pricing approach is a strong differentiator and creates value for the customers, which often struggle with the complexities of cloud service pricing:
Figure 5: Operations services across multiple clouds
Conclusion
To conclude, we have now seen how service providers can build a managed infrastructure services model for multi-cloud. Aria Operations, Operations for Logs and Operations for Integrations are the main relevant components here. It should have become obvious how the integrated nature of Aria Operations significantly simplifies management in a multi-cloud setting. This includes both, technical integration of various services, as well as packaging and pricing from the provider to the consumer.
Next week on Managed Services Monday with VMware Aria, we go another level up and look at managed application services. If you missed any of the previous posts, please find them here. And as always, don’t hesitate to reach out to your account team if you have any questions.
