Guide to app portability and interoperability
A comprehensive collection of articles, videos and more, hand-picked by our editors
Application interoperability is the issue that's keeping my company from adopting SaaS applications. It doesn't look like SaaS vendors can offer real-time interoperability between our apps in private clouds and SaaS apps. What approaches could we take internally to achieve private-public cloud app interoperability? Are there any standards?
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Interoperability in cloud computing has the same problems as interoperability between homegrown applications and commercial software, or between different commercial software. These problems in the cloud are widely recognized but standards bodies turned to them only recently. The world of cloud is a bit wilder than the world of applications because clouds currently offer an opportunity for cloud providers to lock in new, and not technically savvy, business customers.
In this post, we will review emerging standards and initiatives undertaken in the area of cloud interoperability. However, well-known analyst and blogger David Linthicum warns:
Don't expect anything to happen any time soon. The standards process typically takes years and years. Even the first step has yet to occur for these standards: the formation of their working groups. However, IEEE is good at defining the details behind standards, as evidenced by its widely used platform and communications standards. By contrast, most of the standards that emerge from organizations other than the IEEE are just glorified white papers -- not enough detail to be useful.
Nevertheless, there are two standards in a "usable" state: Open Virtualization Format (OVF) and Cloud Data Management Interface (CDMI). The former relates only to the packaging of virtual machines (VMs) for facilitating mobility. The latter determines which interface will be utilized to access and manage cloud storage. There is a trend among cloud vendors to push proprietary APIs as an open standard. VMware has done this with its vCloud API, as has Red Hat with Deltacloud.
If you have a set of applications in a private cloud (and, I assume, you have full control over them regardless their physical location -- inside or outside of the corporate boundaries) and you want to utilize a SaaS offering, you have to take care of integration between them rather than wait for interoperability standards to be ratified . Acting in this way, you will not miss out on any benefits of cloud while your custom integration might be reused later on to decouple your systems from external providers (which is always safer than exposing and locking yourself with them).
The main guideline in creating an integration hub for clouds is the same as you would have for internal integration of heterogeneous applications and platforms, some of which you cannot modify. In essence, the integration hub has to realize a mixture of two patterns (not necessary systems) -- ESB and ETL. However, the fact that your SaaS resource allows only a Web-based communication channel, sets some preferences in designing interactions between your applications in private cloud and SaaS (which also may be deployed in a private cloud but you would not have a control over it).
Avoid synchronous communications between clouds
Try to avoid synchronous communication between clouds as much as possible. Engage an acquire-store-resend model. You will pay some performance penalties but avoid binding the life cycles of your applications with the life cycles of SaaS. The goal of this preference is to achieve a loose coupling between clouds while maintaining some resiliency to changes in connectivity and location.
Monitor the connections
Monitor connections in the integration hub at all available levels. Reserve a mechanism for an automated acquiring of lost connections. Compare monitored metrics against your contract (SLA) with the SaaS provider, and act actively on any discrepancies.
Pay attention to the interactions
Like in any service-oriented ecosystem, put the maximum attention on semantics and ontologies of operations and data involved in the interactions between clouds. You will see that the informational aspects, not only formats, are crucial for all emerging cloud standards. Information "translation" in the cloud integration hub is a must-have feature.
Minimize the interactions
Keep the number of interactions between clouds to the bare minimum but use coarse-grained interfaces. Watch for an availability of such interfaces in the selected SaaS and create a service layer on the top of your own applications if they do not support such granularity.
REST is best
In line with the last note, try to model the application landscape in both clouds as a landscape of resources. This will allow you to minimize data volumes moved between clouds and construct a RESTful interaction solution. However, do not discard simple XML over HTTP and similar cheap mechanisms. More sophisticated integration is available through innovative services like cloud integration from Boomi or Cast Iron, which allow the Internet to be seen as an enterprise service bus (ESB) of sorts.
Do it yourself with security
Do not trust any declarations of SaaS providers regarding security. Protect your channel to SaaS from the integration hub (this is one of the major roles of having such hub) with all security means your corporate policies specify. If your applications are deployed in another cloud, the communication channel with this one has to be equally protected.
Related Q&A from Michael Poulin
Avoiding cloud lock-ins with both the technology and provider is a concern for businesses interested in cloud computing.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.