The Real Costs of Cloud Application Portability

By Rodrigo Flores

As cloud technology evolves, discussions have been building around workload movement and the best way to move apps seamlessly across clouds. While workload mobility could create a better economic model for cloud services by treating the underlying infrastructure as an undifferentiated commodity, this flexibility often comes at a cost (or, more accurately, a set of costs). To put it bluntly, portability may not be the cost-saving measure that some people assume it to be. 

True application portability requires designing for the lowest common denominator (LCD) between clouds. These LCDs can be pretty low, depending on how many different clouds you want to target for portability. For example, does portability between Cloud A and Cloud B mean doing without solid state drives and load balancers? Is that an acceptable trade off?

Portability also means foregoing a number of rich and unique services for which there are no equivalents or standards between cloud providers. These decisions raise a number of critical questions that can have long-term consequences. Can I use the cloud provider’s data warehouse, or do I purchase and install my own? Do I use the cloud provider’s domain name system or install my own? Do I keep my app portable but incur higher costs and delays? Or do I use native cloud services that are cheap and fast, sacrificing portability (at least for now)?

Another very important question to ask when considering designing an application for portability is how difficult and costly it would be to move to another cloud provider. Portability entails many upfront development and licensing costs and, down the road, ongoing operations costs.

But the real costs of portability are opportunity costs. The money and time spent designing and building the service layers means that new markets and customers have to wait. The point is that careful analysis may conclude that it may pay to wait—or forget “portability” altogether—if it means addressing market opportunities today rather than six months from now.

As if the questions around moving among vendors aren’t enough to keep many developers and architects up at night, the idea of vendor lock-in is even more odious. There are indeed risks associated with having a single vendor, including potential outages, ill-designed disaster recovery scenarios and shuttered product lines among them. Not to mention lack of leverage with your vendor come negotiation time—a scenario sure to strike terror into the hearts of your vendor management group.

Again, these questions come down to the larger issue around the opportunity costs. What are the trade-offs between ultimate flexibility and opportunity costs when designing for a multi-cloud world?

One way to begin the discussion is to ask your architects for a view that uses all applicable Web services of a single cloud versus one that preserves workload mobility. You will have to define how quickly that mobility needs to be accomplished. Moving something in minutes entails a different approach than moving something in weeks or months.

As we think about these scenarios, architects will have to focus on some of the biggest decisions they’ll face this decade: when to choose lock-in over portability, and how much lock-in or portability to choose. Not easy questions but critical ones.

Rodrigo Flores is managing director of Product Innovation, Architecture and Management at Accenture.