Vendor lock-in and incompatible tools are the two main problems you'll encounter when deploying SaaS apps across multiple platforms. Learn how the OASIS CAMP spec solves these issues.
Deploying applications with vendor-specific tools across multiple Platform as a Service (PaaS) platforms can be overwhelming. You cannot use the tools that a provider gives you to redeploy the applications to other providers' platforms because the tools are not compatible. You are locked in with a PaaS provider — it doesn't matter whether the cloud is public, private, or a hybrid.
Possible deployment tool problems
Incompatible tools. Let's suppose a provider includes components and several APIs you may need to interface with a platform, but the tools don't include everything you want. You look up a second provider that offers you a library of components, APIs, and plugins that meet your expectations. You would like to transfer a few components from the second provider to the library maintained by the first provider, but you cannot — the deployment tools are not compatible and not interoperable.
Vendor lock-in. Let's suppose you are considering a provider that has the deployment tools you like. You should read the fine print on the vendor lock-in policy about:
- what tools you must use;
- how often the provider upgrades the tools;
- whether you need to make changes in your application in order to use upgraded tools in the newer version of the operating system;
- what the exit fee is for changing to a different provider; and
- when you are allowed to exit.
You can simplify the process of deploying Software as a Service (SaaS) applications from a company's internal data center to multiple platforms by using an interface that's common to both platforms. One such interface is specified by the Organization for the Advancement of Structured Information Standards (OASIS) Cloud Application Management for Platforms (CAMP) Technical Committee.
The OASIS CAMP solution
In August 2012, Oracle, Cloudsoft, Rackspace, Red Hat, CloudBees, Huawei, and Software AG published the (CAMP) specification and submitted it to the OASIS. After reviewing the specification, the open standards organization created the OASIS CAMP Technical Committee. Since then, it has been striving to standardize a single common interface that the CAMP client can use to move applications between multiple platforms, and it wouldn't make a difference what platform and programming languages you are using.
According to Oracle's Gilbert Pilz, the CAMP solution focuses on the interactions between a cloud consumer and cloud provider as defined in the NIST Cloud Computing Reference Architecture. The scope of the CAMP Technical Committee's work covers five areas and informs what you can do when using the specification.
Components and assemblies
- Compose application assemblies from custom components and application-level services provided by the platform.
- Import components from libraries or repositories.
- Configure components and assemblies.
- Register, deregister, start, stop, hibernate, or snapshot assemblies.
- Update applications and components with patches or a version control system.
- Monitor how well components and assemblies have been performing.
- Keep track of data usage to ensure it is within the range you expect to pay.
- Develop applications either in a standalone Application Development Environment (ADE) or as part of the platform offering.
- Determine if components and assemblies can be further customized.
- Perform test assertions, scenarios, and suites.
- Package applications and components in a format that allows portability across platforms.
- Include in the package specific framework and/or language extensions that you need to transport and deploy the application code.
The best part about the CAMP solution is that as the cloud consumer you can manage the entire life cycle of the application from start to end, including application deployment. You could do the first part of the application life cycle on one platform and then complete the life cycle on another interoperable platform. You would need to work with policy administrators on governing policy on how applications should be secured and deployed on each platform you would use.
The CAMP Technical Committee does not define:
- SaaS applications;
- non-management interfaces to platform services (this includes interfaces that would allow an application to post a message to a message service);
- a functional interface to a messaging service (this includes a Ruby API for interacting with a messaging service using Advanced Message Queuing Protocol); and
- interfaces that are specific to a programming language or a platform.
If you want to save time deploying applications across multiple platforms, you should go for the OASIS CAMP's common interface. It doesn't matter whether the PaaS is a private, public, or hybrid cloud.