Application portability in PaaS: Problems and solutions

Very few businesses would tolerate application development practices that tied them to a single vendor, but many are unwittingly developing applications that tie them to a cloud provider. 

With the cloud becoming more competitive and with some providers at long-term stability risks, developers have to understand the following: that Platform as a Service (PaaS) can be a trap because of uneven support for platform features, that some PaaS providers pose greater risks than others, and that all PaaS choices can be made more portability-friendly with the right project steps.

Even at this early stage in cloud adoption, users of PaaS services are raising the question of the portability of their applications -- not to a given PaaS provider, but from that first provider to a different one, or even back to the data center. In some cases, this switch has required major changes in software and caused project delays and even productivity losses. This is caused by two specific problems, and developers have to address them both to create portable applications for PaaS.

The first problem with PaaS portability is the lack of a consistent platform definition among PaaS providers. With Infrastructure as a Service (IaaS), developers are working with bare metal and can provide all of the system software needed for their applications. This kind of platform is portable because it moves with the application from one IaaS provider to another and can even be ported back to a virtual machine on-premises. With PaaS, the provider selects the operating system and middleware elements it will support, and if providers make different selections, then applications that use features in those areas of difference can't be ported. If some of the PaaS features are provider-customized, it might even be difficult to move the application back to the same platform on-premises.

Developers have to understand that Platform as a Service can be a trap.

The best solution to resolving this portability problem is to establish a platform reference point. PaaS services are almost always offered around an operating system (e.g., Linux, Windows), a collection of middleware for communications and database services, and management and deployment tools. While multiple cloud providers might offer the same basic platform, they could vary the middleware and tools, and so it is important to chart the features of your preferred platform type (again, Windows or Linux are examples) and highlight features/tools that are not uniformly supported. By avoiding those features and tools, you can avoid portability issues.

The second problem is a lack of credible alternative providers for a platform. PaaS services today are most often offered in two forms. First, the "owner" of the platform (Microsoft for Windows/Azure, for instance) may make a cloud version of a server platform available. In this case, the dominance of the first PaaS provider may discourage competition, even if the platform provider allows it (Microsoft recently changed Windows Server to facilitate non-Microsoft Windows PaaS offerings). Second, IaaS providers such as Amazon have been steadily adding services to their IaaS platform, which makes the IaaS offering really just a simple form of PaaS. Since there are no standards for these added services, using them will lock applications to a cloud provider.

When a dominant provider is stifling PaaS competition, the only alternative available to a cloud user is to use IaaS services and include the "platform" part of PaaS in their machine image. If this is to be done, it's critical to ensure that all of the PaaS features are available for local server installation. The risk of a major platform provider such as Microsoft, IBM, HP or Oracle simply getting out of the PaaS business is likely small, but where small providers are the only PaaS option, planning for an IaaS fallback position is the prudent course.

The solution to this second problem is the adapter design pattern. When an application for the cloud has to reference a service that may not be available across all providers, encapsulate the references to the service into a higher-level software element (following the principles of the adapter design pattern common to object-oriented design) and transform a general request into the specific form the PaaS service needs.

For example, suppose an application is developed for Amazon's Redshift warehouse service. While IaaS services compatible with Amazon's EC2 are widely available, Redshift is not offered by other IaaS providers and the applications written for the "mini-PaaS" that EC2/Redshift represents would not be portable without changing all the program references to Redshift. A developer could write a small software object called Warehouse that would be used instead of Redshift application programming interfaces (APIs). Inside Warehouse, the code could transform the parameters of the database operation to Redshift form, then invoke Redshift. If the application is then moved to a provider where Redshift is not supported, Warehouse can be changed to perform the correct database access APIs needed to emulate it. A single change to the Warehouse object now makes the application portable.

This abstraction-based mechanism is also suitable for managing portability issues where it's necessary to build a cloud application on a platform feature that competitive analysis has shown is not uniformly supported. The key is to ensure that there are at least reasonable ways of providing the same feature/function on multiple platforms, even if the same APIs won't work across them all. If, as in the Warehouse example, there were no comparable services available at all on one or more alternative platforms, then the adapter design pattern mechanism could not easily support portability among them.

The greatest portability risk for PaaS over time will not be with the formal PaaS platform, such as Azure, but with the evolution of IaaS services into PaaS services through the addition of features, such as Amazon's Redshift or caching services. Many users of these platforms will never see themselves as PaaS users at all and may be blindsided by incompatibility the first time they try to move an application to another provider. A little preplanning can prevent major problems, and the exercise will also help cloud pros understand that feature differentiation pressure will likely make PaaS portability an enduring concern.