VMware Aria Automation Cloud Consumption Interface (CCI) – Part 1
Setting Up Single Sign-On for CCI – Part 2
Configuring the CCI Infrastructure – Part 3
Cloud Consumption Interface (CCI) was a capability that was made available in the SaaS version Aria Automation back in October 2023. More recently, that same capability was released to the on-prem version of Aria Automation, starting with 8.16.2. With CCI now reaching a GA point for on-prem AA, I’ve decided to delve a little further into this capability. Over the next few blog posts I’ll provide a crash course into what CCI is, how it works, the process to enable and configure CCI and then start to leverage its self-service capabilities.
If you’re new and a little confused to what CCI is, you’re not alone. CCI began as Project Cascade back in late 2021. It’s only now that we’re starting to reach a point that it’s ready for general consumption. If I was to break it down to my simple understanding. CCI is a new, and the future, way of self-service consumption of Kubernetes and cloud infrastructure resources via Aria Automation. Allowing you to provision resources like VMs and TKG clusters via native Aria Automation creation wizards.
We’ve had the capability to consume Kubernetes in Aria Automation for a long time now via design canvas resources. They allowed us to design and deploy very specific Tanzu resources onto the design canvas. However, this capability will soon be deactivated in favor of this new method via CCI. In AA 8.17 you will now see a banner informing us of this upcoming deactivation.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-1024x162.png)
If you’re running Aria Automation 8.16.2 and above you will see a new page called Supervisor Namespaces under the Consume tab of the Service Broker. It’s here that developers, or any user for that matter, with sufficient RBAC rights can provision and manage Tanzu Kubernetes services.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-2-1024x813.png)
It’s here that you can go to your Tanzu Kubernetes services and using the native creation wizards deploy your own respective services. As you move through the wizard you will see a Kubernetes resource yaml file be created that will be used to create your services. Prior to CCI the only real way to achieve self-service was for someone to first create a cloud template defining all the resources and values and publish that to the Service Broker catalog for consumption. Having this new capability out of the box really changes the consumption model now for AA.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-7-1024x526.png)
Being the GA release of CCI for on-prem Aria Automation (AA). You’ll find the process to enable and initially configure CCI is a little more manual then you might expect in Aria Automation. A number of configuration steps need to be performed by submitted YAML specs directly to AA with no capability to actually be configured via the AA GUI. For example, while you can view your Tanzu Supervisor Regions in the AA GUI. You will find that you cannot add, edit, or deleted them in the GUI. I’d expect this to change in future AA releases as more capability and functionality is added.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-3-1024x668.png)
With the original Kubernetes resources are being removed from the design canvas in the near future, we now have the capability to also consume some new CCI resources in its place. Currently there are only three resources available, but despite this limited amount, you’ll find the Supervisor Resource acts as a bit of a wrapper for a huge amount of capabilties. Giving you the ability to provision not just TKG clusters, but pods, services, secrets, and vm services just to name a few. I plan to explore these more in future posts.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-4-1024x781.png)
Currently at this stage, we have some limited ability to view our yaml manifests of our CCI resources when deployed from the design canvas. As of AA 8.17, we also don’t have any native Day 2 actions we can perform on these resources. Though I would expect this to change in future AA releases to allow us to add and edit yaml specs.
![](https://blog.ukotic.net/wp-content/uploads/2024/07/image-6-1024x799.png)
In summary, I’m really excited for what CCI is initially bringing to Aria Automation. The ability to natively, using out of the box functionality, provision Kubernetes services. No need to have to spend hours creating a cloud template and then publishing that item to the Service Broker for users to consume. Of couse that functionality is still there if you wish to create a very custom service for your users if required.
Over the next few posts I’ll delve further into how to enable, configure and start consuming CCI.