 Welcome and thank you so much for joining us here at GitLab. We're going to walk you through today the evolution of the Kubernetes landscape. Context-wise, my name is Brandon Young, I serve as the VP of alliances for GitLab. History-wise, I started my career at IBM, but the reason that is going to be the most interesting today is I spent most of the last 10 years at Google, and I was part of the team that helped launch Kubernetes. Joe Beta, Brandon Burns, Craig McClocky, and later Brian Gray and Tim Hawken have done all the hard work, but there was also a part of this is getting a bunch of partners, a bunch of contributors, and a larger number of other people on board, and that was really what my job was at Google. So I want to give you guys a little context, I think of how we got here. I currently also serve on the board of the Linux Foundation. So context, though, why GitLab, what are we doing in the space, and how are these kind of two related before we jump in to the entire landscape? So first off, GitLab and all of our funds started back with a focus on developer productivity. And to make it easy, I'm going to spend a lot of today running through and giving you guys some clear opportunities to look at this. We're a single DevOps tool, not a chain, focused on allowing developers to focus on what they really want to do, which is develop the code, and deploy it into Kubernetes, can deploy anywhere, but we're going to focus clearly on Kubernetes for most of today. I give you a context of what we do, we focus all the way from planning and what you want to run through how you store and run that in source code management, how you package it up in a container registry, how you secure that in your CI pipeline through your static code analysis, dynamic code analysis, license management, et cetera, and then help you in the deployment into the Kubernetes cluster. We also focus on making it really simple through a process we call Auto DevOps, which is an opinionated demo file that helps you ensure that your first deployments and your ongoing deployments into your Kubernetes cluster work phenomenally. So with that said, obviously we love Kubernetes because for developers, nothing's more important than a consistent deployment and a great environment as people are developing more and more applications, but obviously making them a much more polyglot environment. There's a whole bunch more needs microservices that these need to be solved. We spend a lot of time on that side, solving for Kubernetes and making it really easy to bring the dev and the ops side together. Additionally, we spend quite a bit of time and are moving into the serverless space. Same pattern that we brought before of making Kubernetes easily accessible for developers. We also focus on making now serverless easy and accessible to developers while doing that through a full managed solution that's critical for both the security and the speed. And then I think probably lastly spend a bit of time on security. These are areas I touched on briefly. You'll see all of the links at the top of my web browser so you can take a look at those anytime you would want. But with that said, why don't we jump into the landscape? Again, this is a landscape we still work to this day closely with just about every one of these partners in helping them get new workloads into their Kubernetes clusters. And so the pattern I wanted to do is send a little bit of overview on what this entire ecosystem currently looks like and you will see that here. And if you haven't taken a look, the CNCF has a great interactive landscape that covers a whole bunch of these. We're going to focus most of the time around the platform vendors today, but there's plenty of other places for you to dig in and learn quite a bit more about them. So that said, I'm going to start kind of in chronological order. So if we backtrack and kind of go back to the beginnings of where this all played out, everything and everyone relies on a huge investment from Docker. And when Docker first started, it was all about containerization. And there were a bunch of ideas out there before. So Google had a well named one called, let me containerify that for you. Thankfully, that was sunset in favor of Docker when they came out. And really, this was kind of the foundation that we've all built on. Now, one of the interesting things when Docker got started is they started with something called Swarm. If you're not yet familiar with it, Swarm was a very easy to get started, easy to run orchestration tool. And again, we'll be talking orchestration tools all day today with the primary focus on Kubernetes. It was really, again, back to Swarm. What Docker harnessed in Docker, they really extended into Swarm. So easy to approach, easy to get started. Over time, that evolved was got a lot of good support from Microsoft, good focus around Windows. But they did eventually, over time, Swarm was probably served by Kubernetes. And in true fashion, as everything's evolved, Docker's also evolved initially into what was called Kubernetes and Swarm mode. So you can run Kubernetes and Swarm next to each other. And to this day, you still can. And now they've evolved their offering into what is Docker Enterprise. And if you look here, Docker Enterprise is their fully managed solution that includes their Kubernetes service, but is also on top of Docker engine with Docker Hub, image repository and registry, a number of their dev tools, which they continue to do really well. That's kind of where they started and where they're headed now. Again, one of the very best in the business. Who else was out in the market before Kubernetes came in? And I'd be remiss if I didn't go and take a look and we didn't talk about Red Hat and particularly OpenShift. Now the interesting piece is OpenShift has been around for a while, full platform as a service, still in many ways operates as a platform as a service with a lot of additional value at on top of Kubernetes. But if you go back to OpenShift to Enterprise to, it was a very different product. And at that time, you'll see here, instead of containers, OpenShift use it gears. Instead of Kubernetes, they actually would have used, and I'm going to get this make sure I get this correct. Instead of orchestration, they used a broker. So an OpenShift broker host instead. Now, what Red Hat picked up really quickly when Kubernetes first came out is they made a very quick early bet that Kubernetes would be the best tool for doing the orchestration behind the scenes at OpenShift. And they made this bet before they really sure whether or not OpenShift or I'm sorry, whether Kubernetes was going to be the winner in this evolution. And so they did it though, simply believing it was the best tool to orchestrate a pass. As it turns out, they seems like they made a pretty good bet. They jumped in early and have been one of the very biggest contributors throughout all of the years. That said, their big transition from OpenShift two, which had again, as always, open source technologies, but shifting to Kubernetes and OpenShift three came out in June of 2015 and went GA. Now that's outstanding and they've continued to evolve. I want to give you a little bit of an idea of I think where we see them going, going forward. Now as they just released OpenShift four and they've moved on, what is most interesting for them is going to be around a couple pieces. Big one here is operator framework. We'll talk a bit about this, but an operator framework from the simplest of terms is allowing other ISVs and other software to run on top of Kubernetes. And it allows an operator framework what allows you not to just deploy an application to maintain it throughout its life cycle. There's been a number of other ways to do this. Helm is another common one, but it looks like probably operator framework is the one that certainly Red Hat's making a bet on a number of others are. Couple other things that they're focused on from a velocity standpoint is around serverless and they're serverless similar to a couple others are making a bet on was Knative. Knative allows serverless to run on top of Kubernetes cluster anywhere that you would want to do it. So great place there. Again, they made the shift early and they continue to run with it. I think one of the most important things though in the market right now that is being asked is what's going on with IBM. So what I wanted to do is give you guys a little bit of context. IBM before they bought Red Hat and then a little bit of maybe some guesses as to where I'm going to guess they're going to head now that they own Red Hat. So early on IBM made a big bet actually with another platform called Cloud Foundry. Cloud Foundry was also more of a pass and so you'll sale even to this day you'll see Cloud Foundry and OpenShift continue to be two of the probably most opinionated and best adopted passes in the market. IBM adopted and has been a big contributor to Cloud Foundry. Pivotler was the biggest. We'll get to them in a moment. They made a bet for that for the application development. You'll see here the part that Cloud Foundry did really well is something called CF push and it was command line deploy and push your application and it was transformative still is and makes it extremely easy to develop grow and continue to evolve. Now one of the areas that is really interesting and how they bridge the gap what you would end up with in Cloud Foundry is you end up with a completely different back end to Kubernetes. It uses something functionally no primarily around Bosch and Diego. Those are the two primary technologies for container runtime. Those are core to Cloud Foundry and IBM made that adoption of Cloud Foundry and Kubernetes. So they ended up with really two different platforms. In order to bring them together there's a project called Irini and this project is one that focuses on rebasing Cloud Foundry application runtime to run on top of Kubernetes. IBM was a big proponent of this along with SAP and SUSE who also are big contributors to both groups. So they contribute heavily to both Kubernetes and to Cloud Foundry. So this is actually something that's still in place going to continue evolve but works very well for someone that wants to have a consistent back end that they manage. You can imagine that works really well for IBM. Where are they going in the future? Well I think aside from the OpenShift question of what IBM does with OpenShift and how that fits, IBM actually has two primary offerings today of IBM Cloud Kubernetes Service. So this is a fully managed Kubernetes service that runs on their public cloud and the second one that they have is known as IBM Cloud Private. Now IBM Cloud Private is designed to run in your own data center. It's designed to run on your own hardware and it actually pulls together a couple frameworks. It's not just a Kubernetes cluster but that the previous piece that we looked at the work around Irini allowed them to run IBM Cloud Private on-prem and deliver all of the container love that they loved with Kubernetes and Cloud Foundry and run it on a single back end Kubernetes. And so that's certainly something that we expect they'll continue to do but it will be interesting to see how this fits in with OpenShift. A couple other quick things that I'd note that IBM's been big contributors to. A big investment for them in Istio for a service mesh. This is together with Google. A number of other people are also using it but those would be the two biggest. So those are good. Let me go a little bit back in time to cover what was going on and where Pivotal is. So historically Pivotal was very well known for Cloud Foundry still is. They're the primary contributor. They nail this. We use case there's hundreds of enterprise customers that have taken advantage of Cloud Foundry and everything that Pivotal brings. All of that is largely orchestrated and runs on top of Bosch. So let me give you a little color. Bosch is again that alternative Bosch to be overly simple. Naming is pretty interesting. It came from a combination of Borg which is Google's scheduler and also was the grandfather to Kubernetes combined with SSH. So Bosch is half-forged, half the simple of the SSH and you're off and running. It continues to be the foundation of their Kubernetes offering. Pivotal runs what is known as PKS on top of Bosch. Runs in conjunction with Harbor which is a container registry and then tightly coupled together with NSXT from VMware their parent company. So a lot of really good work there on the networking side which is one of the more complex pieces to solve when you get into a Kubernetes distribution. Now with that said, it can run anywhere. That's obviously one of the big value propositions to Red Hat with OpenShift with Pivotal with Cloud Foundry and their PKS offering. Their PKS offering is designed to really meet people anywhere you come from. So they really have three offerings, something that is called essential PKS that comes out of Heptio and we'll talk about that a little bit when I get to VMware. The Enterprise PKS which is a descendant of a project called Kubo which came from Kubernetes plus Bosch. So we'll put those together. Kubo is now what is known as Enterprise PKS which can also run on a public cloud on your VMware public cloud and would be called Cloud PKS. So we'll hit on a couple of those. I think in the future it's going to be really interesting to see where Pivotal and VMware continue to evolve. They've really hardened and brought some really good unique viewpoints to the Kubernetes space, continue to contribute very highly. They also bring a lot of what you need to run in your own data center and obviously VMware is very strong there and Pivotal knows how to develop better than anyone in the business. So those are the worlds you came through but we are missing one that's really important to bring to the table and that is Mesosphere. So again all of this happened these technologies existed before Kubernetes was here and it's another orchestrator orchestration tool which was Apache Mesos. Now Apache Mesos was evolved by Mesosphere into what they're offering is even today known as Mesos for DCOS or Data Center Operating System. The strength of DCOS is it's a two level scheduler. We gained nuances that some other time but the important to know about this is Mesosphere built their orchestration predominantly around data and not a surprise. If you look there anything that's really an Apache project has been something that Mesosphere has done, operates and maintained extremely well and you'll see that even here in their literature with the focus on the data science that said a lot of the application areas the application development has moved more to a cloud native in this case Kubernetes and they've come out with a strong Mesosphere Kubernetes engine. Value on this continues to be a customer the most customers run Mesosphere and DCOS as it's known in their own data center and what this delivers is a universal orchestrator universal scheduler for all of your large big data workloads as well as Kubernetes all running on top of it and so that's very useful for their customers in that use case. They continue to expand and deliver on a lot of it give you a sense obviously the places that they might run and you can dig into a bit more around Mesosphere Kubernetes engine obviously on all of the links so that brings us to the beginning of Kubernetes and I thought it'd just be fun to take a quick look at the first commit ever on June 6, 2014 by Joe Beta into the Kubernetes project and so he started it started very simple the externalization this was very simple Google was looking and ran and always still runs everything in a container including their VMs running containers just for fun so it's as everyone likes to say turtles all the way down but Google needed an answer to what was going on in the marketplace particularly with Amazon that had a very strong messaging and the world completely consolidated around EC2 and VMs and so they came out with Kubernetes they contributed very heavily into Docker and making sure that that was supported but they had some opinions because of Borg on what a scheduler really needed to be able to deliver and so a lot of that is really good stewards that founding teams stewarded it really well but it really this is kind of the first first place that they would have would have started that said about a year later on the one-year anniversary of Kubernetes we got what we now know as CNCF so CNCF's first project and donation that was put in it was the Kubernetes project was put in there by Google a whole bunch of other great founding members that joined it well at the beginning and that was the goal is to get Kubernetes out from a specific company and into what we now know as a foundation for what we've now seen from CNCF which is is pretty truly impressive in terms of where it's grown and it's been pretty amazing ride to watch each kubecon grow but also all the different use cases all the fascinating people that have jumped in to make sure that this runs as well as it possibly can so from that though Google jumped in and focused on commercializing it and they commercialize it first as what is GKE that evolved into Anthos but GKE was definitely the first managed Kubernetes out there it's one that continues to be industry leading in both its capabilities and now where it runs and so Google took a step about two years ago into initially was what's called GKE on-prem it's now involved into what is known as the Anthos platform and Anthos can run anywhere. Anthos can run your workload in GKE if you want to run it on Google on GCP but it can run on-prem in your VMware environment and it can run on other public clouds as well. This continues to be a place that I think Google is going to push the boundaries of how to bring what is really now a very diverse CNCF ecosystem together in a way that it's easy it's managed it runs anywhere and so we'll see this is going to be a really interesting point naturally this brought bluntly Google into a very direct competition with what is now Red Hat and IBM for the value proposition of be able to take your workload that workload portability across any public cloud and anywhere on-prem so I think we'll see a number of people competing here but this is one to look for and certainly they've done an excellent job across the board that said I think the other player another player here is going to be Amazon we know today Amazon has a great Kubernetes offering in EKS but they didn't start with that so when Docker first came out Amazon jumped in because of their very strong customer focus in making it easy to run containers and so even really before I think you'd say even really before Swarm and as Swarm and Kubernetes were getting started ECS was launched and ECS was simply a very easy way to run whatever you've containerized so it doesn't run anywhere but Amazon but it is deeply integrated as you can see here into the identity access management all their cloud watch events cloud formation cloud trail so if you're in Amazon this is a really good way to run your container services however over time it became very clear that Amazon also needed to support Kubernetes and so they made as they always do in listening to the customers hey time to jump in and really invest in making Kubernetes work as a fully managed service on top of Amazon now I love what they're doing I think there's some other really fun stuff you could jump in in and if you haven't picked this up Amazon has open sourced their container roadmap and this covers ECS which we just chatted about also covers EKS and so I would strongly encourage you if you're looking to jump in to look at their container roadmap look at where they are developing make those comments big big fan of where the entire team Deepak, Bob Wise and their team are all headed on this side that said we should also make sure we don't miss Microsoft I think Microsoft's taken a fascinating way of getting here if we go back Microsoft has actually worked with all of the above container orchestration tools that we've talked about so they started out early on supporting Mesa sort DCS on Azure as a fully managed service that was really their first direction that they went when as Docker came out with swarm jumped on the bandwagon did a really good job of helping make sure that Docker swarm ran well on Azure however those have all evolved and as Amazon as Azure rolled out what is AKS or Azure Kubernetes service they've moved to sunset those other orchestrators so at this point Azure has now shifted to Kubernetes being there also primary focus around container orchestration so it'll be interesting to see is that that moves forward the big focus on this as it was before with Docker is around getting windows into the Kubernetes environment so I think we continue to look forward to them making those contributions and making Kubernetes work great with windows and they did that great obviously first time through with Docker and the foundational pieces that were necessary look forward to them continue to do that with the Kubernetes space so with that and here a quick link to you're welcome to go take a look at AKS want to hit a few other ones that I think are interesting first off I think fascinating where VMware stands VMware is where they are both through all the work that they do with Pivotal and what you got with his pks they also acquired Heptio so Heptio was an independent company founded by Joe Beta and Craig McClocky two of the founders split off and started his new company Heptio was acquired recently by VMware and they're hard at work in integrating and bringing Kubernetes to the enterprise at all the places that VMware runs we're going to be watching that real carefully but again lots to be seen there but I think VMware is getting real serious about about this space so another area will kick off and this is almost a backtrack because it might not even be known so hopefully Rancher will appreciate the fact they started originally when this all came out with a platform called cattle now Rancher picked up extremely early on that the importance of orchestration was pretty complex and they made a quick and robust shift over to being a centralized tool for managing any of your Kubernetes clusters as it turns out there's a couple other really great things I want to call out for that they're doing not only a great independent pure Kubernetes player I think their model is fascinating I'm biased I love their open core model so real easy for anyone to get started with Rancher and then as you mature you can pick up the additional support and some of the additional features but it's real easy to get started and run Kubernetes anywhere you want to they're also really heavily involved in making sure it can run anywhere a great project they just launched which is k3s so if you're not familiar with it Kates is Kubernetes is k eight letters and s k3s doesn't mean anything I don't know what the three letters are in the middle but it's a very like Kubernetes distro and allows it to run just about anywhere I'll look forward to that because certainly Kubernetes on the edge is another area we're starting to see it so with that said one last one and a new entry into the space for managed is digital ocean they always do a great job for developers and let's be honest hey anyone and or no one ever gets tired of the awesome droplets that they deliver they focus ease of use for anyone to get up and running so that was a quick flyby one last little piece here that is worth a fun read to see how these come together and it is here this is a use case from the cncf that uses gitlab and I will zoom in here for you all to what is a very interesting picture and this is actually what the cncf has done is in order to test all of the graduated projects against all the different providers which you'll see on the in the in the columns against the projects in the rows they leverage gitlab to do that ci cd and the testing to make sure they were tested they ran etc and so interesting use case here on what we're doing with a lot of the different groups and right down to the core cncf and helping make sure that the code that is written is well tested is well secured and everyone gets to move even faster so these are some of the important places we continue to work with the cncf that said so much appreciate y'all's time please um take a little bit of time come visit our virtual booth in the exhibition hall for a deeper dive into what we're doing with kubernetes and how we can help you get started no matter where it is in the entire cncf and kubernetes ecosystem that you want to get started so with that thank you and have a great day