Cloud vs. clouds: A CIO’s conundrum

Beware of cloud "stickiness." Plan for redundancy. Clouds do fail!

Originally published on SETHspeak , CIO.com July 13, 2017

There was a tear in the fabric of the cloud universe on February 28, 2017 when Amazon Web Services had a significant outage.

It highlighted what some described as a “critical lack of redundancy across the internet.” The outage was a wake-up call for many to build in redundancy (both multi-region as well as multi-provider) in their cloud strategy.

Can I jump from cloud to cloud?

So from cloud the conversation has moved to clouds.

However, good tools with capabilities that allow seamless dynamic interoperability between public cloud providers especially in the PaaS and SaaS space are hard to find.

Public cloud providers' idea of redundancy is to provide geo-redundant storage, replicating data to a secondary region that is hundreds of miles away from the primary region. They talk about seamlessly migrating from one to another in quick easy steps but are silent about dynamic real-time interoperability.

Dynamic real-time interoperability (DRTI – Voila! A new acronym is born)

What I mean is that, ideally, these tools should allow dynamic switching between public cloud providers based on rates, availability, etc.

Customers are getting wary about putting all their eggs in one basket. They would also like to leverage differential rate structures across public cloud providers to their advantage.

What one really wants: A cloud load balancer/scheduler that switches the processing to whichever cloud offers the best mix (rate, availability, processing speed, etc., at that point of time). Cannot say there is one quite there yet.

Interestingly a patent assigned to Red Hat Inc., "Methods and systems for load balancing in cloud-based networks," has been out there for quite some time. But does not seem like it has been effectively commercialized yet. 

Why is my cloud so “sticky”?

This brings me to the other pet peeve about the existing public cloud providers: “stickiness.”

The economic model presented by leading public cloud providers highlights a “consumption-based infrastructure,” which moves the cost model from CapEx-centric to OpEx-centric, and aligns costs directly to usage (see "Pay-as-you-go IT: CFO’s dream, CIO’s nightmare/opportunity?").

However, just like the classic software/hardware vendors, public cloud providers have tried to create a “stickiness” using technology or commercial barriers to make seamless interoperability across multiple providers somewhat of a challenge. (Oh, AWS Cloud is the AWS Cloud and Azure Cloud is the Azure Cloud, and never the twain shall meet – with apologies to Rudyard Kipling.)

In SaaS, vendors are perhaps getting too “sticky,” like to own the application, platform, infrastructure, cloud – the whole shebang! 

That works fine with me when I am the vendor for others, but being at the receiving end of the stickiness is scary.

Perhaps, it could be reduced a bit for some applications where other vendors are pulled for the underlying platform or infrastructure (Oracle SaaS or Salesforce on an AWS cloud). But all applications vendor claim their applications work best on their own cloud!

I do not blame them for that. Any vendor in any line of business would like to make sure the customer stays with them and goes no place else.

The future is cloudy!

If I had access to the ear of Jeff Bezos or Satya Nadella or Sundar Pichai or Larry Ellison, this is what I would whisper: Build the cloud “switch.”

That means a tool/appliance/service that allows storage capacity or processing loads to move from cloud to cloud or cloud provider to cloud provider based on cost and demand.

Create a true “cloud grid” like the electricity grid (where distribution companies can draw power from whichever generating company based on rates and availability).

What next: a “computing exchange” where processing and storage capabilities are traded and futures are locked in like any other commodity (electricity, jet fuel, etc.). Now, I may be getting ahead of myself.

Don’t forget the R word

Well, in the short term:

• Think redundancy
• Plan redundancy
• Execute redundancy

You are only as good as your plan B.

Originally published on SETHspeak , CIO.com