The availability and variety of services in the cloud is continuing to grow, with more and more vendors offering their platforms, software or infrastructure as a service. While the concept of a private cloud has yet to get much traction, hybrid clouds and the integration of traditional on-premises applications with cloud hosted services are starting to become business as usual. This is creating a marketplace where enterprise architects...
and CTOs have a real choice when it comes to scaling their IT out into the cloud.
There are many levels at which vendors make their cloud services available to customers, from providing raw compute power and storage in the form of infrastructure as a service (IaaS), through hosting of bespoke business logic components on platform as a service (PaaS) offerings, to delivering a complete solution to a particular business problem with PaaS. All of these have one thing in common: they need to provide some kind of interface, and while a Web-based control panel looks pretty, it doesn't really scale enough for large businesses -- the primary adopters of cloud hosted services. For this reason, cloud providers offer APIs that allow companies to interact with them in a variety of ways.
We need to make sure we don't get lost in this dream world of fully integrated systems.
Like with all architectural decisions, there is quite a lot to consider when deciding how and when to use the integration API provided, and the availability and suitability of APIs should be a key factor in selecting a cloud service provider. The following sections explore some key considerations to keep in mind during the selection process.
Do I need a provider with an API?
The short answer to this is always yes. Even if a company's current requirements don't include integrating the cloud service with anything, not being able to do so in the future is likely to cause problems. Therefore, I would argue that the availability of APIs should be a key factor when deciding which cloud service to use. Look at whether the API allows the company to integrate with other cloud services, particularly those of competitors, as that will give a good idea of how open the provider is prepared to be. Consider how to integrate on-premises services with the cloud provider's. What technology does the API use? Is it a REST service, SOAP, a library for a programming language, or are all of them available? How does that fit in with how you already build and integrate your on-premises applications? I'd also advise that businesses check to see how well documented the API is. Explore the common complaints about the API on forums and discussion groups.
It is also worth considering whether a third-party cloud API provider -- who provides an API that integrates the back ends of a number of providers -- offers a better way of interfacing with the service. While a third-party option may provide a way to switch between providers, or select services from whichever provider is lowest-cost or best meets the needs of a particular request, it should not really be considered a way to insulate the company from dependency on a vendor. There are no standards around the cloud integration API, and replacing dependency on the service vendor with dependency on an API vendor still means using a proprietary API. In fact, a company that provides APIs into other people's services is fairly intangible, making it hard to qualify concrete benefits. I would consider these APIs to be marginally less likely to continue to exist than those of the service providers themselves.
How do I use them?
While the uses of a cloud API may at first seem obvious -- integrating the cloud service into other on-premises systems or to other cloud services -- they can be more powerful than that, and their correct use requires some thought. Having a system with a well-documented and powerful API is a state of nirvana that is hard to reach with in-house systems. The budget just isn't there to allow developers to write APIs that may be useful in the future, but have no benefit now. With a cloud service, however, someone has already gone to the trouble of putting the integration API in place. This opens the door to a number of integrations that may not at first be obvious. An enterprise monitoring system can integrate with its PaaS or IaaS provider and provision more capacity when it detects high demand. A business's inventory system can post to social media when it receives a shipment of a high-demand item. The authorization service can lock a user's account when their employment gets terminated. The potential integrations available when all a company's services have well defined APIs increases significantly, so long as integrating the APIs has business value.
Another key decision when working with a cloud service is which API to use. Most will have a RESTful or other simple HTTP API available, and this can be the simplest way to integrate. However, the loose nature of these APIs means that considerations like API versioning need to be considered. If a business already has an investment in Web services as an integration technology, it may find a SOAP- or HTTP-based service provides an easier platform to build on, and one that is better understood and catered to in the organization.
However, we need to make sure we don't get lost in this dream world of fully integrated systems. There are no standards here, and all the APIs we are using are proprietary to the service vendor. It is important to minimize the impact of the vendor changing APIs, discontinuing the service or even disappearing altogether, and we would like to maintain as much control as we can over our APIs. This is where good old-fashioned service-oriented technologies and approaches help, allowing us to control the integration of our services, whether they are in the cloud or on-premises.
Cloud service APIs are an attractive part of cloud services, but as with all services, the advantages and disadvantages of a particular implementation need to be considered before deciding which is the best approach for an organization.