In 2020 90% Of Enterprises Have Already Evolved A Multi Cloud Strategy. When is the right time for you? Or is a multi cloud approach even right for your organisation?
Why has a multi cloud strategy, and one with a high level of diversification between cloud providers and platforms, so quickly become a priority for so many enterprises?
Is it really the “silver bullet” to optimise the benefits from your cloud strategy, gain the best of all worlds and avoid vendor-lock-in at the same time? Or does the balance shift with a specific organisation’s needs, priorities and workloads?
Our experience suggests the latter.
The terms multi cloud and hybrid cloud often appear together but there is an important distinction between the two. A multi cloud strategy refers specifically to the use of more than one public cloud platform. A hybrid cloud computing strategy on the other hand, involves the coordination use of a combination of public and private, external and internal, cloud services.
Staying competitive in the contemporary digital economy involves numerous factors. One of those factors is the performance optimisation of digital resources, whether client facing or internal. Another is the cost of keeping the workloads that support those digital resources running.
For many digitally progressive companies, a multi cloud strategy is an important part of both performance and cost optimisation. While all public cloud platform providers offer the same basic service, they also each have their own strengths, weaknesses and proprietary functionalities.
A well-managed multi cloud strategy allows an organisation the luxury of freedom to smoothly move different workloads between providers – optimising the benefit gained from the strengths of each provider while neutralising their weaknesses. In this way, a single user transaction can seamlessly leverage multiple providers – a scenario not uncommon for organisations with a well-developed and executed multi cloud strategy.
If these factors are priorities for your organisation, and are not outweighed by those covered in the next section, then it sounds like a multi cloud strategy could be a good fit:
Escaping the confines of vendor lock-in is for many organisations the strategic catalyst behind the adoption of a multi cloud strategy. If it is clear that all development has to as cloud agnostic as possible as a matter of course, engineers can build apps in a way that allows for all their components to be runnable across cloud providers.
This means workloads can be transferred depending on which provider offers the best pricing model for specific resources required or has capabilities than optimise performance. But most importantly, from a strategic point of view, it transfers the balance of power from provider to you.
If you are an enterprise-level user, you’ll be in a stronger position to potentially negotiate a custom price plan or other concessions. And you won’t be exposed to your cloud provider representing a potential point of failure. Or be faced with the headache or expense of a major redesign the entire organisation’s app architecture if you want to move workload from one cloud provider to another for any other reason.
Building apps to be cloud agnostic as part of a multi cloud strategy does mean a larger upfront allocation of resources. It takes more time and requires specialist knowledge and experience.
But that front-loaded allocation of resources can potentially save an organisation from much larger expense and headache further down the line. Being able to switch workloads to the cloud provider that offers the best price to features balance for a particular workload at any given time could mean much more significant savings than the extra initial development cost.
Not having to redevelop an app’s architecture to run on a different cloud platform to the one it was originally developed for, whatever the reason behind the change, will also often far outweigh the originally higher development costs.
In the early days of public cloud platforms, the resource was essentially just IaaS (infrastructure as a service) and involved the use of APIs to access elastic server resource. A ‘workload’ was basically data attached to an approximate idea of how it would be processed.
Today’s cloud is a much more sophisticated beast. The definition of what a ‘workload’ is has evolved into a set of components that support an application. Each of those components might be better suited to one cloud platform than another. That would mean optimal performance of the app would be achieved through running different components on different cloud platforms.
The good news is running different components of a single app on different clouds is now absolutely possible – if they have been developed to be cloud agnostic and can be seamlessly switched between providers.
For some organisations, especially at an enterprise level, incremental improvement in workload running performance between public cloud providers, will more than justify the incremental increase in initial costs to develop apps cloud agnostically.
A multi cloud strategy also leaves no room for any significant app downtime. If the primary cloud platform encounters, for whatever reason, difficulties in processes a particular service, for example an e-commerce transaction, another cloud within the strategy acts as the failover solution, taking over the processing of the service. The user will be none-the-wiser. Once the original cloud resumes normal function, the operations can automatically be handed back to it.
One negative side-effect to the growth of cloud deployments is that the trend has been shadowed by a reflective growth in DDoS attacks. DDoS attacks have the potential to not only take a site or application down but keep it down.
A multi cloud strategy adds an additional level of robustness against DDoS attacks. If the primary cloud platform suffers a DDoS attack, the load will automatically and seamlessly shift to another cloud environment, keeping the application up and running.
In conclusion, the benefits of a multi cloud approach can be lower long-term costs, better app performance, improved reliability, tighter security and the strategic avoidance of over-reliance on a single third-party provider.
There is never one single approach that is definitively the most suitable for every single organisation and every single app in every single circumstance. A multi cloud strategy is no different. You may not be ready for, or necessarily benefit from, a multi cloud approach.
What are the factors that might indicate you don’t necessarily need a multi cloud strategy?
Organisations that focus their development on a single public cloud vendor’s technology stack are the most common exception to the multi cloud trend. The question that anyone pursuing a single-cloud strategy must ask themselves is:
“Are both benefits to cloud agnostic development for a multi cloud strategy and risk of not doing so relatively low”?
If the answer to that question is “yes”, there is an argument that allocating resources to a multi cloud may not be optimal in the case of the particular organisation.
As covered in reasons why a multi cloud strategy could benefit an organisation, one of the more popular reasons why enterprises opt for multi cloud approach is to pit vendors against each other in price negotiations and to automate the switch of workloads between cloud platforms to optimise execution costs.
For organisations that are intensive users of public cloud resources, these incremental gains in cost optimisation, and negotiating customised deals, can add up to a lot of money. For other organisations that don’t have the resources to effectively track and control costs across different platforms for different workloads, or aren’t big enough customers to negotiate custom agreements, a multi cloud approach might result in losing track of cloud expenses.
Mastering development to run workloads on one cloud is not easy. It requires an investment in either training people, or hiring in experience, whether directly or via an IT outsourcing partner. It also involves developing processes and introducing new tooling and technology. All of that costs money – usually a lot of money. And it can take months to get up and running.
A multi cloud strategy multiplies that investment across different clouds. An organisation needs to invest in having experts that deeply understand the nuances and particularities of each cloud in a multi cloud set-up.
If that engineering and QA resource is not available, the organisation runs the risk of inverting the very benefits a multi cloud strategy is supposed to offer – cost, performance, agility and innovation.
Organisations developing for a multi cloud set-up, without a deep and skilled enough engineering resource to take it on, can send costs up and compromise how well workloads run on different clouds. An ill-equipped team trying to juggle workloads across clouds can also see reliance and security levels fall. Another example of the opposite of what a multi cloud strategy should offer.
All public cloud platforms offer the same lowest common denominator services of compute, storage, network. Workloads that only want, or need, to take advantage of those basic public cloud services can be containerised and developed as cloud agnostic.
However, the moment your engineers want to use unique, higher order features of a particular cloud vendor, like Amazon EBS for EC-2 instances, or Azure’s Cosmos DB, applications lose portability between multiple clouds. True cloud agnostic development that offers consistent management across different clouds precludes the use of unique features.
For larger organisations with the bodies and expertise across different clouds, a multi cloud strategy can still take advantage of unique features of different clouds by building certain applications, or components, to run on particular vendor platforms. And switching workloads that only take advantage of common storage, compute and network functionalities, between clouds as and when that makes sense.
But for other organisations that isn’t practical and it may well make sense to develop for one cloud platform that engineers are experts in and offers unique and higher-level features that best meet your needs.
A multi cloud strategy often appeals to management and C-Suite priorities more than it does to an organisation’s development teams. Especially if development capacity and expertise is limited.
There are, as we’ve seen, advantages, and disadvantages/risks, to both a multi cloud strategy and one that develops a deeper relationship with (or dependency on) a single public cloud provider.
Which is right for you both depends on your organisation’s business and digital priorities, resources and technology needs. Despite the strong trend towards a multi cloud strategy, particularly at enterprise level, it isn’t always necessarily the best fit in every case.
Under the right circumstances, a multi cloud strategy can save a lot of money, improve performance, reliability, security and flexibility. Under the wrong circumstances, a multi cloud approach can achieve the exact opposite.
Make sure your organisation carries out an analytical review of the upside to downside to multi cloud in your particular context. Don’t simply follow the trend blindly.
And if input from a team that’s seen the best and worst outcomes of multi cloud strategies would help you reach an informed decision, get in touch. K&C is at your service!