Cloud Native development keeps growing so assessing your software development efforts to understand the benefits of moving to the Cloud is more relevant than ever. Jordi Mon, Senior Product Marketing Manager at GitLab talks about MultiCloud Maturity.
Welcome to DevOps Sauna. My name is Lauri and I am the Chief Marketing Officer of Eficode. Not too long ago, we held a hugely popular two-day DevOps 2020 event. In the event, we had awesome speakers from around the world telling stories about DevOps tools and culture for over a thousand people online. Since then, we have made these recordings available at the Eficode website and due to the popularity of the speeches, we have now made them also available in our podcast.
You can find the links to the video recording and to the materials referred in the speech in the show notes. We're also keen to feature topics that you find interesting in the area of DevOps. Do let us hear about you in our Twitter, Facebook, or LinkedIn pages. Today, we are going to hear Jordi Mon from GitLab. He's a Senior Product Manager and he talks about multi-cloud maturity model. I'm not going to stand in your way so let's dive right into the speech.
Welcome to my talk about the multi-cloud maturity model. Basically, I'm going to present how we at GitLab see this shifting and ever evolving, and expansive world, and market, and sector of multi-cloud, or the cloud, the public cloud rather. And hopefully you agree or disagree and talk about it.
My name is Jordi Mon. I work for GitLab. I'm a Senior Product Manager here at GitLab. I'm in London, the UK. And as you know, we are a distributed company. So, we are all over the world. Before we jump in, let's just define what it is and it's obviously a pretty easy definition, but just to get academic. Wikipedia defines it as such; the ability to, with a single heterogeneous architecture, deploy it to multiple cloud providers, leveraging the primitives that each one of those, and the services built on top that each one of those providers are offering us to date.
So, basically that's what it means. Leveraging multiple cloud providers in a way. The landscape is ever growing as I said. I'll share some numbers now, although who knows if in the future things change, but I actually will only accelerate the expansion of this market, but I'm not an analyst and I'm not here to talk about the future, but rather the past and the present. And a bit of the near future, as we say.
Basically there was no public cloud as such before 2006. It was 2006 when this market was created through... AWS was the actual, let's say, the agent in this market that provided product market fit. Amazon, through AWS, and then all the big ones joined. And there's plenty more actors than you see in this slide, but these are the main ones. So, the market is already validated and expanded. And it's full of competitors, so it's a very healthy market, although people would argue that even more competitors are required in this space.
The numbers are pretty breathtaking. These numbers are taken from this study by Teixeira from earlier last year, so they probably have changed, but it gives us an idea of how big the market is growing. The public cloud market, 24% over a year. And the good thing is that the demand side of this market, so that 24% is about the offering side, the supply side of the market, but the demand side of the market, most of the enterprises, 87% of them, have already a multi-cloud strategy in place, which is good news.
As you'll see later, most of them fall into the middle maturity or average maturity stage that we've developed in our model, which is good news, right? Now most of the market, of the demand side of the market, is in a certain maturity phase. It's not in the initial ones. Another number might come from not only a vendor, like in this case previously, but rather an analyst, an independent one, a famous, popular one, Forrester, who actually I think...
These numbers are, by the way, in November 2019. So, maybe a reassessment of them now is worth given all this, or actually after all this is over, but still I would argue they are more or less valid to convey the idea that it's growing in the billions. In fact, 300. And also another idea that this study conveys is that open source is a catalyst of all this growth. And I explain that further on. So, the reasons behind pushing and incentivizing enterprises to have a multi-cloud strategy, which is after all what we are here for, are several, right?
The different providers have different technologies and services that others don't provide. An example of which would be DynamoDB, or Lambda, being offered exclusively by AWS. BigQuery in the case of GCP and so on. There are plenty of examples. So, if you're dependent on those services, you'd rather be on that cloud, or not actually. If you're an enterprise and you're negotiating prices, or contract renewals, with your current public cloud provider, then you probably have the upper hand if you have other quotes, other possibilities there, so that you're not stuck into a tyrannical renewal contract, or a price hike, in any case.
So, it is a sane and reasonable thing to do. But also if you're not thinking of renewing or purchasing a new environment, a new cloud, there's chances that either you will grow by merging, or acquisition of teams and companies, or might be hiring a team, or even your own teams will be integrating your services and your applications as a software developer with other teams. And they might also be running their applications in different clouds than yours.
So, therefore, again, the most sane proposition for that to happen is that you have visibility at least on what's going on in the rest of the clouds, because these scenarios that I just described may just happen and you better be prepared. There's also several other reasons, but obviously these are the main ones that we at least see in what motivates our clients and enterprises in general to have a multi-cloud strategy. The last one was, one I would like to highlight, is open source, right?
Open source is proving to be the most prevalent distribution model in the infrastructure software. It is running the cloud and the public clouds that is powering and provisioning the software that is eventually consumed. So, given this, examples of this are Apache Kafka, Redis, Elastic, and so on. We might see also that the future management layer on top of these projects will also be open source.
So, it will definitely help for the leaders of the future to assess a multi-cloud reality. Right? The advantage is pretty clear when open source is there. And one of the main examples would be Kubernetes, right? It is after all the great equalizer. If this becomes the de facto deployment paradigm, development and deployment paradigm, it will become the great equalizer. And it seems so, right? It seems like most of the public cloud providers are standardizing on it in a way.
It is loved after all by developers and operations. It is more or less accepted by everyone that it's the best way to deploy and operate containerized applications. And, well, it will provide if so a common interface to cloud providers. So, let's go then into the levels of a multi-cloud adoption, or the different levels of the maturity model. Going back a little bit again in the past, the least mature of companies are maybe thinking of moving their application, or the software, the packaged software, from the old data centers, or of their own environments, into one single public cloud, or even one private cloud.
Moving onto the next one, you soon realize as a software developer that you may have teams working in different clouds and therefore the workflow, the way in which you develop software, or the teams you manage, are completely adapted to one cloud and therefore it is absolutely customized to it. And you cannot move it or port it to another cloud, which is not ideal. It's better than the mode of the previous phase, but it is definitely not the most ideal phase, which would be actually the next one in which your workflows, the way you develop software, the methodologies you have in place, the structure of your teams, and the architecture of your software is thought for multiple clouds.
It requires knowledge of the different infrastructures and it requires plenty of things, but it is the same way to develop. That's why we would argue DevOps is on the rise, right? It is, if you wish, a philosophy, a methodology that puts the infrastructure, or the technology, or the tooling behind, before processes and people. And that would definitely provide you, as a software developer, with workflows that are agnostic to the different providers. This phase is in which we argue most of the people are, the phase I just mentioned, most of the enterprises, but the next one would be application portability in which in my packaged software, the one I make revenue from, the one I devote most of our resources, and the one I believe in the mission, and so on and so forth, it is actually portable between the different clouds.
It could be run in any given cloud. It is independent of not only the primitives, but also the services that each one of those clouds are running. Once that phase is achieved, you's rather have a plan, not only a plan, but the technology that enables it and activates the disaster recovery portability in which a fail over plan in which once that application is able to run in different cloud private providers, then the load balancing and the disaster recovery instructions are therefore to limit to the minimal the potential downtime in one of each class, in one of the clouds that the end user is consuming.
A more evolved phase of this would be that the actual workloads, or the components of that applications, are able to run in different clouds. In our case, in the case of GitLab for example, gitlab.com, we had workload portability for our CI workloads. So, the end user would not suffer any downtime, because CI workflows would run on the place that is available every time and the fastest, and so on. The most evolved material phase of multi-cloud strategy for enterprises would be the ability to synchronize the data, that applications are synchronized through the multi-cloud scenario, right?
In which, whenever that the downtime comes, or the ability to load any traffic or users to the same application in another cloud, that consistency is maintained, right? Because there's data synchronicity between the same application in different clouds. Basically if we go through it, that is how we see our clients and their market, and the demand side of the market, in the public cloud market, evolving. Most of them, as I mentioned, are around the application portability phase. We are showing their path to actually move forward in maturity levels.
That is all from my side. My call to action, if any, would be that people attending DevOps 2020 will share actually their way, or your way, to maturity on regards to a multi-cloud provisioning and multi-cloud strategy in general. And we come together and actually share that knowledge, because it's a complex and ever growing, ever expanding market full of new open source technologies. We will all be better together if we share this knowledge going to the public cloud, which seems to be one of the best options out there. Let's move on to the questions.
Can you share an example from GitLab in multi-cloud? Well, the one I just mentioned. I'm not sure by the way. We're a very, very fast company. We change pretty fast. We're a distributed team and it's one of the cons, if you wish, of being a distributed company is that it's difficult to get a hold of many of the things that are happening, which is fine if you actually have the premium on velocity, which is actually one of our missions.
But, yeah, the example I just shared about having our CI workloads being agnostic of any specific cloud provider and us, as a service provider in gitlab.com, choosing the best infrastructure for each one of the different clients. So, that is a clear example of how having a workload agnostic of, or adapted to, all the different cloud providers, public cloud providers, is a benefit for the end user and after all for the company providing the software.
That was a snappy and fact packed presentation. Thanks, Jordi. Next time around, we will listen to Jeff Williams from Contrast Security. He's a co-founder and CTO of the company, and will go practical about the security instrumentation. If you have ever stumbled upon the term DevSecOps, this will be for you. Talk to you again next time. Until then, remember to share your strategies to be successful with multi-cloud.