With 81% of enterprises that use public cloud facilities using multiple providers, a cloud agnostic development strategy is becoming a necessity. Applications and infrastructure simply has to be compatible across public, and private, clouds if practical levels of flexibility are to be built in.
Even for those organisations that currently use only one public cloud provider, cloud agnostic development is the only way to insure themselves against the future headache and expense that vendor lock-in might become. If infrastructure and app architecture and development is not cloud agnostic, potential future decisions to move to a multi-cloud footing, or simply change one provider to another, become limited and complex.
Here we’ll explore:
As of 2019, an astonishing 90% of companies relied on cloud computing for at least some of their workloads. And companies are not just using the cloud for more specific workloads. A whole 60% of total workloads were running on the cloud, up from 45% a year earlier. 2020 figures, when available, will almost certainly show that level of growth continuing.
Double-digit growth in the workloads that have been migrated to the cloud, and the fact that comfortably over 50% are cloud-powered are significant statistics. They demonstrate that cloud deployment has become the standard for digitally enabled organisations. Half of large companies spend more than $1.2 million on their public cloud deployments annually and 30% of all IT budgets are allocated to cloud computing resource.
Public cloud facilities including processing power, storage and software run on virtual machines are provided online by third party companies. The biggest 10 public cloud providers – led by AWS, Microsoft Azure, Google Cloud Platform & Alibaba – control over 50% of the public cloud market.
“Organizations leverage almost 5 different cloud platforms on average”. – hostingtribunal.com, Cloud Adoption Statistics for 2020.
Why are organisations using more than one public cloud platform to run workloads? Another statistic sheds light on the question:
“Managing cloud costs was at the top of companies’ 2019 priority list for the third year in a row” – Rightscale, State of The Cloud Survey 2019
Public loud computing services are, in most cases, a more cost-efficient way for organisations to run workloads than investing in their own infrastructure. Private infrastructure needs to be able to deal with peaks in demand, even if they are relatively rare. Public cloud infrastructure offers automated scaling of available resources on a pay-as-you-use basis.
That means extra resources are only paid for during occasional peaks. Organisations are not left with a choice between investing in sometimes very expensive infrastructure that is only occasionally needed or suffering downtime or outages during peaks in workload.
A cloud agnostic strategy takes the flexibility inherent in the use of public cloud facilities up another level. If workloads and applications are built to run within any public cloud, preferences can be set to switch them between different providers based on their performance and cost efficiency in the context of dynamic factors like geography and the strengths and offerings of different providers. Or if one provider experiences temporary technical issues.
Being cloud agnostic offers a level of flexibility which improves cost efficiencies even more than simply using the public cloud. Especially for organisations with high workloads, even incremental differences in cost can add up to significant sums. And for many digitally enabled organisations, incremental gains in performance and insurance against technical problems on the provider-side is as much of an incentive to becoming cloud agnostic as cost efficiencies.
A Bain & Company report found that 22% of companies that use public cloud facilities see the risk of vendor lock-in as one of their biggest concerns. The term vendor lock-in refers to an over reliance on the products or services of a particular vendor. That leaves the organisation vulnerable to prices being raised, changes to or the discontinuation of particular offerings or even, in the worst case scenario, operations being halted.
This means that even for organisations that only use one public cloud provider because their service currently meets their needs on pricing, performance, functionalities, capabilities and reliability, it is important to build applications and infrastructure in a way that allows for an easy switch if circumstances change.
Even in these still relatively early days of cloud migration, there have already been numerous examples of the downside to being exposed to vendor lock-in. One of the best know is the case of public cloud data storage pioneer Nirvanix, which went out of business back in 2013. Users were given just 2 weeks to move their data.
While it is unlikely that the big boys of AWS, Microsoft Azure, Google Cloud Platform or Alibaba will go out of business a quick look back in history and what happened to AOL shows nothing is guaranteed. More likely, as competition heats up, certain vendors may choose to alter or pivot their business model in a way that changes their offering for certain clients.
Ultimately, the large majority of vendor lock-in scenarios will be a case of a lack of cloud agnostic flexibility leading to a loss of operational and cost efficiencies rather than a doomsday scenario of a provider going out of business at short notice. But for a growing number of cloud-enabled organisations, that threat is more than enough of an incentive to adopt a cloud agnostic strategy.
A perfect example of that is the situation Snapchat owner Snap recently found itself in. Plans to restructure in a way that would allow for smooth future growth was stymied by the fact the social media app’s infrastructure was directly tied to Google Cloud. This meant making the necessary business transitions would have incurred significantly higher costs and excess resource allocation than anticipated. Snap’s answer was to invest in Amazon Web Services (AWS) infrastructure that would diversify their vendor portfolio and reduce risk.
When Snap originally built their application and infrastructure, a cloud agnostic approach would have been practically impossible. Thankfully, that’s no longer the case, meaning today’s growing companies can avoid the expense and complexities Snap encountered.
To sum up, the main pros, or benefits, to a cloud agnostic strategy are:
A cloud agnostic strategy allows you to switch cloud providers with minimal headache if pricing, performance or offerings change. It also means you can take a multi-cloud approach which sees workloads split between providers.
This means you won’t miss out on useful features exclusively available from one or a limited number of providers. Simply run the workloads that feature benefits with the provider that offers it. And others on the cloud service of the providers whose offerings are optimal for them.
Spreading systems and workloads across more than one cloud platform avoids the risk of redundancy and downtime if one encounters problems.
A ‘pro’ that overlaps with the previous two. Cloud agnostic organisations have risk management in place which makes them generally more robust to changes in the business IT landscape.
And with two sides to every coin, what are the cons to a cloud agnostic strategy?
While going cloud agnostic can see huge savings on time, costs and stress down the line, it does involve more front-loaded work. Building an agnostic cloud strategy from the ground up, either for particular workloads or across an organisation, can be expected to increase initial development costs and complexity.
A strict cloud agnostic approach could mean an organisation limits itself to using services available across the public cloud providers its multi-cloud strategy uses. If one of AWS, Microsoft Azure, Alibaba and Google Cloud Platform, or another larger provider, introduces a handy new feature, a strictly cloud agnostic strategy may mean there is a reluctance to use it because it can’t be replicated on another platform.
For many organisations, particularly at enterprise level, more choice is generally considered a plus. But if there is a refusal to lock-in even a small number of specific workloads to a provider offering a unique and beneficial feature, that could also, in certain circumstances, prove limiting.
For example, the Amazon Relational Database Service (Amazon RDS) “makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while automating time-consuming administration tasks such as hardware provisioning, database setup, patching and backups. It frees you to focus on your applications so you can give them the fast performance, high availability, security and compatibility they need”.
An organisation attempting to host their own database instance on an EC2 instance would have to take on the management of the instance. Achieving the same level of resiliency or performance could potentially take hundreds of development hours. For many organisations, especially those smaller than enterprise level, that may not be a trade-off that is justifiable.
Let’s take a look at 2 very different companies, one a tech start-up and one a blue chip financial services enterprise and constituent of the London Stock Exchange’s FTSE 100 index of the UK’s 100 largest public companies:
Cuddle.ai, the AI-driven business data analysis app took the decision to develop their application as cloud agnostic.
“We found out we wanted to target organizations across the globe. Some customers preferred a particular cloud provider because of their prior experience working with them or because of their business interests”.
Because the team wanted the app to be able to run on any cloud platform, Cuddle made the choice to build it as cloud agnostic from the ground up, concluding:
“Cloud agnostic architecture is a reality. It is difficult but not impossible. We need to make some choices early on and stick to the system design principles to be able to support multiple clouds”.
You can read the full case study, including how the business decision was arrived at and choice of technologies and DevOps processes implemented here.
Experian is an international blue chip financial services enterprise listed on the London Stock Exchange and a constituent of the FTSE 100.
In 2015, the company appointed Barry Libenson, formerly of Cisco and U.S. retail giant Safeway, as the company’s new CIO. One of his priorities, now seen as a key achievement, was to create a standardised approach to software development.
While he inherited what he saw as a strong team of developers, his challenge was around decentralisation with developers in locations around the world using a range of coding standards, databases and platforms:
“I wanted to get everybody to use the same techniques – we standardised a lot more on open source,” said Libenson in an interview with Computer Weekly. He wanted to make it easier for Experian’s developers to work across cloud platforms.
Experian has supported this change in strategy through containers, the adoption of Red Hat’s OpenShift platform and Kubernetes to help deploy and manage its containers.
“The reason we did that was to be cloud agnostic, so it gives us the ability to build on-premise, to build on Microsoft’s cloud, to build on Google’s cloud, to build on Amazon’s cloud, and then move things around. I think we’ve come a long way in terms of achieving our aims in software development.”
There are increasing choices when it comes to a cloud agnostic development tech stack but here are some of the most popular ingredients K&C’s engineers use to bake apps as comfortable on one cloud platform as another:
Because a cloud agnotistic strategy inherently increases the workload shouldered by DevOps, an automate-first approach is key. Infrastructure should be spinnable with little to no manual effort and testing and integration managed through a scheduled CI pipeline requiring approvals.
The work of DevOps considerably increases with a cloud-agnostic strategy. So we started with an automate first mentality. Infrastructure should be created easily with almost no manual intervention, CI pipeline for easy integration & testing. Deployment pipelines to accommodate scheduled deployments with approvals.
Microservices architecture structures an application as a collection of services that are broken into small units, each serving a specific business function and interacting with each other. Applications, especially if intended as cloud agnostic, are easier to both build and maintain when broken down into more manageable microservice units. Microservices are:
The microservice architecture allows for the rapid, frequent and reliable delivery of large, complex applications. It also far easier for organisation to introduce changes or additions to its technology stack within a microservices environment.
A containerisation technology, Docker reduces friction when migrating workloads from one cloud platform to another. Within the Docker container, application needs such as runtime, environmental variables and setups scrips are defined. That means the container can, with minor exceptions, be launched almost anywhere.
If containers are then placed into a container orchestration platform, this will manage the lifecycle as well as, if requested, logging and monitoring. The OCI-compliant container runtime then smooths out any discrepancy between hosts while running the application.
A relatively new Command Line Interface (CLI), HashiCorp Terraform helps define infrastructure as code. It allows for the specification of cloud provider, access keys and secret keys when running terraform apply. The CLI then spins up the infrastructure, which the developer deploys on top of.
Pulling that infrastructure down again when necessary is as easy as auctioning the terraform destroy command.
It using Hashicorp Terraform like this does mean that writing multiple Terraform scripts is necessary for each distinct cloud provider in a multi-cloud approach for organisations that wish to be cloud agnostic. These scripts also need to be maintained if the organisation wants to have the option to switch providers at any given moment.
Developers writing scripts for different cloud providers will need a level of knowledge on each platform to be explicit about the instance types being spun up and to know the correct size of these instances.
Ansible, Chef and Puppet are all other examples of configuration tools that have similar core functionalities, while each has their own specifics, that can be used as part of a cloud agnostic strategy.
Check out the video below on the subject of Best Practices of Infrastructure as Code with HashiCorp Terraform
Kubernetes, combined with Docker and Terraform, can further extend a cloud agnostic strategy when used as part of the new generation of managed multi-cloud Kubernetes solutions such as Istio. Istio amalgamates Kubernetes clusters in a way that means they run and manage contain-based applications. This abstracts away from the infrastructure code is running on and means developers can focus on how an application looks.
The cloud agnostic technology stack still needs some time to mature and is not yet perfect for every kind of organisation, enterprise or individual app. But even if full agnosticism is not achieved, container and managed database technologies can still go a long way to making your organisation more flexible and adaptable to future changes in a dynamic IT environment.
If you are considering if a cloud agnostic strategy makes sense for your organisation, or a particular application you are developing, and want to explore the pros and cons with experts that have experience of a huge range of scenarios, we’d love to lend you that experience and insight.
Get in touch to talk things through. Let’s see if cloud agnostic is for you!