Cloud Assembly – Extensibility with ABX (FaaS) – Part1

A Brief Introduction

In this series of articles I am going to cover creating and deploying an extensibility use case based on ABX. Links to the other articles in this series can be found here:

Before I get into creating actions and writing code I want to explain what ABX is and how it works.

So, what is ABX? Quite simply it stands for “Action Based Extensibility” which uses a cloud service to execute actions based on events, which perform one or more tasks programmatically.

We are used to referring to extensibility as an on-premise thing which leverages something like vRealize Orchestrator to carry out programmatic tasks to enhance cloud functionality.

With the advent of the latest generation of Public Clouds (i.e. AWS, Azure etc.) the ability to run functions driven by events in the cloud without having to build the underlying infrastructure has arrived. This is known as FaaS (Function as a Service) and most cloud providers have their own implementation of this (for instance AWS has “lambda” and Azure has “Azure Functions”). With these types of services you generally pay for the compute time your code takes each time it is executed.

Each provider supports code being written in a variety of languages (Python, Ruby, Nodejs etc.) allowing an admin/developer to use whatever they feel most comfortable with.

Cloud Assembly with FaaS

At the time of writing this article Cloud Assembly supports AWS and Azure as FaaS providers. This means that you can leverage these services to run your own code as part of the deployment lifecycle process if you have a “Cloud Account” in Cloud Assembly defined for the provider (and a valid subscription for that provider).

What about on-premise you may be asking? Well with the latest updates to Cloud Assembly you can now use FaaS with on-prem by integrating a new VMware appliance (Cloud Extensibility Appliance) that includes an implementation of OpenFaaS.

The deployment of the extensibility appliance follows the same sort of process as the traditional on-premise Cloud Proxy, using a token provided in the Cloud Assembly GUI to link Cloud Assembly to the deployed appliance.

The implication of all this is that for on-premise you need 2 appliances, one for vCenter/NSX related activities and the other extensibility appliance that provides the platform for running your code. Of course you could elect to run the extensibility appliance on-premise and deploy your workloads to a public cloud provider or use FaaS from a public provider and deploy your workloads on-premise.

For more details on OpenFaaS head to

In the next articles I will cover how you go about using Cloud Assembly and ABX to deliver a use case.