March 1, 2013 | Written by: Stephane Wacongne
Share this post:
Cloud standards would allow IT to reach a whole new level of portability and interoperability. The promise is that you would be able to deploy complex applications within minutes either on-premises or off-premises much like you install apps on your smartphone or tablet today. You would even be able to seamlessly move workloads between public and private clouds.
Cloud standards may be years away from now
Cloud computing is a growing field and has not reached its full maturity yet.
Of course standards such as Open Virtualization Format (OVF) exist and many standards organizations are emerging such as The Open Grid Forum (OGF), the National Institute of Standards and Technology, the Cloud Security Alliance, the Institute of Electrical and Electronics Engineers (IEEE) Standards Association or the Distributed Management Task Force. But these organizations have yet to define a set of detailed standards for all major Cloud Service Providers to abide by to ensure portability and interoperability.
Bottom line is that the standards path may be years away from now and we still need something practical to deal with portability and interoperability.
Use well spread APIs
When building a cloud the first things you need to work on are use cases. It describes the interactions between all the components of the cloud including users, software and systems.
Technically those interactions are handled by a piece of code binding two components together. For instance if we have a provisioning system and an accounting system next to one another these are two independent components doing their job well but not interacting. Now if the provisioning system provides a rich Application Programming Interface (API), the accounting system can bind to the provisioning system and provide new features.
The thing is that not everyone provides an API with its products and when someone does the API and its associated Software Development Kit (SDK) may not be rich enough to support your use cases. This is why you need to choose your Cloud Service Provider and on-premises cloud software with great care to avoid vendor lock-in and hidden costs.
For instance, choosing an on-premises cloud that supports a well-spread API such as Amazon Web Services (AWS) API or at least an AWS-like API is a must if you are planning on bringing hybridization to your clouds.
Also check that the APIs you selected support asynchronous, loosely coupled, message based software solutions. It may prevent you from building a monolithic software solution that binds your clouds together but does not scale.
Use well spread and open data formats
When interacting with a system you exchange data. Of course, many of the interactions are done through APIs in standard XML or JSON. But when you need to load a database or a whole virtual server there may be difficulties if the source and destination formats are not compatible.
The debate here is not new and not specific to the cloud market: if your Cloud Service Providers or on-premises cloud cannot export or import your data you may become locked-in. The cost to transform the data between source and destination can be so high that it actually prevents you from implementing a true hybridization strategy.
Use hybrid cloud integration platforms
Now if you are spreading your services across many Cloud Service Providers and on-premises clouds you know you will have to maintain quite a lot of interaction-specific code. This can become costly and reduce your capacity to keep scaling up.
In this situation you can use additional software to simplify the binding between systems and handle non-functional requirements such as security.
Typically you could use Cast Iron for that. You’ll find several articles about this IBM product in this blog.