As the debate between private and public clouds moves on to hybrid cloud adoption, a presumably more flexible form of cloud computing model, there is no denying that the fear of vendor lock-in persists, as most cloud services are still proprietary in nature.
In contrast, an open cloud provides the interoperability that will free companies from being locked in to a single cloud vendor. This in turn allows companies to select the vendor whose service level agreement matches most with their requirements.
Open cloud & open source
In contrast with proprietary clouds, an open cloud adheres to open standards. This allows for interoperability and portability of applications, computing, infrastructure services, development models, and data between various clouds.
As a result, open clouds reduce the issue businesses face of being 'locked-in' to a single cloud computing vendor, as they will be able to take their data and applications to another vendor's cloud -- without having to bear massive porting costs.
Open source software has played a major role in enabling cloud computing. This is because the vast majority of clouds are built using open source technologies for which source code is made available publicly and is free for other parties or developers to adopt.
Open cloud can be thought of as the 'friendly cousin' of open source, and thought of as a definition of explicit rights or freedoms, much like that in the open source definition.
2 forms of vendor lock-in
One major factor that hinders businesses from adopting cloud is the fear of vendor lock-in. This occurs when there is lack of interoperability between clouds -- often caused by a lack of common interfaces, standard data formats or services that could guarantee application, data and service portability. As a result, companies are unable to operate using a variety of cloud service providers, which forces them to be 'locked-in' to a single vendor's cloud stack.
Companies must look out for two forms of lock-in: 1) Data lock-in, and 2) API (application program interface) lock-in:
Data lock-in occurs when the cloud vendor does not return the raw data to the customer for further analysis, aggregation or even storage. This ties the customer to a vendor until a method of breaking the lock-in can be figured out.
API lock-in occurs when the cloud vendor's API ends up forming an important part of the customer's application architecture. As a result, changing cloud providers becomes an expensive and time-consuming process and the entire application code has to be re-written to accommodate the API of the new cloud vendor.
3 myths of "open cloud"
An open cloud does not come into being by submitting it to a standards organization, or have a cloud placed next to an "openness" checkbox. Below are three common myths of "open cloud":
1. One single thing builds open cloud. The first myth is that there's one single thing that makes a cloud open, for example, an open API. In reality, openness has to be present across multiple dimensions in order to ensure broad portability across clouds. This requires a commitment to open standards and interoperability throughout the software stack and the partner ecosystem.
2. "Open" by submitting it to standards. Another myth is that saying something is "open" or submitting it to a standards organization makes it open. When a single vendor controls an API or an implementation, there's no level playing field and the technology roadmap is ultimately controlled by that single vendor.
3. Openness being an option. Finally, openness isn't just a technology checklist. It's an approach to interacting with customers and partners that has to be an ongoing process.
The IT and technology sectors are more likely to adopt open clouds than the other, as they would be more familiar and receptive to the concepts espoused by an open cloud.