Application portability is always an issue in the cloud because competitive market changes can either create a new "best choice" or put a provider out of business. Most users accept that Infrastructure as a Service applications are fairly portable, and most realize that Platform as a Service application portability will depend on application features used. Software as a Service services are not typically considered in the portability discussion, because SaaS applications are owned by the provider and are not portable. In a strict sense, that is true, but portability planning can help users deal with pricing and business stability issues for SaaS providers, and can even help users migrate from a SaaS service back to a self-hosted version of the same application.
Third-party application and SaaS benefits
A Software as a Service (SaaS) app that is based on a provider's own custom software cannot be ported unless the provider creates the option, which will virtually never be the case. Thus, where portability is a concern, a SaaS prospect should first focus on providers who host third-party software rather than those who develop their own. The software developers likely make hosting arrangements with multiple providers, so portability of this form of SaaS is relatively easy. It's also possible to buy a copy of the software for local installation, so "self-hosting" is an option in cases of provider failure or the loss of software support.
The best sources for "portable SaaS" are the major providers (Microsoft, SAP, Oracle, etc.) of applications. Nearly all will offer SaaS, sign agreements with third parties for SaaS hosting or both. The key point is that wherever a SaaS service is built by hosting conventional application software, it's a good bet there will be multiple providers available offering the most popular options. Specialty vendors who offer vertical-market packages are less likely to attract multiple SaaS hosting providers, so a different approach will be needed for those.
Pros, cons of IaaS instead of SaaS
The second option for SaaS portability is "self SaaS," the licensing of a software package and hosting of the package on a cloud Infrastructure as a Service (IaaS) offering to create what appears to be SaaS. The value of this approach is that the resulting service is as portable as a machine image, which can increase competitive choices for hosting. The negative side is that unlike SaaS, self SaaS still exposes the user to the cost of the software and the support of the entire software stack from operating system to application. This means self SaaS is an option for creating a cloud version of a given application, but not for reaping the full benefits of SaaS.
DIY SaaS portability
Even these two options won't fully address SaaS portability issues. A growing number of users are integrating SaaS apps with other on-premises or cloud software to create orchestrated multi-component applications. One company combined Salesforce CRM services with SaaS-hosted unified communications and collaboration to create a sales support application, for example. Here we have two SaaS components, and if either has to be changed, the whole sales support application is compromised.
Portability planning … can even help users migrate from a SaaS service back to a self-hosted version of the same application.
One solution to this problem is proper selection of the application integration tool(s) used to build the higher-level application from its SaaS components. Many application front-end tools (Citrix, for example) allow users to customize the interfaces to the lower-level applications that provide data and processing. Changing a SaaS provider for one component means changing the integration definitions, but not the entire application. For this approach it's important to look for SaaS services that offer flexible application programming interfaces (APIs) that can be integrated easily. RESTful APIs are typically more easily integrated than service-oriented architecture/Simple Object Access Protocol APIs, for example.
When all else fails, SaaS integration and portability problems can be solved by customizing an application based on the SaaS APIs. A SaaS API appears to a developer like a distributed application component, and so it can be built into a program as such. To prevent this process from simply creating another portability risk, the best practice is to encapsulate access to all SaaS service APIs in a local class/object, and refer to that new object to access the service. That way, if it's necessary to change SaaS providers at some point, the local object can be modified to suit the API of the new provider.
SaaS vendors fostering portability?
All integration and encapsulation strategies for SaaS portability depend on there being functional correspondence among the competing SaaS providers of a given application. Obviously, if one provider of a unified communications/collaboration service offers video sessions and the other does not, no amount of interface integration will make up for the lack of functionality. Not all functional differences are that obvious, though, so before undertaking a SaaS integration or encapsulation project, inventory the available service providers and ensure that you build applications based on features that have general support.
Because SaaS services displace the largest amount of platform and infrastructure components, they offer the largest benefit case and are the most easily adopted by non-technical users.
Accommodating portability issues with SaaS is possible, but users must be aware that these accommodations will nearly always add to the cost of the project, reduce the field of SaaS providers available for consideration, and risk undermining some of the sources of SaaS savings. These disadvantages have to be weighed against the benefits of portability before any steps are taken, or the cure may be worse than the disease.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.
Follow us on Twitter at @CloudAppsTT.