VMware’s Solution to API Challenges

ChristopheChristophe 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 TechnologiesBased 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.

 

 

 

Other posts by

Building Infrastructure For Third Platform Apps– Top Down Or Bottom Up Approach?

World enterprises are struggling these days with a big question: how should they move forward to next generation third platform applications? In some of these organizations the transition stems from a business need; in others, the development teams are pushing for the change. While many development departments within today’s organizations are already starting to adopt new third platform development tools, their IT departments find […]

Why vCloud Air

It is no longer a question of: Should I consider Public Cloud to be part of my IT Strategy? But more of: Which cloud provider shall I use? The greater elasticity, economies of scale, and efficiency that the public cloud brings to the table when used in the right context are undeniable.  On the other […]

vCloud Air Disaster Recovery Options

Disaster Recovery as a Service (DRaaS) is becoming an industry trend as it offers tremendous cost savings for customers. Establishing a second and/or third datacenter for disaster recovery, maintaining them, and the operational cost of extra sites are all expenses associated with traditional Disaster Recovery. DRaaS solutions such as vCloud Air Disaster Recovery eliminate and/or […]