Strategic Advisor

VMware’s Solution to API Challenges

CTO Ambassadors Group

October 1, 2015

Christophe Decanini is a consulting architect and a member of the CTO Ambassadors group at VMware. He joined VMware in 2007 as part of the acquisition of Dunes Technologies. Based in Gland, Switzerland, Christophe is an automation and integration expert supporting VMware customers, partners, and field resources globally. Christophe has worked on several important contributions, including product features that participated in making vRealize Orchestrator becoming a successful product. He has presented orchestration solutions at conferences such as VMworld, and is a main contributor to the www.vcoteam.info blog and the official VMware Orchestrator community. Christophe reviewed and contributed to books that cover Orchestrator, including VMware vCloud Architecture Toolkit and Automating vSphere with vCenter Orchestrator (both from VMware Press), VMware vRealize Orchestrator Cookbook, and VMware vRealize Orchestrator Essentials (both from Packt Publishing). He has 20 years of experience in IT automation, was awarded the vExpert designation for several years , holds a VMware Certified Professional 5 – Data Center Virtualization (VCP5-DCV) certification and a bachelor’s degree in computer science. You can follow Christophe on Twitter @vCOTeam.

VMware has a rich set of application program interfaces (APIs). These APIs expose most of the features of VMware’s products, and are very often very extensive. While they give a developer the ability to integrate and automate pretty much everything, there is still much complexity that introduces friction when working across products.

All software companies, VMware included, face challenges in trying to provide a unified automation and integration experience:

Organizational silos may create different API designs (see Conway’s Law)
APIs are inherited with products which may have come from an acquisition that will likely have created different designs
APIs designed for private (i.e. vCenter) or public (i.e. vCloud) consumption expose different degrees of control and detail
Management products must have authentication and session mechanisms, but because there are many possible choices those mechanisms could be different
API technologies evolve over time, but backwards compatibility requirements sometimes prevent products from shifting to the latest technology. For example, vSphere and SRM expose APIs using SOAP (Simple Object Access Protocol), while newer products use the REST (Representational State Transfer) software architecture style
Within REST API conventions, the industry has evolved from using XML (Extensible Markup Language) to JSON (JavaScript Object Notation) as the preferred encoding format. Products developed over these transition periods use different encoding formats

Even when companies standardize on using exclusively REST/JSON APIs, there are different implementation styles for URLs, verbs, content format and documentation.

These APIs are consumed by other management tools and by different language bindings. VMware spends considerable resources producing bindings in the form of Software Development Kits such as Java, Python, .NET, Ruby, Perl and automation tools such as PowerShell, DCLI or vRealize Orchestrator. However, each binding offers different API coverage for different VMware product features. As a result, our customers and partners have to balance their developers’ language binding preferences with the bindings’ specific capabilities.

With the emergence of the vCloud Suite the ideal approach would be to provide a single consistent API implementation whether consumed at the REST layer, via software SDK, PowerShell, or vRealize Orchestrator. To make this possible this API needs to be defined using a programmatically consumable description of the API that we call metadata. This will enable automated generation of the language bindings and automatic mappings to expose commands and activities to automation tools like CLIs and vRealize Orchestrator. This API methodology and infrastructure also need to be designed to be extended to new products regardless of whether they are VMware products or from the rich VMware ecosystem.

These API challenges now have a solution, and not only does it exist—but it has been released and is available! This API is the basis of the “VMware vCloud Suite SDK” package. Informally, we call this project to unify and improve our APIs “vAPI”.

A vAPI endpoint is already built-in and running in vCenter 6, exposing APIs to recent functionality such as the tagging and transfer services, and content library. While this limits the operations that can be automated, this is just a start, and will be steadily extended further with each subsequent product release. Some of the APIs for existing products in the vCloud Suite are good candidates for being adapted to this approach. Some new product capabilities will release APIs using vAPI as their main web service interface. A retrofit effort to expose more modern ways to program against existing vCenter capabilities is also in progress.

vAPI is designed in a way that it can be extended to provide seamless access to multiple products from both VMware and possibly 3rd parties. For this to happen the products need to implement a component called “provider” that registers its API endpoints and metadata with a vAPI endpoint or a load balancer cluster of vAPI endpoint nodes. This is a compelling feature for integrating the vCloud Suite in a highly available environment. A provider is developed with the Provider Development Kit, which at the moment is only available within VMware.

The first release already supports a number of important language bindings:

By leveraging the metadata, it is possible to extend this list with new bindings.

In the future we expect many new products to provide a vAPI programmatic surface and be accessible through the rich set of SDKs, Powershell, DCLI and vRealize Orchestrator.

If you are interested and want to learn more, in order to illustrate the capabilities of vAPI I have released a tagging plug-in for vRealize Orchestrator including a demo video and written a REST tutorial. Check them out and let me know what you think.