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?

What is an API and how is it different than a Web service? »

Over two years with Sonoa, I’ve talked to customers about APIs for hours every day and see a lot of common patterns. I thought I’d start this blog out by talking a little bit about what we've seen. More companies of all sizes are building web services APIs so that they can make their own capabilities available to a wider audience. The concept of an “API” on the Internet is not new but it’s been taking off, especially recently. At this point, if your company isn’t offering such API, it probably will be before long.

What’s an API? In computer science we’ve used the term “Application Programming Interface,” or “API,” for pretty much forever. Everything from the Windows operating system to the Oracle database has an API. What I’m talking about is a little more specific — a “web services API”. That means some functionality that you can invoke over the Internet. Specifically, an “API” in this context:

• Is invoked over the public Internet
• Almost always uses HTTP (or HTTPS) as its communications protocol
• Often uses XML to represent a response
• Often uses either HTTP query parameters or some XML to represent a request

For these reasons, a good API often requires no special client-side software. The most successful APIs, like the Twitter API, can be used from anywhere on the Internet from literally any programming environment that can communicate using HTTP. The most effective and popular APIs are also simple.

For instance, in order to see the current status of Lance Armstrong on Twitter as an XML document, all I have to do is perform an HTTP GET to this Twitter API URL. And there are tons of examples like this - sites like ProgrammableWeb provide a great directory and stats of many APIs.

Aren’t API’s just web services? Well, yes they are. In fact, all web services match the description I put in the section above except for one thing — a web service does not necessarily have to be accessed using the public Internet. In fact, an awful lot of web services today run inside a corporate network and are never touched by the Internet.

But on the Internet the term “API” has become a lot more prevalent than the term “web service.” that is partly due to semantics — “web service” typically implies “SOA,” which to many people implies “SOAP,” which in turn makes people think, “big, complicated, and expensive.” (And if you don’t know what I was talking about in this paragraph then you probably had the same reaction.)

So from a purely pedantic perspective, an “API” is just a “web service.” But that doesn’t mean there isn’t an important distinction — typically, something called an “API” is designed for the Internet, to be consumed by many different types of clients, and if it is successful it is pretty simple. On the other hand, a SOAP web service running on a big “web services stack” inside a corporate network could be a thing of beauty that is widely adopted, or it could be a tangle of spaghetti that keeps one or two applications intimately intertwined for the foreseeable future.

Why build an API? One short answer is that an API is a great way to get more people to use the services that you offer. For instance, most Twitter traffic comes from its API, not from the web site. (If you’re using a desktop Twitter client like Twhirl or Spaz or even some of the iPhone or Blackberry apps, you’re using the Twitter API.) It also lets you focus on the functionality that your company provides rather than on presentation. Do you run a trucking company with great scheduling and routing capabilities? You can expose those as an API that your clients can embed into their own applications more easily than you can build a slick web site and keep it up to date with the latest fashions in web site design and implementation.

Next time I'll talk about some common challenges we see for folks building APIs. - Greg