Cloud 1.0, 2.0, and 3.0: The 3 Phases of Cloud Adoption

Armon Dadgar lists all of the attributes of the Cloud 1.0, 2.0, and 3.0 adoption phases in this whiteboard video.

»Transcript

Hello and welcome. Today, I want to spend a little time talking about the phases of cloud adoption. As you'd imagine at HashiCorp, we've seen everything from the good, the bad and the ugly in terms of how organizations go about adopting cloud.

But ultimately, I think we've seen enough different patterns that we've almost been able to simplify into what we call a cloud 1.0, 2.0, and 3.0 framework in terms of how we see most organizations adopting cloud. 

I want to spend a bit of time talking about that framework and the different signs and approaches we see within each of those 1.0, 2.0, and 3.0 phases of cloud adoption.

»Starting Your Cloud Journey: Cloud 1.0

Where we see most people start their cloud journey is in what I'll call the 1.0 motion. In cloud 1.0, most organizations start by realizing, "Hey, we have a critical need to start innovating more rapidly on our applications. Time to market is more important to us. So, how do we start to embrace cloud as part of our digital transformation?"

It's a focus on improving agility of our development teams, enabling teams to deliver applications faster and more easily. Typically, that becomes the starting point — the catalyst for an organization to start with cloud.

I think where most people start then is by saying, "Great. Let's go to one of our preferred cloud partners. We're going to sign an enterprise agreement with them. Maybe we commit several million dollars in spend to them. And then great, we're going to give those keys to our development teams and allow them to start building applications directly on cloud."

In this first phase, it's usually driven by the business need, which is, how do we go faster? How do we enable our digital transformation? We light that up by signing an agreement with one of the major cloud providers. And then we give access and credentials to our development teams and service teams and say, "Hey, knock yourself out. Go start building applications in cloud."

Almost invariably, the challenge ends up being in this 1.0 motion that we've created a bit of a wild west scenario. We've given keys, we've given credentials, and we've given it to our applications and said, "Go run free, do whatever you want." Almost inevitably, 12 months, 18 months later, you end up with a number of problems.

You now have things like account and resource sprawl, because each of these teams are running free and doing whatever they want. You have no consistency of approach. Each of these application teams is provisioning accounts in different ways, they're managing VPCs in different ways.

There are no real shared patterns or blueprints in terms of how people are building and defining and managing infrastructure. Typically, a result of that is you end up with a number of problems. One is cost overruns because you've opened up the floodgates and said, "Go free."

The second is you usually end up with a number of security and compliance challenges. The reason for that is, oftentimes, there's a divide in most organizations between who cares and is responsible for those things. 

Typically, a central security team or central compliance teams own and manage that. But in this model, we open up the floodgates, give credentials to the app teams, and tell them to run free. Those application teams are more focused on adding features — delivering capabilities — than they are necessarily on the security and compliance requirements of an organization.

Oftentimes what ends up happening is 12-18 months into what we call this cloud 1.0 approach, these issues come to the front. And all of a sudden, we see either the CIO organization or the CISO organization say, "Pause — we need to re-evaluate our strategy to cloud because we're creating chaos.”

We have 50 app teams doing things 50 different ways. We don't have proper security controls, cost controls, policy guardrails. It's the wild west. Oftentimes organizations hit pause on this and say how do we rethink our approach to cloud? Instead, we need to be much more intentional.

»Putting A Platform Layer In Place: Cloud 2.0

This often gets to what we call a 2.0 notion of thinking about the cloud.  Rather than let every application team directly interface and do whatever they want, it's how do we be slightly more measured and say great, we still want to enable cloud, but we want to put a consistent platform layer in place.

This platform layer will then give us an opinionated way of how we're interfacing and consuming cloud. It gives us an aperture for how we now define consistent ways of defining, deploying, and managing infrastructure. It allows us to manage our cost and put proper guardrails in place. It allows us to have a single point that we're imposing common security controls, compliance controls, ensuring we have visibility.

In short, it's about being intentional about how we're consuming cloud and trying to recognize that once I have 50 or 100 app teams doing it, I want to have a consistent set of ways of doing it, so I'm not managing it in 100 unique ways.

This introduction of a platform team usually then becomes the aperture through which we start consuming cloud. Then, great, all of those application teams become internal customers of this platform team. 

Some organizations that are very mature and platform-based to begin with might start their cloud journey here because they're used to having a strong platform-led approach to infrastructure.

For many organizations that are not used to a strong platform, they might start with this 1.0 motion, run into some of these challenges, then recognize the need to define either a platform team or sometimes a DevOps team, an SRE team. 

You see it's called by many different names and might be a Cloud Center of Excellence. But effectively, it's this idea that we're going to create a single group of platform owners. Their job is to build and maintain this layer. Then I'm going to have many different teams — these are the application teams, versus the platform or the ops teams — who are going to own this central layer.

Then this starts to allow us to address these pieces, which is how do we define some common patterns? If every one of these application teams needs to deploy a Mongo database, I don't want to do it in 50 different ways.

I want a consistent way that I'm doing that so I can put the right policy and controls around it, and I only have to manage it one time. That becomes a key part of this — which is from a security and compliance perspective — can I do it in a centralized way?

But then, ultimately, it's about thinking about how am I scaling this out to many different app teams? Which is ultimately a question of how do I get leverage at scale? Because in this approach, generally, in any given organization, there are a handful of very sophisticated, mature teams.

You can give them the Amazon credentials and say, "Go, run free." But then there's a long tail of teams that are not as mature. They're not as aware of how to manage cloud infrastructure, how to do DevOps, how to manage CI/CD pipelines.

When we think about this, it's not about how I service that 20% of my mature users, but the 80%, the long tail, that want a little bit more help — a little bit more opinionation — about how to do this.

»Gaining Maturity and Running Multi-Cloud: Cloud 3.0 

Then ultimately, I think once this model starts gaining maturity and traction, this tends to lead into what we call a 3.0 approach. A 3.0 is, in some sense, an extension of the work that's happening in 2.0.

Primarily, what starts to happen is once we've defined that central platform — and that's become the aperture for all of our application teams to come in and consume — we've enabled this to work with our single public cloud, which is where we started our journey.

But then this becomes the same vehicle to enable us to do multi-cloud effectively. And I think the ultimate extension of this is starting to recognize why can't we apply these same practices to our private datacenter?

What starts completing the journey is when people start to realize, we’ve enabled our ability to automate and get that DevOps ability to enable self-serve for our users. We accomplished self-serve at scale because now we're getting the leverage of many different application teams sharing this platform.

Often as part of that, we're adopting cloud ways of working. Typically, these platforms are introducing concepts like CI/CD. They're introducing infrastructure as code. They might be enabling a shift to Kubernetes and containerized-based ways of deploying applications.

Then the question becomes, why can't I get all those same benefits in my private datacenter environment? And the answer is, you can. I mean, cloud is more about a way of working rather than where you're working. Many of those same principles — whether we talk about CI/CD or infrastructure as code — can all be applied to a private datacenter environment.

At full maturity, when organizations get to this 3.0,it’s about extending it and saying we have a common platform approach now that spans our multi-cloud efforts as well as our private datacenter efforts. 

The goal being that I'm shielding my underlying application teams — my service teams — from having to be an expert in understanding the nuances of the different environments or whether it's public or private cloud. They want to focus on building and deploying their applications. 

»How Does This Link With HashiCorp Tooling? 

Overlaying this with a conversation about HashiCorp and our tooling: Oftentimes, organizations start adopting our open source in the 1.0 motion. Development teams might pick up tools like Terraform to start provisioning infrastructure, Vault to manage secrets and put it in their CI/CD pipelines.

Maybe they're using Consul to enable discovery between their different applications. Most of the time, organizations start with our open source here, and it's development and app teams pulling it in, using it, solving their problem, and for running as fast as they can.

As we move into the 2.0 framework and the 3.0 framework, that tends to be the transition for us into more of our commercial tool offerings. It's a focus on how we enable these platform teams to offer all of our products as a service to their customers — the underlying app teams. 

Now what we care about is how do I enable multi-tenancy? Because I have many different tenants on these shared platforms. Oftentimes I care about — if it's a core platform — am I building in the right level of high availability, disaster recovery?Am I hardening this into a tier-one service internally where I'm then offering and enabling it to many, many app teams internally? Now I care much more about building an HA — a high availability —platform. 

Then lastly, it's around things like, how do I enable common patterns? That might be things like using Terraform Private Registry. How do I enable security controls and compliance controls? That might be leveraging some of our policy as code capabilities. 

Some of the governance capabilities certainly include things like single sign-on, role-based access control, where we want to be thinking about how I build this platform such that I'm gaining that leverage, then imposing the right policy and governance, balso enabling it in a multi-tenant way.

I don't want to manage a bespoke platform — one instance of it for every one of my tenants. That doesn't scale if I have to support hundreds of app teams. Then, as we come to this world, it's about leveraging the tooling to create a consistent approach across multi-cloud and private datacenters.

This is where HashiCorp tools shine — when we talk about a tool like Terraform, great, it's the same underlying workflow, whether I'm deploying it to Amazon, Google, Azure or my on-premises environment. 

Vault — same thing. I have one set of APIs, one workflow around how I'm doing secret and key management, but I can integrate it and apply it across all these environments in a consistent way.

Consul — same thing. How do I enable service networking and discovery across all of this? How do I normalize my ability to do micro-segmentation and govern access of an application in cloud, talking to an application on-premises? We can start normalizing all of that.

That becomes the transition for us from a HashiCorp perspective, where we tend to start with organizations they're using our open source in a tactical cloud in the 1.0. And as they move into a more mature intentional design around 2.0 and 3.0, that becomes a commercial conversation around how to use the enterprise version of the products to enable their application teams at scale.

Hopefully, this was helpful in terms of the patterns we see as organizations go from tactical cloud adoption to enabling cloud as a strategic platform. And then moving from that, from a single cloud into a multi or hybrid cloud pattern. 

Thanks so much.