The vast majority of organisations are pursuing a “Cloud First” strategy. Gartner fans will know that 88% of the organisations it surveyed last year are either already using some form of cloud or will be by the end of 2017. Their reasons vary, but typically include amongst others cost reduction, agility, scale and capability.
In many cases a cloud first strategy means public cloud and a “let’s get as much of our stuff into public cloud as possible” approach.
The reality however, is that not everything can go into public cloud and neither should it. While there’s no doubt that the majority of stuff will end up there eventually, a key question is whether organisations opt for a single or multi- vendor cloud model.
Clouds are sticky
Initially it can seem easy to select a single cloud provider to embark on a cloud first journey – both from a technology perspective, and from a business and procurement angle.
Cloud vendors want you to use their clouds and theirs only for obvious reasons. They don’t want you being able to move apps or workloads easily between providers. Which is fair enough.
But when you do need to move, then it’s going to be one almighty headache. If your applications, processes or skills are all stuck in a single provider’s cloud, then you are indeed stuck and it will take some effort to extricate yourself.
Is cloud lock-in a bad thing?
But… Is having an app or service stuck in a single cloud provider a bad thing?
These days IT is in love with things being open and avoids lock-in at any cost. Yet it seems to be less of a concern when it comes to cloud vendors.
Some of the customers I work with have moved an entire service or the majority of their IT estate to a single Hyperscale cloud. They understand the risks but the benefits they get outweigh them. When qualified, this can be a great solution.
What to ask
When selecting the best target for an application, be it data centre, private or public cloud, one should always consider the needs of the application.
Here are nine questions to ask:
- How do I connect and network to the cloud provider?
- What are the security requirements?
- What regulatory, compliance or sovereignty requirements exist?
- Do I need cloud provider specific capabilities?
- How will the application evolve during its lifecycle?
- What processes and skills need to be put in place?
- How much will it cost?
- What is the cloud exit/migration strategy?
- Does it matter if the application gets locked-in?
It’s unlikely that your entire application estate will have the same requirements and be satisfied by a single vendor. So, do you need different clouds for different applications?
Enter stage left multi-cloud.
The trouble is, managing multiple cloud vendors bring challenges. Differences in pricing, procurement and technology to name but a few. How do you provide connectivity between multiple providers and ensure common governance and policy across them? Does multi-cloud mean you effectively commoditise cloud and only realise the lowest common denominator across all providers? It’s a tough one!
Different clouds for different crowds
My favourite saying is “Different Clouds for Different Crowds”. I annoy people by constantly repeating it, but I do fundamentally believe it to be true. What I mean by this is that applications will be deployed or consumed from different clouds based on their requirements. It’s all about the service and not the cloud. For example, you may have some application that can reside anywhere with no performance, pricing and compliance concerns. So, stick them wherever.
Then you may have some applications that require capabilities only available on a particular cloud. So, go for it, stick them there. Other applications maybe consumed as a service so you go to the best SaaS provider for those.
But of course, in order to do this, I need a tool to take away the multi-cloud challenges. Enter stage right… Cisco Cloud Centre.
Managing multi-cloud
We have a solution called CloudCenter. It’s pretty cool.
Its basic premise is that you abstract the application from the underlying cloud or infrastructure. You model the application once, then you deploy anywhere. CloudCenter takes care of the all the cloud specific nuances. You just focus on your apps.
Cisco CloudCenter Framework 
Another aspect CloudCenter takes care of is governance. It has a comprehensive policy model that ensures applications are only deployed where they should be. You can build custom polices covering concerns like data sovereignty, compliance, risk, performance and cost.
It works with all major public cloud providers and your on-premise investments like VMware and Openstack.
Ultimately it’s all about the qualification. Different Clouds for different crowds. Some of your services will rightly be entrenched and locked-in to a cloud provider because it makes sense. Others will be mobile and deployed according to price, performance and policy. Then there’ll be those that will happily tick along in your data centres.
Authors
