I’m not a gambler, but there is one “big bet” I would make: that clouds are never going to “interoperate in a seamless fashion.”
We’re starting to see the IT industry accept that business, which is completely dependent on IT, needs agility and flexibility to gain competitive advantage. If IT wants to be a value driver instead of a cost center, IT needs to move faster.
“The cloud” gives IT the power to move faster – and the opportunity to be the preferred service provider to a business – if they include a datacenter, private cloud, and public cloud deployment portfolio. A complete offering helps to meet the fickle needs of any business.
But wouldn’t it be nice if the various clouds (including datacenter, private and public cloud environments) making up your portfolio worked together seamlessly?
It Ain’t Gonna Happen.
Some suggest cloud service providers should “Design for multi-cloud compatibility from the start, rather than building this feature in as portfolios grow.” Or, alternatively, they should work together to develop interoperability standards.
As I’ve written before, it’s not going to happen. It’s not the interest of any one cloud solution provider to make it easy for customers to switch to competitors.
But why have multiple clouds if they’re all similar? After all, the reason for having a portfolio of services is to have different solutions that best address different business needs.
It’s better for the industry in the long run if individual cloud providers apply scarce development resources to innovation. This drives a range of services designed to solve different customer problems, rather than committing scarce resources towards a standard cloud model.
Reframe the Problem
How can IT leverage the value of having multiple clouds in their service portfolio without having the cost of multiple cloud teams and management stacks? Instead of framing the problem in infrastructure terms as, “How can we get all clouds to be the same?,” let’s shift thinking to the application level and ask, “How can we get applications to not care if each cloud environment is different?”.
While applications don’t have feelings, they do have requirements. So how can IT departments leverage the agility and flexibility value of cloud computing, while meeting the unique requirements of each application, and without locking the application to the cloud?
The solution is to abstract the application – the main character in the cloud story – from the cloud. The application should dictate the infrastructure, security, and cloud service requirements it needs for successful deployment. It should do so:
- By allowing the application to deploy natively to any cloud environment;
- Without modifying the application;
- Without writing cloud-specific installation scripts, configuration or orchestration;
- And while retaining portability and redeployability to another cloud if business requirements change. (Business requirements will That is another sure bet in our industry.)
David Linthicum is onto it: your hybrid-cloud management and orchestration solution should be cloud independent. But that thinking is rooted in managing multiple cloud infrastructures with a single tool, not in terms of “application first.”
The CliQr “Application Defined” Alternative
CliQr CloudCenter goes a step further: with CloudCenter your application defines its infrastructure, security, and cloud service requirements in a way that’s not specific to any one cloud. CloudCenter captures those requirements in a cloud agnostic Application Profile, which can then be deployed to any target datacenter, private cloud, or public cloud environment. CloudCenter Orchestrator then processes the application’s requirements and securely provisions infrastructure resources, and deploys the application stack and data natively. This is all done according to the specific APIs and services offered by the target environment.
To put it succinctly:
- The CloudCenter Application Profile defines the needs of the application.
- The CloudCenter Orchestrator stands up infrastructure and deploys the application stack in a way that is a best fit for the target environment.
- The business gets flexibility and agility since the application isn’t locked into any one environment. There is no “exit cost” if business needs change.
- Developers can focus on the application and not spend time understanding the details and nuances of different cloud environments.
- IT can offer a portfolio of cloud services that can flex and change to meet evolving needs of the business without deploying multiple cloud specific management stacks.
A multi-cloud future seems inevitable. IT needs to leverage the agility and flexibility of having multiple clouds in a service portfolio.
Don’t get stuck thinking that the only way to get the benefit without the cost is by getting multiple clouds to work together by design or by committee.
If you see a multi-cloud service portfolio in your future, even if you start with just one application in one public cloud today, you need to take a look at CliQr CloudCenter.