Just when you thought the misconceptions regarding cloud computing couldn’t get any worse…they do.

We have, in general, moved past the question “what is cloud” and onto “what do I need to do to move an application to the cloud?” But the question “what is cloud” appears not to have reached consensus and thus advice on how to move an application into the cloud might be based on an understanding of cloud that is less than (or not at all) accurate. The problem is exacerbated by the reality that there are several types or models of cloud: SaaS, PaaS, and IaaS. Each one has different foci that impact the type of application you can deploy in its environment. For example, moving an application to SaaS doesn’t make much sense at all because SaaS is an application; what you’re doing is moving data, not the application. That makes it difficult to talk in generalities about “the cloud”. 

This lack of consensus results in advice based on assumptions regarding cloud that may or may not be accurate. This is just another reason why it is important for any new technological concept to have common, agreed upon definitions. Because when you don’t, you end up with advice that’s not just inaccurate, it’s downright wrong. 

Consider this post offering up a “Practical Top Ten Checklist” for migrating applications to “cloud.” It starts off with an implied assumption that cloud apparently only supports web applications:

1. Is your app a web app? It sounds basic, but before you migrate to the web, you need to make sure that your application is a web application. Today, there are simple tools that can easily convert it, but make sure to convert it.

First and foremost, “cloud” is not a synonym for “the Internet” let alone “the web.” The “web” refers to the collective existence of applications and sites that are delivered via HTTP. The Internet is an interconnection of networks that allow people to transfer data between applications. The “cloud” is a broad term for an application deployment model that is elastic, scalable, and based on the idea of pay-per-use. None of these are interchangeable, and none of  them mean the same thing.  The wrongness in this advice is the implied assertion that “cloud” is the same as the “web” and thus a “cloud application” must be the same as a “web application.” This is simply untrue.

A 'cloud' application need not be a web application.  Using on-demand servers from infrastructure-as-a-service (IaaS) providers like Rackspace, Amazon, and GoGrid, you can operate almost any application that can be delivered from a traditional data center server.  This includes client/server architecture applications, non-GUI applications, and even desktop applications if you use Citrix, VNC or other desktop sharing software.  Web applications have obvious advantages in this environment, but it is by no means a requirement.

-- David J. Jilk, CEO Standing Cloud

As David points out, web applications have obvious advantages – including being deployable in a much broader set of cloud computing models than traditional client/server applications – but there is no requirement that applications being deployed in “a cloud” be web applications. The goodness of virtualization means that applications can be “packaged up” in a virtual machine and run virtually (sorry, really) anywhere that the virtual machine can be deployed: your data center, your neighbor’s house, a cloud, your laptop, wherever. Location isn’t important and the type of application is only important with regards to how you access that application. You may need policies that permit and properly route the application traffic applied in the cloud computing provider’s network infrastructure, but a port is a port is a port and for the most routers and switches don’t care whether it’s bare nekkid TCP or HTTP or UDP or IMAP or POP3 or – well, you get the picture.

This erroneous conclusion might have been reached based on the fact that many cloud-based applications have web-based user interfaces. But when you dig down, under the hood, the bulk of what they actually “do” in terms of functionality is not web-based at all. Take “webmail” for example. That’s a misnomer in that the applications are mail servers; they use SMTP and POP3/IMAP to exchange data. If you take away the web interface the application still works and it could be replaced with a fat client and, in fact, solutions like Gmail allow for traditional client-access to e-mail via those protocols. What’s being scaled in Google’s cloud computing environment is a mix of SMTP, POP3, IMAP (and their secured equivalents) as well as HTTP. Only one of those is a “web” application, the rest are based on Internet standard protocols that have nothing to do with HTTP. 

The boundaries to enterprise cloud computing have nothing to do with whether or not your application is optimized for the web.  In fact, we have a large number of cloud customer running applications that are not only not traditional “web apps,” but also don’t even connect to the internet.  We have customers running SAP, Oracle DBs, SQL DBs, Point of Sale Systems, Purchasing, etc..  Many of these are legacy client / server applications, the cloud has allowed IT departments to get rid of the servers, but for now the clients are alive, well and running more efficiently using a cloud enabled back end.

-- Christopher Drumgoole, SVP Engineering & Development @ Terremark

REDUX: “THE CLOUD” can support virtually any application. Web applications are ideally suited to cloud, but other types of client/server applications will also benefit from being deployed in a cloud computing environment. Old skool COBOL applications running on mainframes are, of course, an exception to the rule. For now.

We’re going to skip to number ten now, because if we went through every item on the list, well, we’d be here all day. The good news is that some of the advice is actually good advice that is not based upon the premise that cloud only supports web applications. Even a blind squirrel can find a nut sometimes, you know.

10. Scalability and redundancy capabilities. Are you able to provide full dynamic scalability and redundancy capabilities to the server parts of your app? It is important to realize that these are directly affected by the technologies that you use, and their ability to scale. When it comes to ability to scale, if you cannot scale dynamically, you simply can’t move to the cloud. 

Okay, this one is a bit tricky because honestly I’m not sure what the author is trying to say. The first question seems to imply that the customer, you, are responsible for dynamic scalability and redundancy. Now I don’t know about you, but I thought that was one of the big value propositions of cloud computing; cloud dynamically scales applications for you. You don’t need to know how or why or what they’re using to achieve that, but they can do it because, well, that’s part of the fundamental attributes of a cloud: elastic scalability.

Trying to give the author the benefit of the doubt, it might be that this statement is trying (failing, but at least trying) to point out that some applications aren’t very scalable. That’s true, even with the help of cloud’s elastic scalability features. The problem is that point number one told us we had to be web-based to move to the cloud, and web applications are one of the most scalable application types there is. Web applications are delivered over HTTP, and we (as in the industry) have over a decade of experience scaling web-based applications. Too, we understand how to make just about any application, any protocol, redundant. We do that, too, via essentially the same mechanisms we use to scale applications – through one of the core features of load balancing solutions: failover. Perhaps the author was trying to point out that applications relying on state require “sticky sessions” and that this inhibits the ability to deploy in a load balanced environment without support for persistence (a.k.a. sticky sessions)? That can be true, unless you choose your cloud provider carefully and ensure that they support the notion of persistence in their load balancing (auto-scaling) implementation. Many do: see Amazon ELB and GoGrid load balancing APIs for examples. 

REDUX: ONE of “THE CLOUD”s fundamental attributes is that it enables elastic scalability and, through such scalability implementations, a measure of redundancy. Nothing special is necessarily required of the application to benefit from cloud-enabled scalability, it is what it is. Scalability is about protocols and routing, to distill it down to its simplest definition, and as long as it’s based on TCP or UDP (which means pretty much everything these days) you can be confident you can scale it in the cloud.