Single Cloud vs Multi Cloud Strategy

Introduction.

A discussion which comes up often with our clients is that of Single vs Multi Cloud Strategy. Its an interesting topic to dig into and whilst benefits are evident for both approaches, it largely depends on the perspective you are coming from.

Lets do the TL;DR  - Fenergo as a SaaS Vendor align firmly with the Single Cloud approach, partnering  with AWS works exceptionally well from our perspective based on the type of software we create and in this post I'll look at why that is the case and also why some IT Professionals might favour a Multi-Cloud strategy.

A Cloud is a Cloud is a Cloud - Except when it isn’t.

The terms "Cloud Adoption, Cloud Migration, Cloud Deployments, Cloud Provisioning" have so much crossover that they can almost be used interchangeably.  Consider a software product or technical platform  that previously lived on infrastructure you own (or a private data centre you manage) and the simple objective is to have that asset provisioned from a cloud platform. In this Lift and Shift approach, you start with your technology stack, then identify cloud based equivalents (often VMs or maybe containers), and move it lock stock and lot onto a cloud provider. The underlying cloud vendor is largely not relevant. It can be selected based on cost, service availability or existing staff skillsets. Any differentiator might be more prominent for different organisations, but ultimately your stack is one which can operate on top of any cloud vendor.  Job Done, a cloud is a cloud is a cloud. 

Except when its not: consider a more modern term, Cloud Native. This is the latest way cloud providers have commoditised infrastructure to what must be approaching the lower common denominator. With Cloud Native software solutions, that software is born in the cloud. No different from someone being born in a country versus someone migrating to that same country. For natives, the cloud is all they know. They are unburdened of the constraints from foreign lands such as Operating System or DBMS reliance, hardware dependance or peak load provisioning. Such solutions are built on Services rather than Platforms and have the benefit of removing any direct responsibility for managing even virtual infrastructure.

Across  these  two separate camps of: native software and migrant software, how do they compare from a cloud perspective?

Multi-Cloud Perspective.

Setting aside the style of software being run on the cloud, having a multi-cloud strategy surfaces a lot of benefits for getting the best from multiple vendors. There now exists many vendors (a lot more that just the 3 well known: AWS, Microsoft and Google) and they all have compelling pros, cons or niches  across pricing, geographic availability, resilience etc... Any budget conscious risk adverse IT Professional  would be forgiven  for using the below list as justification to pursue a multi-cloud strategy. 

• Pick and choose from a broader range of services rather than compromising to what is available with a single vendor. 
• Optimise for cost & avail of special offers or specific vendor incentives & partnerships. 
• Higher degree of flexibility in selecting where to run your workloads, being able to select across multiple global locations. Could be strategic Middle East/ APAC locations that offer market advantage.
• Independence  of choice removes any reliance of a specific vendor. 

Even using a raw comparison metrics like available  global regions between two major cloud vendors can strongly influence selection.  If Single-Cloud is selected, deployments are limited to the regions where that vendor has deployed their data centres. With Multi Cloud global options can be assessed collectively and that total availability can be sold as a service offering to the users of your cloud software, essentially reselling that flexibility as a benefit. 

But . . . This is rather hypothetical or at least software agnostic.

Lets get less speculative and more software specific. Even with all the above compelling arguments, Fenergo has chosen to offers its software exclusively from AWS. We have a Single Cloud strategy and for strong, compelling reasons. 

Firstly, we have built a Cloud Native product. It has been designed from the ground up to take full advantage of the best benefits the cloud has to offer by using managed services. Think of the difference between a  Cloud Native vs Traditional provisioning of data storage. Traditionally you start with a server & operating system. Then deploy your DBMS and licensing. You will need resilience to handle peak loads so not just a single server but potentially a cluster. Then you have to consider Disaster Recovery, Security, Patching and Maintenance. A lot of work has to be done before your developer can create or read a record in that data store. All the developer (or the actual software product itself for that matter) wants is a connection string. The Cloud Native approach is essentially "a Data Store as a Service".  You create connections to managed services and your time, energy and skills go straight to your product. That same approach of using managed services across a full enterprise tech stack can result in a streamlined development organisation with skills focused on product/ feature enhancement. Granted this may be oversimplifying the provisioning and management a little, but not by much. You will certainly need a cloud architect, but you do not need one for each cloud vendor. 

Secondly, in Fenergo we sell a SaaS platform. One of the key advantages of the cloud is to achieve a reduced "Total Cost of Ownership" and benefit from strong "Economies of Scale". We have multiple tenants sharing common infrastructure and designed tenant isolation from the grass roots. Each new client does not result in new infrastructure for us, we benefit directly from the scalable services we have selected. Our technology stack includes, APIs, UIs, Processing Logic, Data Stores, Queuing and Workflows. In a traditional on premise deployment this would require multiples of physical servers / VMs. A lift and shift to cloud would benefit from containers but still a lot of moving parts and skills in operations to get the baselines in place. With Cloud Native services, all of that infrastructure management is eliminated and our SaaS clients collectively benefit from using a single codebase where tenant isolation does not require a blunt, costly separate tech stack strategy. 

What about vendor lock-in?

Being a native comes with some downsides, most often quoted being vendor lock in. If you adopt a service like AWS Lambda, you are managing almost nothing except the code you execute. The interfaces into that code (hooks that call it), performance, availability and "Continuous  Integration / Continuous Delivery" would all be part of / integrated with the AWS stack. The modern principal "Automating Everything" will depend on vendor specific interfaces. The code being used at the heart of your application could well be something portable like .NET CORE or Python, but it would be a heavy uplift to create like-for-like versions that target the various managed services of multiple vendors. If such effort was undertaken (and I doubt any Cloud Native SaaS vendor is doing this) you might have to accommodate inconsistencies  between versions. Inherent differences in features, performance or pricing. At best you would be creating a multi-cloud-native solution that peaks at the feature parity between vendors, at worst you could end up with multiple code bases, multiple CI/CD pipelines and broader skillset dependancy. It would be creating technical debt and limitations right out of the gate and arguably negating the whole point of using managed services in the first place. So if your application is going to use managed services  to scale, affinity to a single vendor is likely to be a hard dependency.

The Bottom Line.

Step one for organisations looking to benefit from the advantages offered by the cloud is to move their existing workloads. Supporting this is the most basic service offered by cloud vendors. Some cost optimisation would be achieved through careful analysis and configuration, but if you managed 100 VMs across owned infrastructure and move them to the cloud, you are still managing 100 VMs,  just from a different place with a lot of the preexisting overheads remaining. If you plan to stick with traditional software simply located in the cloud, a multi cloud strategy is viable, allowing you to double up on deployments or use a different vendor for your DR. As your software strategy evolves, and you step further into cloud eco systems, that flexibility could become an anchor holding back your ability to embrace modern capabilities . 

Look at how the vendors have commoditised their offerings. Virtual Server Instances, Containers, Spot Instances all the way to Code as a Service. Cloud Vendors want to maximise their own economies of scale and now software creators can build solutions where you pay in milliseconds for the time your code spends executing, or in Kilobytes for the size of a record read. Software cannot be broken down to a lower more granular level of control where you truly pay for what you consume. 

When we faced a choice of creating the best solution possible for our clients from the ground up, we chose to take full advantage of what the modern cloud has to offer. The trade off of being aligned exclusively to AWS is far outweighed by the benefits we can offer our clients and cost optimisations achievable by using Serverless Services. 

George McGrane is a Technical Advocate for the Fenergo SaaS Engineering Team and has been with Fenergo for 5 years.