I’ve been thinking a lot about the ins and ou’s of “The Fog,” which seems a more accurate description of the cloud in its current state.  Specifically, I’m trying to wrap my brain around long-term sustainable business models – which in turn gets me to think about legitimate applications for using the cloud.

The way I figure it, these are two basic attributes the market MUST require in order for external cloud providers to ultimately find success:

1.  The want/desire to push infrastructure operations to an external provider.

2.  An application, or use case, that “fits” with the extended latency and bandwidth limitations that the cloud creates.

Note that I am not talking about cost here (for now).  Note that I am not talking about hybrid or private clouds either, although the application requirement would remain the same regardless.

Let’s take number 1 as a given – those who could get rid of internal IT services to support this type of use case/application, will.  I’ll assume the costs make sense and the stars line up.

That gets us to the heart of the issue: the use case.  By default, the cloud adds latency to transaction times.  Thus, that should be the central consideration when choosing the applications that make sense to deliver via that means.  Second, the bandwidth/throughput capabilities of the cloud are also at their weakest versus locally attached infrastructure, and therefore understanding those requirements become paramount.

So a perfect application for the cloud will have limited bandwidth/throughput requirements – in either direction - and be able to tolerate higher levels of latency.

What Works:  Apps like SalesForce.  Why?  Because the data involved in a CRM record is small – both going out to the cloud and retrieving it back.  Latency isn’t an issue because individual users are fine dealing with the web.  CRM records are the web equivalent of small, random access IOs – perfect for the cloud.  Online banking has proven a wildly successful cloud application for the exact same reasons.  The only time you really wait is to view images and even then, it’s inconsequential as you tend to only view one or two.

I wrote recently that BI is my call for a killer cloud app because it works in this model.  Data leaves corporate systems and asynchronously populates a big fat store in the ether – in perpetuity.  Every day, new data is created and used for whatever case is required locally and then replicated to the uber-store in the cloud.  It’s only moves ONE WAY (out).  Once it’s out in the cloud, it never has to come back (the primary data sets have either served their purpose and been disposed of or are still in use by internal IT), so bandwidth isn’t ever a concern.  What happens is your BI application(s) execute against that uber-store however you want (in this example leveraging both compute resources and storage resources), and return a set of results – which is a small chunk of data.

Tomorrow, the data set is different, as it now includes today’s data, and the query we run against it might also be totally different (who can predict what we’ll want to ask?) – but the use case remains valid.  People have no trouble stuffing giant fat data warehouses externally and letting someone else keep it up and running.  BI is a perfect storm for cloud usage.

What Doesn’t Work:  Backup – or to be more specific, recovery.  This has been an enigma, as clearly the one app that keeps showing up as a cloud example is backup.  The problem is that you can’t recover, thus the model breaks.  You can ship off your data incrementally, but you really can’t recover it due to the problems of latency and bandwidth.  Thus, server recovery needs to include Fed-Ex.  If it needs to include Fed-Ex, why bother?  That isn’t backup/recovery – that is DR.  I hope SalesForce doesn’t use a cloud model to back up your stuff.  You might check on that.

Disaster recovery is an excellent cloud application – for the aforementioned reasons.  Just like the BI example, getting your data asynchronously offsite to an uber-store in the cloud is doable.  Add the ability to create virtual computing instances at the place where the data rests and voila, you have the ability to get back to whole without Fed-Ex.  You have eliminated the bandwidth element from contention.

I understand why many individuals use the cloud for backup – at least the working set is smaller than what sits on a server – but even there it is an issue unless you are retrieving a single small file.  A real recovery operation on a substantial disk crash remains impossible even for an individual (over the wire).  In that case, backup providers have (smartly) begun to offer enhanced services – i.e., “we’ll burn a disk for you and Fed-Ex it.”  Better than nothing, but is it really good enough for a commercial world?

Perhaps a smarter way will eventually be when we virtualize users themselves – where their personal information and data never really resides on their local machine, such that they never have to perform a “recovery” in the classic sense – instead they just log in to their personality and everything they know and love is there.  This is the kind of thing that Viewfinity and UniDesk are trying to do, and it makes piles of sense to me.

Others still will try to tackle the problem differently – by killing  latency or bandwidth constraints.  How I can’t say, but there are several efforts underway.  That would also be really interesting – imagine what you might be able to do if you had no latency encumbrances or if bandwidth were effectively unlimited?  If CDP were utilized, you wouldn’t ever have to “recover” as is traditional.  You could simply keep a copy of  your life in the cloud and point to it when you needed it.  Instant gratification.  My kind of stuff.

If someone can figure that out, you could do two seemingly conflicted things: you could move everything to the cloud (public or private) and you could simultaneously centralize everything (or at least your data).  If there were no latency, you could have every single bit of your corporate data in once central uber-store (and perhaps another copy 8,000 miles away for DR).  What might that enable?  Wow.

So, I dig the cloud and what it can be.  I’m not jumping up and down about trying to force it to be everything for everyone, the way that industry tends to do with the new shiny object du jour.  If there is an application/use case where pushing the operating burden to a provider makes sense, I’m a huge fan – as long as the application meets the criteria and is cloud capable.  SLAs from providers around uptime are nice, but what if they (the provider) aren’t the problem?  What if the telco is the issue or the network becomes a problem?  What if the Pepsi syndrome happens on your premise?  That SLA is worthless when a backhoe cuts through your T3.  We need to make sure we’re using the cloud for the right things, and not for what it (as of yet) isn’t designed for.  There are plenty of smart use cases – so much so that it’s ok to stop talking about the dumb ones.

Related posts:

1. Cloud Economics Continued
2. Why the Cloud will Vaporize
3. Scarcity Imbalances – why the SMB (and the Cloud) will change the game
4. Head in the Cloud? Or Just up your……..?
5. Reverse Cloud Economics

Tags: Backup, BI, CDP, Cloud, Disaster Recovery, DR, on-line banking, SalesForce, Viewfinity