Brail’s Blog

Everyone is talking about “cloud computing.” There’s a ton going on out there, and a ton of confusion. I’d like to talk about not cloud computing in general, but the concept of “cloud services” and why they’re important.

IDC has posted an overview of what the term “cloud service” means, including an eight-point checklist. I’d like to offer my own, shorter version on this. In my opinion, 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.

Now, this is different from “cloud computing.” “Cloud Computing” (again, see IDC) is about running your infrastructure in an elastic environment. You can run a cloud service “in the cloud” by building it on Google App Engine, or Microsoft Azure, or by building your own app and deploying it on your server in EC2. But you can also build a cloud service on an enterprise network and run it from your own DMZ, or run it on a server in a traditional co-location facility. In fact, I suspect that the majority of cloud services deployed over the next few years will run in traditional data centers and will not actually run “in the cloud!”

How is that different from an API or a web service?

Is a “web services API”, like I talked about last time, a “cloud service?” Absolutely. However, right now 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 that provides a service so valuable that it’s worth paying money for. The second problem is that “API” means a lot of things other than “web service” and the distinction between, say, the “JDBC API” and the “Twitter API” is lost on less-technically-oriented people.

Then, 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.” 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 you are probably 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 call or visit the web site. This saves UPS and FedEx money, and it makes it easier for their customers to use their services — which means they get more business.
• By offering their catalog as a web service, Amazon makes it possible for all sorts of other retailers and manufacturers to produce a pretty, up-to-the-minute web-based storefront however they want, using whatever graphic design people are the best for the job — but when it comes to the boring, hard work of taking money and shipping products, that cool site can just delegate to Amazon without losing control of the user experience.

On the other hand, a ton of stuff today does not take advantage of this technology. 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? It doesn’t seem like it.

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?