There was a tear in the fabric of the cloud universe on February 28, 2017 when Amazon Web Services had a significant outage.\nIt highlighted what some described as a \u201ccritical lack of redundancy across the internet.\u201d\u00a0The outage was a wake-up call for many to build in redundancy (both multi-region as well as multi-provider) in their cloud strategy.\nCan I jump from cloud to cloud?\nSo from cloud the conversation has moved to clouds.\nHowever, good tools with capabilities that allow seamless dynamic interoperability between public cloud providers especially in the PaaS and SaaS space are hard to find.\nPublic 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.\nDynamic real-time interoperability (DRTI \u2013 Voila! A new acronym is born)\nWhat I mean is that, ideally, these tools should allow dynamic switching between public cloud providers based on rates, availability, etc.\nCustomers 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.\nWhat 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.\nInterestingly 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.\u00a0\nWhy is my cloud so \u201csticky\u201d?\nThis brings me to the other pet peeve about the existing public cloud providers: \u201cstickiness.\u201d\nThe economic model presented by leading public cloud providers highlights a \u201cconsumption-based infrastructure,\u201d which moves the cost model from CapEx-centric to OpEx-centric, and aligns costs directly to usage (see "Pay-as-you-go IT: CFO\u2019s dream, CIO\u2019s nightmare\/opportunity?").\nHowever, just like the classic software\/hardware vendors, public cloud providers have tried to create a \u201cstickiness\u201d 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 \u2013 with apologies to Rudyard Kipling.)\nIn SaaS, vendors are perhaps getting too \u201csticky,\u201d like to own the application, platform, infrastructure, cloud \u2013 the whole shebang! \u00a0\nThat works fine with me when I am the vendor for others, but being at the receiving end of the stickiness is scary.\nPerhaps, 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!\nI 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.\nThe future is cloudy!\nIf 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 \u201cswitch.\u201d\nThat 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.\nCreate a true \u201ccloud grid\u201d like the electricity grid (where distribution companies can draw power from whichever generating company based on rates and availability).\nWhat next: a \u201ccomputing exchange\u201d 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.\nDon\u2019t forget the R word\nWell, in the short term:\n\nThink redundancy\nPlan redundancy\nExecute redundancy\n\nYou are only as good as your plan B.