Earlier today, I read a blog post (that I recommend) on TechCentral.ie about customer lock-in and cloud computing. The author asked if a consumer of a cloud computing service should be concerned with what marketing people call “stickiness” and what we might call an exit strategy. In other words, if I consume some cloud application or build an application on some platform/infrastructure, how easily can I get it from that service and move to another service?
No matter what cloud solution (or even basic web hosting to be honest) you choose for your online presence, there will always be some customisation required. However, some require more than others. An infrastructure-as-a-service (IaaS) solution using virtual machines with traditional operating systems will give the developers a pretty common experience across different vendors. There might be different machine names, different patch levels, and so on, but in the end they’ll develop for IIS, .NET, SQL, Apache, or MySQL the same with company X as they do with company Y. That’s because there is a common denominator across the IaaS providers which those providers cannot customise.
Some platform-as-a-service (PaaS) solutions offer what developers might consider some very useful features. However, the vendor behind them will have customised the platform quite a bit to provide those features. An application developed on this PaaS won’t be directly portable to another service without extensive re-engineering.
The same applies whether you are developing some great big online application, or storing business data in some online SRM software-as-a-service (SaaS). Tsun Tzu wrote the following:
“To always have an exit strategy from vulnerable positions in which the army will find itself”.
He didn’t know it at the time but he put it perfectly. If I’m deploying into a public cloud service then I want to know how I can get my application/data out of that service and into a competitor (or back internal) down the road. Things might be just peachy right now; the SLA looks good, the price is right, regulations aren’t a problem, and going cloud aligns with company strategy. But what if the battlefield shifts? What if that public cloud service provider increases prices? What if they don’t live up to their SLA and lose business for you? What if state/industry regulations change and you need to relocate your data? What if you need to change how business applications/data interact with each other? How hard, and how expensive, will it be to move from A to B?
Will you have to hire consultants? Will there be a third party solution? Will there be a lot of manual work? Just how long will it take to migrate? How exactly will you exit from the public cloud service provider without wasting huge amounts of time and money?
The business people who are promoting cloud computing love this aspect of the service. It’s referred to as “stickiness”. For example, if you put all your customer data and workflows into some online CRM, using their features, and suddenly they jack up the price, what are you going to do? If it was a phone service, you’d browse the alternatives, and move once your contract was up. Your phone number can usually transfer with you. Downtime? Usually nil. Cost? Usually nil. What about moving that CRM? The truth is you will have to get consultants in to assess the situation, and then balance the cost of paying for their time to migrate you from A to B. One could say the same is true of internally or on-site deployed applications. True; but we tend to consider that factor and there are typically existing routes to manipulate the easily accessible data that resides in the data centre or computer room that you own. It’s a whole other ball game when the data sits in some multi-tenant database that you have no direct access to and your going to be working with nasty dump files – kept deliberately that way to deter you from moving. In the end, you’ll compare the cost of leaving that CRM SaaS with the cost savings of another provider and stay where you are. Stickiness; there you have it!
Like the earlier referenced blog author said, I recommend that you do investigate an exit strategy for any public cloud deployment that you consider. Remember that any USP (unique selling point) that a public cloud has equates to complexity in your exit strategy.
Very interesting article here, Aidan. And this is the typical question that involves more than just the developer. So it`s important for the IT-pro as well. – To have a solid knowledge of the Public Cloud vendor, either its Amazon, Microsoft, Google. The point is, even though there is a PaaS that the developers are responsible for, we should also need to know how to move from a to b. And it`s more than just writing the code.
Cheers,