With cloud usage on the rise, various cloud application programming interfaces (APIs) are emerging to connect end-users to databases via mobile or desk-based web interfaces.
There is no standard way of creating cloud APIs yet, but rather a range of approaches with their own pros and cons.
But the aim remains the same: to provide large-scale access to cloud resources, whether infrastructure-as-a-service (IaaS), such as Amazon S3 storage; software-as--service (SaaS), such as Salesforce; or a private cloud enterprise database, that needs to be accessed by the company’s army of field agents.
Organisations and cloud service providers currently use a range of APIs, including traditional SOAP/XML; Web 2.0-style lightweight JavaScript APIs; a slightly more modern REST/JSON [representational state transfer/JavaScript object notation]; or proprietary APIs such as VMware's vCloud API or Oracle Cloud API. Interestingly, Amazon S3 provides both a REST-type API and a SOAP API, catering for users at both ends of the spectrum.
Datacentre services firm Memset favours open source technologies and recently developed its own cloud API, currently available to customers in beta.
Juan Martinez, development manager, said: “When we started to design our public API we wanted to keep it as simple as possible, so our customers could use it from the command line on their servers with stock tools such as cURL or wget and no programming knowledge.”
“We believe the best option for this is to use a REST-like interface with JSON over HTTPS. It's simple, relies on a well-known and secure protocol (HTTPS) and, thanks to JSON, it provides a convenient way of structuring the API responses,” said Martinez.
However, Martinez said Memset wanted customers to be able to perform complex operations from their own applications as well, and with a RESTful API being too close to plain HTTP, it needed an abstraction layer that supported higher levels of service.
“Based on these requirements, the best solution was to provide two different interfaces for the same API methods: JSON over HTTPS and a high-level interface using XML-RPC (remote procedure call) protocol over HTTPS,” said Martinez.
Martinez explained that XML-RPC has been around for 14 years and is very well supported, with open source libraries available for almost all programming languages, “so we don't need to provide specific support besides documenting the API methods”.
Regarding the open source approach, Martinez said: “If you want your customers to build their business on top of your infrastructure, and that's what cloud is about, you must be as open as possible. Relying on open protocols and widely-used open standards is very important because it makes it easier for your customers to start using your technology.”
Mac Scott, associate director at KPMG CIO Advisory, observed that newer cloud API technologies – such as Memset’s REST/JSON over HTTPS combination - can offer more flexibility and platform-neutrality than traditional a service-oriented architecture (SOA)/Enterprise Service Bus (ESB) route, which is more infrastructure or middleware-centric.
In many cases, these approaches have delivered functionality using large, monolithic packages in the past, said Scott.
“Traditionally, SOA and ESB have been generally recognised as being developed from within an organisation, working to improve access and openness of the internal IT architecture,” Scott said.
"Cloud APIs are largely similar, in principle, but are being developed by third parties, made public to a much wider audience of users, and are generally specifically cloud-based and not proscriptive to particular hardware or software implementation.
“The benefits of cloud APIs include the fact they offer clear boundaries, they’re non-ambiguous, are testable and reliable. Having defined boundaries allows organisations to take functionality and data from a number of third-party systems and, using the APIs provided, build new functionality and interfaces which add value to existing systems.”
However, the main drawbacks are that, once an API becomes mass market, it also becomes more and more difficult to change, Scott warned.
APIs can mask a range of problems, said Scott.
“There are two main risks, which are often difficult to detect until the API is in full use,” Scott said.
"Either the API itself is compromised, or the underlying system has issues. Users may see a neat-looking API and interface, but when used in anger, these APIs may show significant performance problems, as the various layers in the suppliers’ system try to marshal the resources required to deal with each API call.
"Of course, these issues are unlikely to appear until the API has been in use for some time.”
One major benefit of a well-written cloud API is that it should be able to offer the enterprise differing levels of cost, resources, and service levels, and therefore greater flexibility, argued independent IT consultant Graham Oakes.
“What should be different about cloud APIs is their level of resource awareness," said Oakes.
"Under a traditional SOA, calling an API may have costs, service levels, and so on, attached to it – although few are stated explicitly in most organisations. But these are all pretty much single points: calling the API costs so much, and it'll deliver within certain SLAs. If you don't like it, find another API.
“With the cloud, there's potential for these things to be measured against resources: call the API while allocating X amount of compute resource and it'll cost so much, and deliver within a given SLA. But you also have the option to call it with 0.5X, 2X or 3X of allocated computing resource, in which case the cost and SLAs also move in predictable directions.”
Oakes added that an organisation could call the API at some other time of day, and get a completely different “resources versus cost and SLA” curve.
“I don't know of anyone using cloud APIs in this way. But this is the promise of the cloud — you can flex the resources you allocate in order to dynamically balance cost/value trade-offs. But most people are just using cloud as a different deployment location for otherwise unchanged components of their SOA. This gives some -- sometimes substantial -- cost and flexibility benefits, but it lacks the dynamism that might eventually be possible,” concluded Oakes.
05 Oct 2012