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

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.

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.

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 + 3^rd parties) and the consumption interfaces like terraform.

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 3^rd 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.

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.

Summary

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.