Cloud APIs and Programmatic Interfaces

This is a re-post of my article, originally published on The Ravello Blog

.

In talking about functionality and how a product works, people don’t always address the question of allowing interfaces into their software. As a product evolves and grows, the more important the implementation of programmatic interfaces becomes. APIs need to take the place of users sitting at keyboards to better facilitate access to interfaces, especially for large products.

Not everything can or should be done manually. For example, you don’t want to manually power on/off a thousand machines from your keyboard/mouse – it would take too long. When an environment exceeds a certain scale, you need to find a more efficient way to do things. For this reason, when a product is designed and built, you want it to include programmable interfaces that allow people to access interfaces in a programmatic way.

Almost all the cloud providers understand this and have been including such APIs from Day 1. This is true of VMware, Azure, Google, or even Amazon Cloud, with its very rich API, which can be used for almost everything, through API calls or Java components, and so on.

Different APIs for Different Products

But you have different APIs for different products; this is both good and bad. It is good for the vendors, in that it locks you into their products. Migration from one API/vendor to another is problematic. At the same time, the API makes it easier for the end users to handle what would otherwise be labor-intensive tasks in a more efficient, automated fashion. You can do this automatically with a program or a script, or with some kind of automation tool.

Vendors are beginning to be receptive to the idea of allowing their Cloud APIs to be open to the external community, and even external vendors. For example, Cisco UCS manager API is an interface that allows you to interact with underlying hardware so that anything you can do with the GUI, you can do through the API as well.

You can use APIs to embed your solution inside another solution. For example, allowing the interface into the API enables you to embed some kind of management portal inside another solution. This allows you to expand on the functionality that was originally there and differentiate between the default functionality and the added benefit that would like to add.

The idea of having an API, of course, is to expose it to the customer from Day 1 and to allow the customer to use it. Nonetheless, some vendors have APIs that are not exposed to the end user to prevent people from developing or using functionality within the product in a way that is not generally available or desirable.

As time goes on, the APIs are leading to better ecosystems. For the end user, the ideal solution would be to have some abstraction layer of APIs or a single API that is suitable for multiple vendors. This can make the end user’s life easier, eliminating the need to repeatedly recode everything. With regard to virtualization, APIs enable you to interact with multiple vendors using the same API calls, with an abstraction layer in between. It is not easy and does have its challenges, but there is growing interest in the concept of using an extraction layer for APIs and its implementation.