Loading Search...

API Best Practices Blog

Why should you care about “Cloud Services?” »

IDC has posted an overview of what the term “cloud service” means, including an eight-point checklist. Here's my own shorter version on this.  A 'cloud service':

  • Is accessible over the public Internet. 
  • Is accessed using standard web services protocols like XML or JSON over HTTP — proprietary client-side hardware and software are not acceptable.
  • Is billed elastically, so consumers can pay for what they use.
  • Scales elastically, so consumers don’t not need to worry about capacity as long as they stick within their SLAs.

Is a Cloud service any different than an API or a web service?

Is a “web services API” a “cloud service?” Yes!  However, I have two problems with the generic term “API.” The first is that a “API” on the web today implies something like Twitter or Google — not an enterprise-type service. The second problem is that “API” means a lot of things other than “web service” - such as “JDBC API” (non-XML APIs) vs. “Twitter API”.

Is “cloud service” just another term for a “web service?” No!  First, unless it’s available on the Internet, then it’s not a “cloud service.” Lots of web services are internal to a company and aren't.  Second, “web service” has come to mean SOAP, WSDL, and other “enterprise-y” technologies. (For instance, see the Wikipedia definition, which as of today, at least, shows a diagram of a “web service” complete with SOAP, WSDL, and UDDI.) There’s no reason why you can’t build a web service without these technologies, but if you do you face an uphill battle against those who assume that “web service” means “SOAP.”

So, is a web application a cloud service? IDC thinks it is, but I’m not so sure. Salesforce.com pioneered “SaaS,” and they have offered an XML-based API for a long time now — that’s truly a “cloud service.” However, when you log in to the Salesforce.com web site using your browser, are you using a cloud service — inasmuch as every interactive web site has aspects of a cloud service, then yes, but I think that’s making the definition too broad.

In the end, I like a very simple definition of a “cloud service” – a web service, running on the Internet, that can be used in an elastic way.

So what?

Most of us are already using cloud services. Twitter is a cloud service. The Salesforce.com APIs are cloud services, as are the APIs provided by UPS and FedEx. (And as far as I know, none of those cloud services “run in the cloud” — they run in traditional data centers or co-lo facilities.)

A cloud service is a great way to expose your core functionality in a lot of new ways. For example:

  • By offering transit times, rate quotes, and tracking as a cloud service, then FedEx and UPS allow all sorts of third parties to integrate their services directly into their applications, where previously a user had to visit the web site. This makes it easier for their customers to use their services.
  • By offering their catalog as a web service, Amazon makes it possible for for other retailers and manufacturers to provide customized storefronts but let Amazon do the heavy lifting. This gets Amazon more distribution.

On the other hand, not everything is yet available as a Cloud service. Would it be easier to build an air-fare aggregation engine like Orbitz or Kayak if all the airlines offered a cloud service to get access to schedules and fares? Absolutely! Do the airlines want that? Not sure.

Or, what about all the systems today that communicate using FTP, or EDI VANs, or VPNs, or fax, or tapes being sent via UPS? Would those systems be a lot more effective if they communicated using cloud services instead? What do you think?