Note that as of publication, this blog uses the new VMware Cloud Management branding, with references to legacy brands for clarification. For more information on branding changes, see our announcement blog. This blog has been updated from the original blog posting on March 7, 2022.
VMware Aria Graph is a new technology which is expressly designed for the operational challenges of cloud-native applications and environments and provides access to a single source-of-truth that is updated in near-real time. Aria Graph is developed with an API-first approach that allows DevOps and ITOps to access a consolidated view of their applications across multiple clouds. Additionally, the graph can be accessed via Aria Hub, which provides rich, centralized views and controls to manage the entire multi-cloud environment. Below is an example of the Aria Hub applications view that is built upon the public APIs provided by Aria Graph.
This blog, however, will focus on the Aria Graph API. This establishes a single, consistent programmatic interface to multi-cloud environments which is an important capability to enable DevOps and ITOps. It provides precise and elegant access to Aria Graph data, and it does so with incredible speed.
Before we dive in, please remember that anything discussed here is subject to change and may not make it into the final service. With that I’ll share our legal disclaimer.
- “This blog may contain product features or functionality that are currently under development. This overview of new technology represents no commitment from VMware to deliver these features in any generally available product. Features are subject to change, and must not be included in contracts, purchase orders, or sales agreements of any kind. Technical feasibility and market demand will affect final delivery. Pricing and packaging for any new features/functionality/technology discussed or presented, have not been determined.”
A Modern API Approach
When we undertook the task of transforming cloud management to be multi-cloud capable, it became clear an approach that focused on data from multi-cloud, with the ability to provide near real-time updates was needed. Further, the new approach must be able to support the ability to query this data, subscribe to a data change feed and perform changes to the managed environments and workloads.
To meet these requirements, we focused first and foremost on an API approach as the guiding principle. This allowed for adoption of a solution that could meet the challenges faced by organizations as they adopt multi-cloud. Let us next look at what the challenges are, based on the current state of multi-cloud management solutions.
The Challenge: One VM Many Truths
When a virtual machine is created in a public cloud such as AWS EC2 or VMware Cloud on AWS, or in a private datacenter via VMware vCenter, it is assigned an identifier and metadata about that virtual machine is stored in that system’s inventory.
Now, if Aria Automation (formerly vRealize Automation) was used to create the virtual machine it is also assigned an identifier and stored in the Aria Automation database with metadata unique to Aria Automation. So, now you have a single object that has multiple sources of information about the state and attributes of that object.
Now begin to add more services such as Aria Operations for Networks (formerly vRealize Network Insight) for connectivity, application discovery and flows, and Aria Operations (formerly vRealize Operations) for monitoring performance and capacity. All this information is useful in the context of each of these services, but there may be information in Aria Operations that would be important to know in Aria Automation or Aria Operations for Networks.
Practically this presents some challenges. For example, if I want to verify that an application deployment from Aria Automation is currently healthy in Aria Operations I need to understand and access two different APIs. Then I need to correlate the information from both services to get the information I require.
This is just for a single object. If you need information about related objects such as the host, datastore, networking and so forth you can see that the complexity scales rapidly as more services are added.
The Solution: Unified Data and a Common Object Model
Aria Graph delivers a unified consumption surface that meets the unique needs of the cloud administrator and SRE alike. From an architectural perspective, this means creating a platform designed for programmatic consumption and a firm “API First” approach. I think you will agree, after you read this blog, that Aria Graph’s APIs raise the stakes for what is required for management APIs. In this blog, I am working within the mind of the SRE, who is trying to access management tools programmatically and prefers to use APIs.
As mentioned in the introduction, Aria Graph brings in data from multiple management services (e.g. public clouds, VMware Cloud on AWS, and the Aria family) and normalizes the data into a single, common object model in the form of a graph. This allows services to be built on top of the common data model and indeed to extend the graph with new functionality.
There is another key capability that this will deliver; the ability to reference any object from any management service from a single API call.
Below is an example of what this metadata will look like in Aria Graph (in this case an EC2 instance. Notice the unique properties from EC2 and from each Aria service are listed here. For illustration properties only a few properties from each source are shown, but there are many more.
So, every bit of information from multiple services about any object will be available. Let us now look at how we can access this information programmatically using the API.
Meet GraphQL
If you are used to working with VMware Aria (formerly vRealize) APIs, you are familiar with RESTful APIs and our Swagger documentation which makes it easy to learn and test. Instead of REST, Aria Graph uses GraphQL for data retrieval. This allows for more powerful and easier content retrieval. If you have not been exposed to GraphQL, I think you will find it even easier to use than REST and Swagger. For more information about GraphQL visit their website. For purposes of this blog, let us dive into how GraphQL works with Aria Graph.
First, GraphQL is a query language and there are essentially only three types of request operations:
- Queries are the essence of GraphQL, fetching information about specific objects.
- Mutations provide ability to request the server to perform an action on objects.
- Subscriptions provide the ability to track changes in the system as they occur
See, already simpler than REST! Seriously though, GraphQL is ideal for solutions like Aria Graph where the goal is to consolidate, normalize and simplify data from multiple systems. Aria Graph provides a built-in web IDE for GraphQL with full auto-complete, inline documentation, and ability to export to cURL – or you can use your own GraphQL clients – what you really need to know is that this will be an easy tool to use and to familiarize yourself with the API.
Below is an elegant but non-trivial query – we query the API for any AWS EC2 instance entity containing the string “CloudMachine” in the name (and limited to the first 3 occurrences), and ask for their names and entityIds in the response:
The response includes the AWS EC2 instance entities discovered directly from the public cloud as well as those discovered through Aria Automation, Aria Operations or Aria Operations for Networks. I have only asked for the most basic details at this point, but I hope you can start to see the power in this approach.
Here is a slightly more involved query; a query for AWS EC2 instances, but also requesting properties from different data sources (which are stored in “namespaces”), and querying which entities are related to it:
I will not spend a lot of time explaining GraphQL, so if you are interested in learning more and even trying it out for yourself, there are a lot of public GraphiQL instances out there to play with. For example, I have enjoyed learning more by using the GitHub GraphQL API but there are many more you can find from this link from APIs.guru.
Now that I have covered the background, let me show some examples of how this works with Aria Graph.
Finding and Exploring Objects
Above, I discussed how Aria Graph consolidates and organizes data from other systems using a common object model. The inventory objects are referred to as “entities” within Aria Graph.
Now let us take a different, multi-cloud perspective and look at the different cloud deployment environments. In the Aria Hub UI, we can see them like this:
In the Aria Graph API we can query the deployment environments and their members like this:
This produces the output below, showing the deployment environments and their first level of members. From there, you can continue navigating to see the EKS Clusters or AWS EC2 Instances, or the vCenter Clusters and their VMs, etc.
Earlier in this blog, we saw an Aria Hub UI image with another multi-cloud perspective, an application-centric view of the world. This view was not concerned about where the applications are deployed.
Here is an example query of applications and their members, with application discovery having performed by Aria Operations for Networks:
You can see in the response below that this is a multi-cloud query. We see two applications, one of which is running on vCenter and which has an application tier comprised of vCenter VMs, and one which is running on AWS EC2 and which has an application tier comprised of AWS EC2 instances.
If I query the namespace information from the entities, I can get the unique IDs and types for the same VM in each of the Aria services, allowing me to interact with Aria services and any other external REST APIs in the context of these entities.
The best part is that I do not actually need to know those unique IDs to get information about the virtual machines from each Aria service. I can do that directly with the Aria Graph API.
For example, assume I want to know the CPU usage from Aria Operations for some virtual machines. I can form a query like this:
The above query is asking for vCenter VMs (limited to the first 10) and asking for couple of stats for each specifically from the Aria Operations namespace. By default, this returns the latest metric values, but I can optionally add begin and end timestamps, interval type, and rollup type, as I would using the Aria Operations REST API. I can use this same stats API query to get timeseries data for entities from Aria Operations for Networks, AWS CloudWatch or from Aria Graph itself.
Now let us look at how you can perform actions on entities with the Aria Graph API.
Taking Action with Mutations
In REST, you typically use methods like PUT or POST to trigger some activity via API requests. In GraphQL this is an operation type of mutation. First, we need to know what actions are available. I use this query to find the actions I can use for an entity.
Aria Graph responds with the available actions, and the availability of the action depends on the state of the entity. For example, this virtual machine is powered on, so we see there is an action for power off, but that the power-on action has a “validation failure” of “INVALID_RESOURCE_STATE” to indicate that the action is not available. This is like how the vCenter UI would show power on actions as unavailable or greyed-out.
You may have noticed that I also queried for “actionRequests” and that returns a list of actions taken on this entity, so I also have a way to audit activity taken by myself or others on the entity.
To start the power off action, we send a mutation request. We need to provide the entityId and actionDefinitionId from the query above. Let us also request the actionRequestId and actionStatus so we can check to make sure the action was successful.
We see the action was submitted in the response:
Now we can check a few minutes later to confirm that it completed.
Success!
You may have noticed that the action is taken through the Aria Automation service, so that actions are committed within the policy and governance set by Cloud Administrators.
But what happens if something from an underlying service isn’t yet fully integrated into Aria Graph? Well, in addition to being able to get each service’s resource identifier for any entity and using that to invoke the service’s REST APIs, the Aria Graph API and Aria Hub UI also allow you to launch into a given service’s UI directly in the context of a given entity – in multiple places in the Aria Graph API you can query for hyperlinks:
This will return you hyperlinks permitting you to launch directly into a service in the context of a given entity. Note that Aria Graph also includes its own Aria Hub UI hyperlink in there under the ‘ENS’ namespace!
New Services That Extend the Graph
VMware Aria Graph is built to be extensible. As we integrate functionality from existing Aria services, and as we build brand-new SaaS services on top of Aria Graph, these services will all be accessible through the same GraphQL endpoint. They will leverage and expand the core entity model and extend the existing graph with new service-specific fields on entities and other nodes, new namespaces, new queries, and new mutations.
Aria Graph’s extensible core model combined with GraphQL’s ability to stitch multiple sub-graphs together gives us the ability to join data from many different sources, includeing native public cloud metrics, SaaS micro-services and even legacy monolithic services into one extensible graph, without needing to import the data from all the existing services into a central store. This is already used in the core Aria Graph platform, and is the pattern being used as we extend out to new services. The result is a seamless API that avoids the need to centralize data (which is practically impossible at multi-cloud scale).
Speaking of new services, we are already starting to extend coverage, by federating, for example, with VMware Skyline and Aria Operations for Logs (formerly vRealize Log Insight) and are developing brand-new services such as Aria Automation Guard-Rails and Aria Migration on top of Aria Graph. By the way, you can read more about these brand-new services on our announcement blog.
Conclusion
VMware Aria Graph APIs provide programmatic access to powerful Aria Graph platform, which simplifies your integration with VMware Cloud Management. This single, multi-cloud API can be used to retrieve information about and take action on business applications and workloads.
