The cloud market is dominated by a small number of companies with significant market share and power. In the third quarter of 2018, Amazon Web Services (AWS) held 34 percent of the market followed by Microsoft with 14 per cent and Google, IBM and Alibaba making up the other key players. These companies have attracted customers through their innovation, vast computing capabilities and continued price cuts.
Like any market dominated by a small number of very large players (Synergy estimates that the top five public cloud providers control almost three quarters of the market) the cloud oligopoly brings both opportunities and challenges.
Firstly, one of the major benefits in having a few companies lead the market is the compatibility it offers to end users. Before the emergence of these hyperscale, public cloud providers, the market was much more distributed across various cloud platforms (mostly vCloud and opensource cloud stacks).
See also: Cloudy, with a Chance of Overspend
If we think of the mobile phone market, prior to the iPhone and Android for example, every handset maker had its own operating system with few applications and limited usability.
Then when the market shifted to iOS and Android it became much easier to develop apps for just two key operating systems. That leads to a virtuous circle with the dominance of those platforms leading developers to build only for them, and the higher availability of apps driving the success of iOS and Android. There are similarities now with enterprise software and tools – and their compatibility with the major cloud providers.
This heavy reliance on a small group of companies also increases risk. As more businesses and services are run on a small number of providers, it centralises the risk of IT downtime and operational disruption.
Over the last decade, the average IT department’s infrastructure has become much more disparate. We talk about ‘the cloud’ as a singular technology but in reality an IT department will probably be using several different cloud services, in addition to some servers on-premises. This disparate setup reduces risk because it is far less likely that any incident will affect all of those systems at once.
However, now we see a consolidation to a small number of cloud providers. A vast proportion of internet services could become inactive if one of the providers suffers a major outage. On the rare occasions we do see major cloud failures hundreds or thousands of its customers are affected. This poses a significant threat to supply chains and must be effectively planned for.
The first step is to take stock of your infrastructure and vendor relationships. Identify the cloud services you are reliant on and interrogate suppliers about their supply chain. Find out where your SaaS services are actually hosted from to see if many systems are at risk on one particular platform.
For IaaS, the onus is on the cloud customer to build resilience using the tools available. Like any mitigation, you need to balance risk and cost.
If you are concerned about having all your eggs in one basket, with one cloud provider, the obvious choice is surely to use more than one cloud? You could use different clouds for different applications or use one cloud for production systems and another for backup. But, there are also some strong reasons to commit to a single cloud. Using multiple clouds requires more skills and knowledge which can be difficult to maintain and it increases cost.
What are the options for cloud-resilience?
Building Resilience across Availability Zones
At a minimum, you should architect your environment across multiple Availability Zones. This should be the baseline for every company. Each geographic region a cloud provider operates in are made up of Availability Zones (or Zones, depending on the provider’s terminology). These are like data centres within data centres. Building your infrastructure across at least two Availability Zones’ limits single points of failure.
Building Resilience across Regions
The next step to consider is building resilience across different regions. Region-wide outages are rare but they do happen, and so architecting across more than one region will further reduce risk. Building across regions is however more complex and expensive.
Building Resilience Across Cloud Service Providers
The last stage of cloud resilience is to use multiple cloud providers. Again, there are considerations that can make this option difficult or simply impractical, including:
- Vendor lock-in and software incompatibility can prevent running some applications across multiple clouds
- Increased technical management overhead
- High egress charges limiting movement of data out of clouds
Immediate failover to another cloud may not be practical but having copies of data outside of the production environment is a necessity. Backup to another cloud destination is inexpensive and we would recommend it as a minimum.
Containers and the Future
Multi-cloud resilience is still in its infancy. New methods are emerging that will make it easier to use multiple clouds, both for resiliency and to move workloads between clouds. Containers allow you to move applications between clouds and Infrastructure-as-Code methods and tools mean you can create and destroy environments quickly and repeatably.
For a long time we’ve argued that the cloud makes computing a utility. The utility market is another oligopoly market worth comparing here. It’s an important function of the electricity market for instance that customers are able to switch supplier easily in order to take advantage of savings.
In this young, cloud market we’ve not yet seen issues with tacit price coordination as has been the case for electricity but containers will provide the solution to another of the potential pitfalls of the oligopoly.