If you have been following IT infrastructure for a while, you will have seen the rise of the cloud hailed as the solution to all of our IT problems. You will also have heard that the public cloud is like Hotel California, where you can easily check in but can never leave. I wrote a little while ago about the risks of relying on a single cloud service and the need to use multiple clouds. In order to use multiple cloud providers, you must use them in such a way as to minimize the barrier to exit. And that means using cloud-portable applications.
Most people are familiar with the phrase “barriers to entry,” which refers to the difficulties encountered when starting to use a service. This is one factor slowing cloud service adoption. “Barrier to exit” refers to the difficulty of ceasing to use a service: the difficulty of moving applications from one cloud provider to another or to one’s own private cloud.
There are two main elements of this exit barrier: data migration and application logic migration. Moving large amounts of data is slow; simply copying a terabyte database from one cloud provider to another may take hours. These are hours when the database is not available or is functionally limited. More data means more hours. The smaller the amount of data needing to be migrated, the quicker the migration can occur. Oddly, this is the easier barrier to accommodate through good design. The application logic can be the stickiest part. Applications written to use services that are only available on one cloud provider need to be rewritten for a new platform. This can be a huge barrier to exit.
Cloud as Hotel California doesn’t come from using commodity cloud services. Any cloud provider can supply you with a VM with an operating system where you can deploy your application. This sort of IaaS cloud has the lowest barrier to exit. Whole VMs can usually be exported from one platform and imported into another. Of course, these VMs aren’t small, so there will be hours of outage for each VM and each migration. A strategy that minimizes the number of VMs that need to be migrated helps. Stateless VMs can be re-deployed rather than migrated, and they reduce the amount of data that must be copied during migration.
Cloud as Hotel California comes from the use of non-commodity services. For examples, take a look at the product list from AWS. Almost every service it offers is not available from any other cloud provider. Services from S3 to autoscaling and relational database services are all proprietary. These are the very services that make AWS a desirable platform for developers. Applications can consume AWS services, and developers can spend more time focusing on business requirements. Without these services, developers must build a heap of infrastructure before they focus on business requirements. The very thing that makes AWS a great application development platform puts up a huge barrier to exit. Applications developed for AWS services cannot be migrated to other cloud platforms. The services they rely upon simply do not exist. Applications developed for AWS services are also architected for those services. To migrate to a new cloud platform, the application needs rearchitecting and redevelopment. This isn’t unique to AWS. Both Google and Microsoft are adding more services to their platforms, enabling simpler application development and making their cloud platforms stickier. This stickiness is a huge barrier to exit and the crux of Hotel California in the cloud.
To simplify application portability across clouds, we must build our application infrastructure ourselves. Not using the unique services of a single cloud provider enables portability. We must also maximize the disposability and re-creatability of our workload. This requires that we minimize the amount of data to be copied between clouds when we migrate. One great tool for disposability is containerization. A container instance is supposed to be disposable and easily re-created. If all of our application logic is in containers, then it is easy to re-create the application on a new cloud. Containers like Docker and Cloud Foundry are great for application mobility. Containers also lend themselves to loosely coupled, microservices-based application architectures. This can enable migration of parts of an application independently. Being able to migrate piecemeal rather than in a big bang can be a big help.
Architecting an application for cloud deployment is complex. Architecting an application to allow it to migrate between clouds is even harder. Developing applications that can be migrated between different cloud providers involves ignoring all of the cool features of each cloud. We will build your own versions of the ones we need. I’m not sure we will see any applications developed for cloud portability until a major cloud provider lets a lot of customers down.