Multi-cloud: What enterprises need to know
In this guest post, Allan Brearley, cloud practice lead at IT services consultancy ECS, takes a look at what enterprises need to bear in mind before they take the plunge on multi-cloud.
There’s no doubt that enterprise interest in multi-cloud deployments is on the rise, as organisations look for ways to run their applications and workloads in the cloud environments where it makes most sense to.
When enterprises move workloads on demand, they can achieve cost advantages, avoid supplier lock-in, support fiduciary responsibility, and reduce risk, but there is a flip side to this coin.
Enterprises in the single-cloud camp counter that multi-cloud introduces unnecessary complexity, increasing management overhead and diluting the value of cloud to the lowest common denominator of commodity infrastructure.
In short, customers taking this approach fail to fully exploit all the advantages the cloud model can provider.
So who’s right?
Multi-cloud to avoid vendor lock-in
One of the most popular arguments we hear in favour of adopting a multi-cloud strategy is to avoid vendor lock-in. After all, who wants to be tied to one supplier who notionally holds all the cards in the relationship when cloud has made it possible to run workloads and applications anywhere?
In my view, this is a partially-flawed argument, given that large enterprises have always been tied into inflexible multi-year contracts with many of the established hardware and software suppliers.
For some enterprises, multi-cloud means using different providers to take advantage of the best bits of each of their respective platforms. For others, multi-cloud is about using commodity compute and storage services in an agnostic fashion.
Anyone who opts for full-fat multi-cloud will have access to an extensive choice of capabilities from each supplier, but this comes at a price.
Unless they limit their cloud adoption to the Infrastructure-as-a-Service (IaaS) level, only then will they unlock the benefits that come from having access to near infinite on-demand compute and storage capability, including reduced costs.
But this skimmed-milk version of multi-cloud increases the burden of managing numerous suppliers and technology stacks, limiting the ability to increase pace and agility and hampering the ability to unlock the truly transformative gains of cloud.
Managing a multi-cloud
Many enterprises underestimate the management and technical overheads – plus skillsets – involved in supporting a multi-cloud strategy. Managing infrastructure, budgets, technology deployments and security across multiple vendors quickly progresses from a minor irritation to a full-blown migraine.
While there are a plethora of tools and platforms designed to address this, there is no single, silver bullet to magic away the pain.
As well as considering the in-house skills sets required for a multi-cloud model, another factor is the location of your data. With the increasing focus on aggregating data and analysing it in real-time, the proximity of data impacts any decision on the use of single cloud vs multi-cloud vs hybrid.
The costs associated with data ingress and egress between on-premise and multiple cloud providers need to be carefully assessed and controlled.
Best of both
But don’t panic, there is another option. It is possible to secure the best of both worlds by opting for an agnostic approach with a single cloud provider and designing your own ‘get out of jail free’ card that makes it easy to one of its competitors. With a clear exit strategy in place at the outset, you can take advantage of the full capabilities of a single vendor and avoid significant costs.
The exit strategy needs to address the use of higher value services. For example, if you use Lambda or Kinesis in the Amazon Web Services cloud, what options would you have if you decide to move to Microsoft Azure, Google Cloud Platform or even back on-premise?
Always consider the application architecture and if you aim for a loosely coupled stateless design, it will be easier to port applications.
Assuming you extend the use of cloud resources beyond commodity IaaS into higher-level PaaS services, such as AWS’s Lambda, you will develop functions as reactions to events.
This pattern, although labelled as ‘serverless’ can be replicated in a non-serverless environment by making these functions available as microservices.
If you later decide to migrate away from a single provider in future, you can use Google Functions or a combination of microservices and containerisation, for example.
By maintaining a clear understanding of which proprietary services are being consumed, you will make it easier to re-host elsewhere while complying with regulations.
As with most enterprise decisions, there’s no clear-cut right or wrong answer on which leap into the cloud to take. The right approach for your organisation will reflect the need to balance the ambition to adopt new technology and increase the pace of change, with the desire to manage risk appropriately.