Right now there are two different SDKs that provide different vSphere API bindings. First, the vSphere Automation SDK provides bindings for REST vSphere services. This includes the following services:
VMware vSphere Automation Endpoint in vCenter Server
VMware Cloud on AWS Console APIs
VMware NSX-T on VMware Cloud APIs
NSX VMware Cloud on AWS Integration APIs
VMware Cloud on AWS Site Recovery APIs
The vSphere Management SDK provides bindings for SOAP VMware services. This includes following list of services:
One of the biggest challenges is the multiple SDKs for automating software-defined datacenter (SDDC) management workflows. There are two SDK bindings for each programming language. For example, we have pyvmomi for accessing vSphere SOAP APIs, and the vSphere Automation Python SDK for accessing vSphere REST APIs.
There are different distribution channels, with the Automation SDK hosted on VMware’s GitHub repository and the Management SDK hosted on developer.vmware.com. You can also get pyvmomi from the PyPI repository, but not the Automation SDK for Python. Additionally, some customers cannot access and use open-source software, such as what we host in our GitHub repositories.
This is confusing, complicated, and adds friction to vSphere and SDK release cycles. Speaking of release cycles, some of our partners require early access to our SDKs to test their solutions and fix any issues in time. However, SDKs are not part of the VMware Beta programs and we cannot provide our customers with the latest version before the GA (General Availability) version is released. This prevents us from receiving early feedback from our customers, but also prevents our customers from starting early integration/update of their software and products for the upcoming vSphere releases.
Put simply, we need to improve the SDKs:
Improve the developer & user experience.
Make the distribution mechanisms consistent.
Find a way to enable earlier access to the beta SDKs to gather feedback.
Let’s talk about how we are doing that!
Consistency in Delivery
Starting with vSphere 8, we are delivering all SDKs on developer.vmware.com. This helps customers who cannot access open-source repositories, giving them a trusted and consistent location where they can find the SDKs:
We are addressing the outstanding issues raised by the community members in the pyvmomi GitHub repository of the project, as well as embracing some of the suggestions. For instance, the latest release of pyvmomi 8.0.1.0 introduces new auto-completion functionality that significantly improves developer experience. We have also increased the rate of updates to the SDK so that we can more rapidly improve the quality of the pyvmomi SDK.
OpenAPI Support
We have introduced OpenAPI v3.0 support, allowing us to get coverage in the SDK for the new VMware Cloud APIs that are also defined with OpenAPI 3.0 and are available in the VMware Cloud API Explorer. We added those bindings to vSphere Automation SDK for Go, and now this functionality is also available in the VMware Cloud Terraform provider.
What’s Next?
We are working to enhance the user experience by streamlining our vSphere SDKs. Our next move is to launch a single SDK that integrates bindings for both SOAP and REST-based APIs. This consolidated SDK offers intuitive access to all SDK libraries in users’ preferred programming languages. By centralizing the location for developers to obtain all essential libraries, we ensure robust documentation, a reliable download source, and visibility in public package repositories such as PyPI and Maven Central.
We are also gearing up to incorporate bindings for the new JSON protocol. This protocol was introduced to offer a REST-like representation of the SOAP APIs.
We are keen to grant early access to our customers and partners. This way, we can gather feedback before the official release.
Our aim is to ensure a uniform development experience across all supported programming languages. One of our goals is to cater to Reactive programming models, like the async/await feature in Python bindings. The demand for async/await capabilities is high, and it is an option currently unavailable to our users. Not for long!
