Every now and then, when a publicly traded company’s quarterly earnings whiff, you hear the “secular shift” song. It’s a lament about how the “Hotel California Syndrome” doesn’t work anymore. In other words, “vendor lock-in” is loosing its grip on the customers.
OK, translation for the uninitiated:
- “Vendor lock-in”: aka “proprietary lock-in”, “customer lock-in” and “technology lock-in”, makes a customer dependent on a vendor for products and services, unable to use another vendor without substantial switching costs (source: Wikipedia).
- “Hotel California Syndrome”: The concern of vendor lock-in (“You can check-out any time you like, But you can never leave”).
- “Secular shift”: Customers are becoming less committed to a specific vendor, or platform; are less religious in their consumption of HW, SW and services; are becoming freer and more opportunistic in their IT choices.
The public discussion about cloud lock-in has gone quiet recently. Perhaps it is because the options are becoming fewer with the recent give-ins of so many vendors (HP, Rackspace and VMware vCloud to mention but 3). Perhaps it is because many customers have just given up on their freedom.
Thing is, there are actually two cloud lock-ins. And of the second lock-in, which is much costlier and more painful, no one speaks of.
There’s the visible part of the cloud lock-in: The cloud service itself. The switching costs and pains are well known. This is not the cloud lock-in we’re talking about.
Then there’s the invisible part: The security apps, network tools, integration and configuration one has to do in order to make one’s cloud-staged apps functional. It’s a hefty corollary price (or a collateral damage…) the customer has to pay in order to make the cloud actually work. Very little of it (if any) is provided by the cloud providers as part of their platform or as (paid…) add-ons.
Let’s take a look at this pain. What does the “corollary cloud lock-in” consist of?
- WAN optimization
- Application delivery controllers
- And much more…
Sounds painfully familiar? It’s the DMZ, with all of its gravy and trimmings, and then some. This list of pains represent significant cost and time investment. It’s a sunken cost, as it’s the cost of making the cloud actually work.
To make matters worse, this investment is tied to the specific cloud provider one chooses. It’s not transferable, scalable or extensible to other clouds the customer uses. This expensive effort is so painful the mere thought of going through it again as part of migrating to a different cloud provider is enough to scare the customer away from it.
So in effect there is a double cloud lock-in.
In many ways “cloud religion” is a forced one. One is perhaps lured into a certain cool and hot cloud platform, but then is mired by what it really takes to actually consume the cloud.
So how do you unlock your cloud?
- Build the entire perimeter-related controls (security, access, network, delivery) as a native cloud service
- Result: Much less cost, much more freedom.
- Design it in a way that allows it to be extended to any enterprise network (private cloud, public cloud, even old datacenter)
- Result: Omnipresence. The solution applies anywhere.
- Make it such that it deploys fast and painless by anyone and not just IT professionals.
- Result: Migration to the cloud is made affordable and easy. A huge hurdle is removed.
If you do that, you remove the invisible and costly lock-in, and make your cloud freedom much closer to reality. As a matter of fact, we did just this. We unlock your cloud. You’re no longer “stuck in the mud”. Take a look at Soha.