In my previous blog, I talked about my role at ESG covering systems management, DevOps, and PaaS, as well as how the use of the term hybrid cloud is almost a requirement for any product in the space. I think that many of you will agree with me that the entire idea of hybrid cloud is a little under-defined.
Currently, most vendors define hybrid cloud on an architectural basis, as essentially any configuration with disparate cloud systems that are brought together. The definition is based mostly on the ideas that IT needs to have an on-premises environment linked to an off-premises, usually public or hosted, cloud. But for the practical implementations of hybrid cloud, we should more clearly define what a hybrid cloud can be.
Rather than using a broad architectural definition of hybrid cloud, we can look at the different vendor solutions in the market today and define some specific configurations that define hybrid. Three specific ways we can define hybrid cloud are as follows:
- Common Platform – Where the base infrastructure/virtualization platform are the same, allowing the common use of existing management tools and processes. An example of this type of hybrid cloud is the recently announced VMware service on Amazon Web Services.
- Common Applications/APIs – Where the end applications or application APIs are the same, allowing common applications to be developed across different platforms. An example of this type of hybrid cloud is the upcoming Azure Stack solutions from Microsoft and its hardware partners.
- Common Management – Where the management tools have the capability to manage all the different environments, with a common interface and process. Examples of this type of hybrid cloud are software solutions such as CloudForms from Red Hat and Scalr.
As I continue this series of blogs, I’ll dive deeper into each of these types of hybrid cloud and the advantages and disadvantages of each type.
This is the second part of a series of blogs on hybrid cloud. Check out the other parts here: