Answer this. What is a Cloud Application (to you)?

By Atos Apprenda Support

Flip through any vendor marketing material or industry pundit blog post or article, and you’ll see copious use of the term “cloud application.” You’ll be surprised to know that asking nearly anyone in the industry the simple question of “What is a cloud application?” results in all kinds of responses ranging from <Blank Stare> to “A cloud application is X”, which is totally different from what someone else told you 5 minutes ago when they answered with “A cloud application is Y”. Some of the more common ones I’ve heard are:

  1. Any application “running” in the cloud
  2. Any app that is mobile/social
  3. SaaS apps like Salesforce
  4. Apps that are at Facebook scale
  5. There is no such thing as a “cloud app”

That is a tremendous amount of deviation. What’s even more curious is that we don’t, as an industry, have this problem with more traditional concepts like “SOA App” or “Client/Server App”. So what the hell is a cloud app then? At Apprenda, we spend a lot of time talking about the names and categorization of things – it’s almost a company-wide hobby. “Cloud application” has irked me enough that I decided to write this post to present some fundamentals of what might be considered a “cloud application”, so feel free to give feedback and constructive commentary!

To start, we need to define a framework for how to think about the definition of “cloud application”. If presented with an arbitrary application, what criteria would we apply to determine whether that app is a “cloud application” or some other class of application? Would the list look something like this?

  1. How it’s built
  2. How it’s used
  3. Where it’s hosted
  4. Some other attribute

Typically, a proper definition and taxonomy aims to be as context-less and absolute as possible. Following this rule reduces ambiguity and leaves little room for interpretation, which is necessary for a definition to have universal applicability. Thinking about definitions this way means that “How it’s used” and “Where it’s hosted” are poor ways to define a cloud application since those concepts are imprecise and changeable.

For example, if a cloud application is defined as being apps running on a cloud like Amazon, then is Facebook not a cloud app? If it was on EC2 and was considered a cloud app, and then was moved to its own data center, would it lose its “cloudiness?” I think you probably understand the absurdity of this. After going through this exercise, you’ll arrive at the conclusion that the best foundation for a definition is to define cloud application architecturally; that is, how an application is built – its architectural outcome – will determine if it is “cloud” or not. Interestingly, this is consistent with how we think about “SOA app” or “client/server app.”

Next, let’s look at some examples of apps we consider “cloudy.” Some that come to mind are Facebook, Salesforce, Google Docs, among others. In many ways, they are similar, and in other ways, they are different. Similarities include:

  1. They are all consumable in a service form factor. This means I never “have” Facebook or Salesforce or Google Docs, I merely get access to their functional qualities and outcomes.
  2. They do not have limitations in terms of the number of end consumers; that is, they are highly scalable.
  3. They are shared entities with varying levels of isolation between end users.

Some differences include:

  1. Isolation patterns are very different. Salesforce isolates and groups users into “tenants”, apps like Facebook have unit isolation where the coarsest grained unit is the user.
  2. “Scale” may be an order of magnitude different, requiring different architecture patterns.
  3. Functionality may include the need for complex data processing

Looking at this snapshot, a hierarchy evolves that helps define a “cloud application” in the following way:

Cloud Application Architecture Types

Essentially, all cloud applications must be “Service Consumable” – that is, they can be accessed as a service. Additionally, a cloud application must have at least unit tenancy where it can provide segregation between individual end users. Once these base qualities are met, cloud applications can then mix any of the 3 sub-types for a composite architecture that defines that cloud application’s total architectural foundation. The 3 sub-types are best understood as follows:

  1. Service Applications – Applications whose architecture up-level the service consumption model away from individual end users and into an architecture that groups users together and can segregate data and execution among groups, but share that data and execution within a group. We typically refer to these as a ‘SaaS’ apps but I’m avoiding using this term because it has certain implications that don’t make sense in the context of internal enterprise apps (where this sort of architecture has tremendous applicability).
  2. High scale applications – Applications whose architectures focus on achieving extreme levels of scale, needing to support high levels of concurrent access without compromise. Architectures rely on shared nothing models, data sharding, etc. to achieve this.
  3. Distributed applications – Applications that typical deal with large amounts of data or complex analytic requests that require parallel computation or divide and conquer models. In these architectures, multiple agents in a distributed topology coordinate and act against a common problem to derive a solution. Things like map/reduce and monte carlo experiments fall into this category.

As a cloud application adds DNA from each of these buckets to its architecture, its complexity begins to increase significantly. Enterprise app developers writing new apps don’t want to have to deal with this complexity, but need the architectural outcomes described. One of the things good PaaS offerings should do is equip developers to build cloud applications that fit these 3 buckets with as little effort as possible. In fact, if a PaaS is of the run-time variety, it should strive to provide these architectures as part of its underlying execution model so that guest apps can inherit these architectures. I could write a whole second post on this topic alone.

I think this is a good start, but is by no means comprehensive. What do you think? Are these the right buckets for defining a cloud app? Do we need more or fewer? Any feedback is appreciated! 

Atos Apprenda Support