vRealize Automation 8 API, CLI, Terraform provider, Kubernetes – How developers can benefit from the platform

By | 24. January 2020

Now that the next generation of vRealize Automation has been released I would like to have a closer look on the new use cases being addressed. Most of you probably know that vRealize Automation can be consumed in two flavors in this new model:

  • vRealize Automation Cloud – consumed as Software-as-a-Service
  • vRealize Automation 8.x – consumed as on-premise installation

Both models share the same architecture. So, the information provided in this blog applies to either version.

One major enhancement in the new architecture is the enhanced support for developer use cases. These comprise primarily of Infrastructure-as-Code principles and more in-depth integration of container workloads. This blog will provide an overview of the various consumption options with focus on developers.

Service Broker – Catalog-based consumption of services

Consumption by Catalog

For classic IT consumption models typically a service catalog is provided where users can select and request services in a defined approach. Consumer e.g. can select from various Linux and Windows variations, provide parameters and start the deployment. This is where the Service Broker module from vRealize Automation comes into the game.

Infrastructure-as-Code (IaC)

Many developers require a more flexible consumption model and often won’t use the GUI but rather prefer APIs. While a catalog service can be consumed by API as well (as by Service Broker), still the services are pre-defined and offer only limited way of variation (like parameters) for the user.

Cloud Assembly is a new component that has been introduced and addresses these requirements. It can be used to create blueprints for the Service Broker catalog, but it can also be used directly by the users to model and deploy services. Modeling can be done by graphical elements as well as yaml descriptions. Both options are shown in a side-by-side view and users decide based on their preference.

Cloud Assembly – Infrastructure-as-Code modeling and consumption of blueprints

One big difference compared to Service Broker is that a user in Cloud Assembly can model the service according to his needs. Developers can select from a variety of services components which will become even more in upcoming releases of vRealize Automation. Example components are: vSphere, AWS, Azure, Google VMs as well as higher level public cloud services like Lambda, RDS, Puppet, Ansible, Kubernetes Clusters and Namespaces, Networking, Security.

There’s no limits and restrictions in place for the service itself. A user might assemble e.g. a service that consists of 2 VMs on-premise, an on-demand network segment, security group attachment plus a public cloud service. When created, this service directly will be provisioned based on the yaml specification without the need to reach out to IT and request adding it into the catalog.

IT-Admins can however define resource limits (like number of VMs, memory) for the user to control resource consumption in scale environments.

Defining resource limits on cloud zone

A developer can use the graphical interface to model his service or simple use a yaml file and directly start the provisioning. Examples of YAML files can be provided by the IT department and e.g. stored on a github repository to give users access to them. Cloud Assembly syncs content from a github or gitlab repository automatically.

Blueprint repository on github

As a summary vRealize Automation can expose a classic IT services catalog + very flexible developer services (IaC) on a single platform.

Consumption by CLI/API

Cloud Assembly offers a flexible REST API. Documentation is available on public web pages and applies to Swagger standards. Developers can use their tool of choice (like postman, curl) to access the API and consume as well as manage services. Users may want to integrate resource provisioning into automated processes like CI/CD pipelines or others.

As an option vRealize Automation also offers a CLI interface which can be used to access Cloud Assembly. This is called VMware Cloud Services CLI and can be downloaded after logging in with a myVMware ID.

For the API as well as CLI the user can specify a pre-defined blueprint for provisioning or just provide a YAML file that includes all details. Authentication to vRealize Automation is done by an authentication token. All resource limitations defined by the administrator automatically are considered to put restrictions for the user in place and limit resource waste. VMware Cloud Services CLI is available for OS-X, Linux and Windows

VMware Cloud Services CLI

Command examples:


login to vRA / vRA Cloud by refresh token or username and password

cloud-assembly blueprint deploy –blueprint Ubuntu-Server-DEV.yaml –project “App__Development” –deployment “UBUNTU-DEPLOYMENT”

Start deployment of blueprint “Ubuntu-Server-DEV.yaml” as defined in the yaml file. The yaml can be created by the Cloud Assembly designer and afterwards will be modified to the user’s needs.

Deployment of a blueprint by CLI
Day-2 management of the resulting deployment

Consumption by Terraform

Terraform is an open source based tool to provision and manage resources in a multi cloud environment. Definition of resources to provision is done by text-based terraform files which have their own syntax. For each provider (vSphere, AWS, Azure and others) separate syntax must be used. There’s a big developer community that uses Terraform as a tool. While Terraform works well in smaller teams there’s challenges in high scale environments as it lacks governance and central management.

For users that want to consume services by Terraform CLI VMware offers a terraform provider which talks to Cloud Assembly or Service Broker and consumes related services. Similarly to native UI or CLI consumptions, resource definitions, limits, user permissions and related configurations on the vRealize Automation platform are honored which enables a highly scalable and controlled platform.

Also, vRealize Automation provides an abstraction layer for consumption of resources from multiple clouds like vSphere, AWS, Azure and Google. Consumers can benefit from real cloud-agnostic blueprint specifications that can be applied without modification to any of the mentioned clouds. Developers don’t need to care about different syntaxes for the clouds in question.

In an environment where no vRealize Automation is in place, terraform would talk directly to vSphere for consumption of on-premise resources with the related provider in place. This provide considerable risk as it’s almost impossible to control and govern resource consumption especially when the environment scales. In general users should not be given direct access to the “heart” of IT infrastructure – the vSphere environment.

vRealize Automation closes this gap and acts as central governance layer between vSphere (and other clouds + 3rd parties) and the consumption interfaces like terraform.

Example main.cf tile (terraform description)
“terraform init” command – deployment as per definition in main.cf
Day-2 management of the resulting terraform deployment

Customers might closely evaluate if there’s the need to supply and maintain another utility for resource consumption as vRealize Automation as a platform already provides all various options. Why using another tool when Cloud Assembly services from multiple clouds and 3rd party integrations can be consumed by the out-of-the-box provided GUI/API/CLI already?

Container and Kubernetes integration

In developer scenarios Kubernetes and Containers are broadly used. This is why vRealize Automation 8/Cloud has got native support for Kubernetes. vRealize Automation integrates with VMware PKS and can import existing Kubernetes clusters. In addition, support for openshift has been added to vRealize Automation Cloud which will be part of the next vRealize Automation 8 release, too. Going down the road vRealize Automation will also integrate with the announced Tanzu portfolio and Project Pacific enhancements. This gives customers the assurance that they can manage modern application infrastructure based on Kubernetes today as well as in future.

Consumers can provision Kubernetes on-demand when Kubernetes management tools like PKS and openshift are used. For provisioned or existing Kubernetes cluster the vRealize Automation platform provides Namespace-as-Service. Developers can request a new namespace and furthermore can download the related kubeconfig file for use with kubectl command.

Management of external Kubernetes clusters
Namespace as a service in Service Broker
Day-2 management of namespace (kubeconfig download)

Currently deployment and day-2 actions can be performed in the graphical UI. VMware Cloud Service CLI in version 1.1 does not have support for day-2 actions yet.


Bringing it all together: vRealize Automation 8 / Cloud has full integration of developer use cases. This consists of

  • Infrastructure-as-Code support
  • REST API for consumption
  • CLI for OS-X, Linux and Windows
  • Terraform Provider
  • Native support for Kubernetes and Kubernetes Management Tools like PKS and openshift

Customers can benefit from various consumption models with central governance and multi-cloud support. Besides that, vRealize Automation is the platform for IaaS (virtual machines and related components), XaaS (custom services) and many other services which allows customers to have one central multi-cloud layer for easy service consumption.

Christian Ferber

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.