The Four Stages of Cloud Adoption

A quick look at the adoption of technology over the last 60 years shows us that no one vendor, technology or concept becomes 100% dominant. Back in September 2017, I presented at Scality’s SDS day on what I thought the future of storage and cloud would be. With technology and specifically cloud adoption in mind, I suggested that the long-term future of IT will be multi-cloud. What does that mean and how do we get there?

The Four Stages of Cloud Adoption

In my presentation, I suggest that we have four stages of cloud adoption (in the presentation, it’s three public maturity stages after private).

Stage 1 – Private Cloud

There have been lots of discussions recently about whether private cloud exists at all, however, in this context, I’m thinking more about business transformation than technology. Instead of deploying infrastructure on a project-by-project basis, businesses should be charged for what they logically consume. This is a hard transition for many organisations that traditionally run IT as a loss-making division. Moving to private cloud means implementing service catalogues and service-based charging. It also means transforming infrastructure to abstract from the use of specific technologies. A virtual machine/instance could be delivered via VMware vSphere, Microsoft Hyper-V, KVM, or a hyper-converged solution using any of these technologies. However, virtual infrastructure alone doesn’t define private cloud.

Stage 2 – Single Public Cloud

The first step into public cloud is to try working with a single cloud provider. Many of the issues with moving to using AWS, GCP or Azure are process related. This includes understanding how billing will work (and be sub-charged to different lines of business). There are still traditional capacity management problems to address. Public cloud makes it easy to upload terabytes of data and create instances way bigger than may actually be necessary. Public cloud providers also operate their services in the way they have chosen to work. So features such as networking, storage and security will operate in a very specific way. The IT organisation has to adapt to the cloud provider and not the other way around.

Working with a single provider does have some benefits. There is only one set of technologies to learn. Billing is managed in one place. There’s no need to compare the cost of resources with other providers unless a comparison with private cloud makes sense. Data mobility and data protection issues exist, but in many cases, applications exist only either in public or private locations. This means data movement is likely to be a one-time task.

Stage 3 – Multi-Cloud

At some point, the limits of working with a single public provider get reached. Perhaps one vendor offers services another doesn’t, or implements them better. Company policy may dictate not having a dependence on a single provider. There may be savings in cost in running some services with one specific provider, either for spot or long-term instances. We’re already seeing CSP (cloud service provider) differentiation. VMware has partnered with AWS to offer native vSphere functionality. Microsoft has countered this with limited access to vSphere, although it isn’t clear whether this will be supported. AWS has introduced many new machine learning and AI features. Google is known for analytics capabilities. Azure partnered with NetApp to provide Enterprise NFS.

Stage 4 – Multi-Cloud Brokerage

Initially, multi-cloud will be tactical, to overcome some of the issues we’ve presented here. As a long-term strategy, cloud services will become generic, like choosing an energy or communications supplier. However, there are challenges to overcome, in order to make multi-cloud truly practical and useful.

Brokerage – services need to be advertised and rated against each other. Is Google cheaper for 100 short-term instances than AWS, for example? These calculations will constantly change over time, making decisions very fluid.
Data Mobility – where is data located? Can I easily access it via one cloud or another? Is there a time/cost associated with moving the data to a cloud/service?
Cost Management – how am I being charged? Does it make sense to move workloads to another provider? Do the marginal savings make up for the effort of migration?
Avoiding Lock-in – every IT solution creates some kind of lock-in, but the degree of “stickiness” of some services is more than others. Understanding and minimising or reducing the impact of lock-in is generally a “good thing”.

Some of the potential cost calculations needed to either initially place or move a workload between cloud providers could be very complex. Only those IT organisations operating at scale will see the benefits of having full service brokerage. Achieving this also means considering the issues of data mobility and implementing solutions that abstract the actual location. Abstraction could mean implementing a distributed file system, keeping multiple in-sync copies or application-based replication.

The Architect’s View

Like many things, IT is inherently cyclical. Cloud is currently in the uptake cycle, with adoption growing rapidly. With maturity, IT organisations will see the benefits and pitfalls of having a single cloud provider, just as they did with multiple infrastructure providers. Where the cost/benefit ratio makes it worthwhile, multi-cloud and then brokerage will be a common deployment model. There are still challenges along the way however, start-ups are resolving many issues. This was more than clear at AWS re:Invent in December 2017.

What do you think? Where are you on the multi-cloud journey? Do you think the idea of running brokerage is practical or even possible? As usual we’d love to hear your views.

The Four Stages of Cloud Adoption

Stage 1 – Private Cloud

Stage 2 – Single Public Cloud

Stage 3 – Multi-Cloud

Stage 4 – Multi-Cloud Brokerage

The Architect’s View

Further Reading