 Well, thank you everyone for coming really appreciate it. That's our first workshop session. We'll try to keep it brief I'm gonna have a great period for questions and answers at the end and we'll dive into a bunch of stuff So I won't kill you with the slides for too long, but hopefully gonna give you some context to Kubernetes First context on who I am if you don't know my name is Brennan O'Leary, and I'm from Annapolis, Maryland here in the States Born and raised in Maryland. I mean what we're gonna talk about is a few things, right? We're gonna talk about what Kubernetes is, but I think more importantly I think the context that really helps when talking to customers about it is like why is Kubernetes? And then we'll go into some Kubernetes terminology. So that's as kind of deep as we'll get We're not gonna do a lot of hands-on stuff in this session The slides will be available and there's a hands-on tutorial there, but this is mostly just gonna be let's talk about it Let's give context, and then let's get questions answered and we've got a couple fun stuff fun things because it's me So first off, you know, what what is Kubernetes, right? And so you'll hear it called a lot of different things you'll hear people say well It's a container scheduler. You'll hear people say it's a desired state manager You know people say it's an orchestrator, right? All these things just basically boiled down to it's a system that keeps the system how we want it to be which Sounds kind of crazy, but when we're a software company for software companies, you can you know relate a little bit, right? And so Like let's talk to kind of understand where more is what it is more Let's talk a little bit about where GitLab and Kubernetes meet, right? So when I'm talking to folks One of the things I say is before I came to GitLab. I came to GitLab in 2017 and before I did the only Executives of any company I heard talking about Kubernetes were our VP of product and said our CEO And so there's a number of touch points. We've been kind of all in on Kubernetes for a while So one is of course, you can run GitLab on Kubernetes because Kubernetes. I mean GitLab is an application So we allow you to deploy GitLab to your Kubernetes cluster if that's where you want to run GitLab and that could help you if you're already running other things on Kubernetes It's a great way to keep apps alive and running and highly available And so it might make sense to run GitLab in your Kubernetes cluster And so things will hear about and we'll talk more in detail later Are like helm charts, right? So we publish a helm chart. It's basically a descriptive way of saying here This is how you install GitLab into a Kubernetes cluster But the other and perhaps more important place that like GitLab and Kubernetes intersect is GitLab's ability to interface and interact and integrate with Kubernetes itself For deploying the apps that our customers are writing and storing in GitLab, right? So you store your source code in GitLab you're probably you might hopefully of course I'm gonna be biased, but hopefully you're doing your CI and GitLab and then with the GitLab Kubernetes integration that we have a whole team in the configure team dedicated to You can deploy that app automatically So all the great things we talk about in autodevops like automatic review apps The ability to run sass and desks automatically that all basically relies on hey if we're connected to a Kubernetes cluster we know how to deploy your app and So that's really where GitLab and we'll talk in more detail about it later Comes into play when it's when I want to deploy all of my applications. I'm writing into Kubernetes So it's a two different two different touch points and we'll go into more detail. Oh And of course I don't have my slides up So yes using Kubernetes to run GitLab as application or using Kim and oh and then also the third touch point is We are working on moving our production system GitLab calm into a Kubernetes cluster So we recently as you may remember have heard moved our infrastructure from Microsoft Azure to Google cloud platform and the reason one of the main reasons for that was We want to run GitLab calm at the scale that it is inside of a Kubernetes cluster so that's able to scale and and keep up with demand even better than it is today and GCP has kind of been on the forefront of running Kubernetes in the cloud and so that's why we chose chose to go that way So we're not running it yet We're talking about which pieces of infrastructure first go into Kubernetes But but that's another way and then of course like I said that can be a platform to run your applications on Kubernetes And we'll talk a little bit more about that So to kind of answer the question like why is Kubernetes? I want to do a little like history lesson through deploying applications right if you're software to well first on Kubernetes and then through deploying applications, so So Kubernetes originated at Google when you're a software developer and you want to deploy an application There's a system called Borg And this system basically is agnostic to you the developer as to where the hardware is what kind of hardware there is How much hardware there is you just say I've got a new mail app that I wrote calling a Gmail And I want it to run on 10,000 servers globally distributed and Borg just goes and figures it out and does it Right, so the infrastructure team at Google Enables their developers to deploy as fast as they do through Borg So that's a closed source inside Google solution but in 2015 Some Google engineers started a project called project seven to create an open source version of Borg in ways it's not exactly Borg but they took everything they learned from Borg and the stuff that they were okay making open source and created this open source project called project seven and Then that at the end or summer of 2015 evolved into what became version 1.0 of Kubernetes right so now it's known as kubernetes And that was then there was in a foundation created the CNCF you'll hear that a lot cloud native Computing foundation that was founded by Google and the Linux Foundation together in order to house kubernetes And now it houses lots and lots of projects and incubates even more Then this is what I was kind of talking about Earlier in 2016 I've put the dark ages here or and I've got a picture of beta max And so what this was is at the same time? Docker Who is a company around Docker containers had a project called Docker swarm? And it was kind of this who's gonna win between Docker swarm and kubernetes Everybody's talking about it and then as I said earlier you could hear lots of folks debating it on hacker news or You know forums and engineers debating the merits of both But the only folks that I saw this I wasn't a git lab yet And the only folks I saw really talking about it seriously at an executive level were ours I was a git lab customer at the time so I would watch videos that we posted and Said was convinced kubernetes is the future where we're gonna be all in on that and It was at the 20s end of 2017 that we were kind of and he was kind of Vindicated because you can kind of see 2017 is when beta max of Docker swarm goes away and the VHS of kubernetes wins because Amazon goes all in comes up with Eks their version of running kubernetes in the cloud Our Azure comes out with a KS and actually the thing I used to point out to folks I'm not sure if it's true anymore, but if you went to docker.io It said kubernetes. I said if you needed any more proof The kubernetes one over Docker swarm. It's that when you go to docker.io The first thing you see is hey, you can run Docker and kubernetes and so That was critical because that was an open source project winning right like Docker swarm I actually don't know it may have had an open source component anybody knows I don't know if it did or did not but it was you know It was mostly a platform for them to sell as part of their commercial offering And so that's a big reason that kubernetes ended up winning that and Then here I pointed out if you can read it that kubernetes is from Greek It means helmsman or pilot that's why you see kind of like a helm logo and you see a lot of ship Right, it's a lot about ships And so let's talk a little bit more about why we wanted to go down this road And so the reason I want to talk about it is because I think if you know the why behind kubernetes It becomes a lot more obvious why a lot of our customers are talking about it why people seem excited about it Even though it's kind of still up in the air as to how it works So let's talk about if you wanted to deploy an application, right? You write some software you've checked in to get lab and you want to deploy it so that people can use it You know the original version of that was okay You've got a computer a bear you might hear people say bare metal meaning just a computer and that computer has the kernel and the Libraries that are on top of it and then you put your apps on it, right? And so this is where Technology is like puppet and chef are really great at hey I've got a bunch of computers out here like put my apps He put this app here put this app here and you figure out where you're going to deploy everything Then after that came in an abstraction away from that model called virtual machines, right? And so a virtual machine actually takes one physical computer and breaks it into multiple entire computers Virtually right so it's not a real computer But it's for all intents and purposes it is because it has the whole kernel all the libraries and can have all your apps in it, right? So then the next abstraction that came was the idea of containers, right? So why do we need a copy of the operating system? Every time on the same computer, right? That's that's what a virtual machine is copy the operating system copy the operating system on every virtual machine that's running So the container takes that away says just run one operating system at the computer level Put Docker or there's other container technologies on top and you can have a container that just contains the library and the app You want to build so I'm saying library It could be things like, you know Java or node right the things that we're building the app with the problem with this is You start to get away from what a human can kind of understand right? It's kind of easy to understand like that computer is my email server and that computer is running my web app And that computer is running my point of sale app But very quickly now we've got all these abstractions in place and it's kind of hard to understand like where is stuff, right? And so I've kind of illustrated that here, right? so you Again, if you it's easy to grok and figure out where stuff is But as you get more and more containers and you you separate concerns, that's great technically it has a huge advantage Technically, but it really kind of creates a mess as to we how are we managing all of these these containers, right? And there's another problem, right? So bear metal virtual machines containers these all still to some extent assume You know what's going on with the computer that's running them, right? And if that computer goes out, it's on you to figure out what to do right so computers break all the time It's the thing that happens I've heard that something like Google and we've got some folks that have worked at Google before here They'll know better than me, but replaces something like a thousand servers a day because computers just break And and so with any of these other solutions you have to monitor for that and Puppet has to walk you have to have puppet and orchestrating or something like it orchestrating Hey, what computers are running and what's not and health check and all this stuff Kubernetes is really very self-healing, right? You just throw a bunch of hardware at Kubernetes and it's going to figure out the best way to run it That's that's one of the big benefits of Kubernetes You can kind of think of it if you if you know about RAID systems For hard drives right random array of inexpensive desk the idea you put a bunch of discs together You should do some there's a lot of different complicated things you do against them But now you have one bigger desk same idea with Kubernetes if one of those discs you pull it out and you throw it against the wall Everything still works so let's next talk about some key terms and that will it'll help us unpack like the The the concepts behind Kubernetes because you'll hear a lot of these terms thrown around especially when you work at get lab And we're talking about Kubernetes all the time so so I want to spend some time just kind of simplifying what they are so first Again, we talked about container schedule or desired state manager right these things are to help you try to understand what Kubernetes is right basically I say I want my app to run like this. It's gonna need three front-end nodes It's gonna need a database. It's gonna need This kind of let these people in through this kind of this port And you state that and then again Kubernetes is the orchestrator The manager that places all of those things in the disparate hardware. It doesn't care where you don't care where you don't Have to figure out. Oh this app needs Two gigabits of memory and this app needs a gigabyte and this app needs 500k So let me figure out how much memory I have in different computers and distributed it just figures that out So some terms you'll hear you'll hear a pod node and cluster right and so I've got this kind of an order here Cluster refers to kind of the largest set Of things in Kubernetes So this is the entirety of all of the machines that are running Kubernetes that are where your applications running right a node represents one physical or virtual device there right so you can think of it a node as a computer right so I have Three nodes. It means I've got three computers. Those are the where where my applications are gonna run and then a pod is Where the containers themselves are actually running so a cluster has many nodes a node's gonna have many pods probably one or many pods and so that's kind of how that breaks down and the pod just is a Unit that says these are the containers that represent the front-end website or these are the containers that represent the payment system The other side of again kind of have that same hierarchy between deployment replicas and service so a deployment Just talks about deploying one set of applications or set of containers Replica says well, how many of those do I want to run at a given time and then service says What are all of the deployments that make up a service right so again? If we think about it in the git lab world if you're familiar with the git lab architecture You have to have postgres database. You have to have a redis caching layer You have to have machines that are running rails to run the actual web app Those might be deployments, but git lab as a service might be get lab So we'll go a little deeper into each of these And so these definitions are actually taken off Kubernetes website again They're trying to expose to the world, you know all these terms that are just ways of abstracting the way we think of things So again, the node is a worker machine. It could be a physical computer It could be a virtual machine most of the time. It's a virtual machine actually, but it has a whole operating system on it And then it also has Docker on it probably And then it has one or many pods running on it So here we can see the outline where there is The kubelet, which is just the way that kubernetes controls the node And docker that are running on the node itself And then we see the pods inside and again a pod can have one container in it a pod could have a container and a data store in it Pod could have many containers in it But we can see all those broken down there And then again the highest level abstraction is the cluster So here we see that little node that we just saw we kind of zoomed out and We've got three nodes and a master in this cluster. So the master is What is kind of orchestrating and telling the nodes what to run? and then It has gonna have many nodes that it can then distribute to and again those nodes don't have to be identical They can be you know various different pieces of hardware in different size They may have some that are there with GPUs for really fast machine learning processing and some that are Slower that are fine for back-end processes to run But all of those nodes together make up the cluster. So then let's dig a little deeper into a service I kind of talked about that a little bit So a service Can span a number of pods right and it's a set of pods that logically make sense to get together And then have a policy about who can access them, right? And so I have this thing below that say pods come and go but a service is forever right a pod is going to get scheduled into a node and But if that node were to go away The fact that this pod is a member of the service means I've got to go find somewhere else to make that make a new pod That has this thing running in it right and so it's going to keep all of those things at the top of this We can see a service be that has three pods Each of which have you know one app inside of them But we need all of those things to be running at all times and so something were to happen to The one on the left it would probably reschedule that and that pod into the other node So that's kind of like the really basic basic terminology There's a lot more detailed terminology obviously. I'm just gonna run through these real quick Again, we'll have plenty of time for questions at the end But I do want to kind of just touch on those other words you hear when you're talking about Kubernetes So one thing you're here is namespace this is really critical because One of the the the best parts and the and the beauty behind Kubernetes is Again the original design of Borg if we go back to that history lesson, which is as the infrastructure team I want to just provide hardware to my developers and people that run apps and as a developer I don't want to care about it where where it's running But you can imagine in a large organization, you know, there's folks that are running apps that Are finance finance financial apps that only certain subset of people can have access to You might not even want the developers to be able to you know get on and do anything against that and now in Kubernetes You've kind of got a seemingly kind of Wild West that this node could have anybody's pods running on it, right? It's no guarantee about where they're running So a namespace is another concept that Kubernetes uses to separate logically a whole set of services and Pods and deployments and everything that isn't within Kubernetes can be separated by namespace So that you can be multi-tenant from the beginning And so that's really critical because that's why a lot of our enterprise customers are so interested in Kubernetes because it really allows them to have this Separation that is going to meet their regulation the regulations that are placed on them But then also, you know make efficient use of the hardware or the cloud hardware that they're buying You'll talk here people talk about ingress and load balancing. So this is just basically to say that By default, you know stuff's running, but you can't get to it. You have to explicitly say what is what traffic is allowed into? my service and then Load balancing is just something that's kind of built in There's a number of different ways to achieve it But obviously if you have multiple apps or multiple copies of the same container that's running your app You're gonna need to balance the load coming in between that persistent volumes so again, this is is a very, you know Ephemeral kind of way of looking at the world, right? We said I could take one of the computers Throw it against the wall and it's and everything's still running, but obviously My data I need persistent data. So there's a whole another subset of Kubernetes about how you deal with persistent volumes and things that are stateful versus the stateless, you know apps that are running And then, you know, it also allows For those things that we that we help enable which is like rolling updates to your pods Right. So because you have this kind of distributed workload, you can slowly update Your app over time, you know enables can air things like canary and blue-green deployment really enables a lot of that and Then the lastly you'll hear people say cube CTL will come will come back to that one in a minute So yeah, kubernetes in practice. So this Is where I'm trying to kind of this is probably the most dense slide that I have but I'm trying to kind of demystify Again, those multiple touch points that we have with kubernetes because they're two very separate concerns, right? And and the separate concerns we're talking about here I'm gonna use very non-dev opsie terminology so that we can understand it. The purple is dev and the white is ops, right? so on one side on the white side if you're gonna run kubernetes and you're an organization you have to have folks that know How to run kubernetes maybe and and maintain the cluster. So that's one way to do it, right? You can spin up your own cluster and Add your nose to it. There's all kinds of different things that you can do to it But where that's made easy and where everyone's, you know pushing towards is Is a cloud provider right what a cloud provider does is make that part really consumable So when instead of having to use the command line and spin up my own machines and connect them all together I can go on to Google say I want a new cluster. I want it to have four nodes and I have it, right? That same disparity exists on the dev side of the house if you think about deploying apps again very possible to do kind of on your own you can write a lot of yaml and Describe your application in yaml. You can use helm charts, which are kind of a more Easier way to use that but it's still a lot of work And you're still going to be interacting a lot and using a lot of command line tools to get it working so The idea of that piece of that we talked about earlier about git lab Deploying your apps is we want to be that same easy button if you will That Google is for creating a cluster For deploying the apps right and so that's where Auto helm charts automatic deployment comes in we basically recognize what kind of app you have Automatically create a helm chart for you automatically monitor your cluster And then bring that all back into the development life cycle so that that kind of is again It's complicated, but it's just two separate concerns And and it kind of shows the the use case we're going for with our with our customers and and how we would you know try to Educate our customers about what we're what we're doing with Kubernetes Again, the slides will be available. So we'll have this hands-on exercise. You can do it walks you through it one by one But we'll just end with a couple little fun things So One is k8s you see k8s a lot. It's It's really not that complicated the way you spell Kubernetes is k eight other letters and then an s So that's hard to do. It's easier to write k8s. And so that's what you end up with How do you pronounce pronounce Kubernetes so again, I've got a link in the slides to the eight different ways you can pronounce Kubernetes Kubernetes I Think I say it the same way every time Kubernetes, but I may not and then I Jason plum pointed out to me that this debate is supposedly settled although I have I have a counterpoint to him so cube CTL is the is the Control that you use the the command line tool that you used to interact with Kubernetes and some folks say it should be pronounced cube cuddle and Or but you also could be cube control. I mean, that's what it really stands for But cube cuddle is kind of nice. I like it a lot better I think that the Kubernetes website now specifically says it's Cube CT cube CTL Or maybe cube control it says it's not cube cuddle But I found out that someone embedded IDs in the SVG version of the Kubernetes logo that says it's pronounced cube cuddle so I'm sticking with cube cuddle for now and The other thing that Jason didn't like from this presentation But I keep it kept in any way is I'm trying to change the pronunciation of get lab Caterl or get lab CTL to get lab cuddle because I think that's great So you're all on team get lab cuddle now. All right, so how do we make Kubernetes a game again? This is kind of a cool thing. There's a whack-a-mole game where you actually it spins up a Kubernetes cluster and you can like punch A node with the like the hammer from whack-a-mole and the node goes away and another one pops back up, right? great little explanation and Then someone actually did also spend the time to make that into a physical device So it's like a physical like DJ keypad that has lights on your lit buttons We can actually control your Kubernetes cluster like a DJ So if you're really into it after you take Jason's lesson, you can then go go build that There's also a Kubernetes children's book Highly recommend it. There's videos that go along with it and it's a whole It's a giraffe and I think an owl. I don't know what that little guy is And they're you know exploring the world of Kubernetes That's all I've got for you Thanks So as promised is not it was not an hour long. We have plenty of time for questions There's some nuance with respect to that sure sure. Yeah, so Helm again is this system Helm kind of is the charts the the descriptive language if you will The yaml that describes how do I want to describe a service and a deployment, etc? How that actually you take those just text files right helm you can think of helm is just the text files How you take those text files and then actually interpret that into Kubernetes commands is through what's called tiller and so I Think then you also the second part of your question was asking about how that relates to Like red hat and open shift right so Open shift From red hat is kind of their take on kubernetes, right? So it's kubernetes and then red hat builds on top of it, which is red hats business model, right? That's what? The you know sent to us as the open source version of red hat ever applies Linux same idea so they have Not added support for tiller yet or at least last time I looked at them They didn't which makes it harder for us to use our existing integration to an open shift cluster Having said that I think that we're doing a lot of work on open shift right now I think that's like actually the focus of the configure team But I don't know Daniel Grosse would know in great detail What the configure teams plans are around that and I'm just gonna go look if I can tell you quickly, but You Yeah, I'm not sure If you can't find out from Daniel, let me know Jim and but he should I would definitely recommend You know it might be it might be smart to if he is working on that like have a public sector call where he talks about where we're Going with that because it's a it's a concern for us It's we want to be able to integrate just as well with it, but it just it's I think it's just some more leg work To do This is kind of from a sales perspective, I guess but I've been told there are different distributions of kubernetes and I'm just wondering Does GitLab work with all of them? So if we're talking to customers, do we have to? You know clarify what distribution? I've been told that we work with like generic Just kubernetes, but if it's something there are other distros out there that are not generic that we may not work as well With so I'm just wondering if you can talk about you know the number of distributions and how they sure get lab Sure. Yeah, I don't necessarily have the most up-to-date information on how many there are But yes, we're building against the open-source canonical distribution of kubernetes right the CNCF is there's no question who Is in charge of the the main project kubernetes that is the CNCF and that's what we're integrating with Open shift in some ways is another distribution of kubernetes, right? You could you could call it that and then I know there are some others There may be folks in the room that are more aware of on the my So I would say that It's unlikely I think I mean that anyone besides someone at the scale of a red hat would have a distribution That was so different that our stuff wouldn't work with it, but it's possible. So it's definitely a concern I wouldn't bring it up in every conversation. Oh wait, let me just check your distribution But if you get an inkling that they may be something funny going on if I was an enterprise customer I wouldn't want to I wouldn't want to you I wouldn't want to use Again, some other distribution. That's not very well used right like I'd use open shift. I use Main kubernetes to go to another distribution. That's a big bar. That's a high bar and a big risk for me at this point Now that could change in a year, but at this point that would be a big a big risk for me That's a good question When we built that eks was really in its infancy I don't know. I'm sure there's an issue open probably I'm not I'm not in charge of that part of the product. So I don't know how prioritized that's going to be There's there's some differences about how Amazon implemented it that make it a little less clean To have a third party spin up. There's actually a whole separate Project cops I talked about it was in the slide. I don't think I talked to it Kops that stands for kubernetes ops and Really, that's the only way I mean you can point and click around and you probably can use the Amazon API but cops is really the most mature Way to deploy a cluster. That's not in Google. It's Google really it's just still pretty far ahead But I think if I would say that yes, we'd want to integrate the question would be are there API is mature enough that now Is the right time? I don't know So the question was about Google Tecon is it is a competition or something we want to integrate with I mean I think in some ways it is competition, right? So Tecon So that would give you a lot of context Another foundation was just formed this year called the CDF Which is the continual delivery delivery foundation. I'll just make it try the right. I don't think it's yeah continuous delivery foundation and Jenkins and Jenkins X have been put into that foundation as founding members and then also Tecon which Like everyone's heard of Jenkins only a few people heard of that and the reason for that is You know It's a big focus from the Jenkins community to try and mature The tooling around deploying to kubernetes, right? they have I Always say that one of their biggest disadvantages is they were written first Jenkins to us like if I if I'm talking about right like we We've matured and come to age in a time of containers being the way to do things So I think it is competition from that perspective of like there. That's trying to catch up with us As what it is, but we integrate with Jenkins today And so why would we not integrate with Tecon if a customer needed it tomorrow? Yeah, that's a good question That's that's a tough one I Can see both both Both sides of that. I mean open shift is kubernetes to a technical person, right? and So to just like copy and paste the configuration we have and put the word open shift on it is maybe not the best idea but there's probably There's probably other ways to solve that that I'm not thinking of on stage right now that we should probably maybe explore with again That's going to be Daniel and his team I think it'd be smart for Daniel again Just completely thrown him out of the bus But like a public sector call with Daniel would be really smart thing thing to do Are they thank you for the intro can you recommend a definitive resource to use to teach people about kubernetes? Yeah, so do you want to learn? So do you want to learn more about it or do you want to like put your hands on kubernetes? I'd like a resource like the pro get book which kind of takes you from zero to here sure sure So there's a couple I will post them with my slides when I post them I can't think of them all the time I have it I'll find them in the in the slides today or is a great hands-on tutorial, which I think is That's how I like to learn but I'll try to I know of a couple other resources like that that I'll try to add to the slides as Well, thank you before I post them Brendan I've got a resource I can add to your material awesome Yeah, I'm sure it's edible so great around security Oh, I did a presentation around securing kubernetes And so I did a lot of research on how you can hack it and you might want to include that Yeah, no, that would be great. That would be really great. I didn't touch on that at all I know Jason will talk a lot more about You know the boundaries that you need to set up when you're actually deploying apps in the 102 sessions this afternoon Sure. Yeah, the biggest challenge is it's a hot topic, right? So let's let again, let's go back to the history of kubernetes who built kubernetes Google, right? How many of our customers have the scale of a Google when it comes to software deployment? It's not many, right? so Like kind of everyone sees kubernetes as a hammer right now and everything's a nail That's obviously not true at all kubernetes is really great for what it's good for But it's not Necessarily, you know a panacea of solution which any new tech thing that comes out people assume is a panacea solution It's really complicated to run yourself. So if your thing is well our infrastructure is too complicated We're gonna go to kubernetes You're gonna have a bad time. I mean, maybe if you go to cloud provider It's gonna be okay, but you're gonna want to have some expertise in it If what you need is highly available systems Right, so are we still recording JT? Okay. Well, I'm about to talk about customers. So like ticket master Like they need a lot of quick scale here and there right and they're all in on kubernetes makes a lot of sense for them Like that's exactly kubernetes is a fantastic place ticket master is a fantastic place for kubernetes, right? Because that's what they need they release, you know Ariana Grande tickets and it's like you got a scale quick, right? Or wait, there's probably there might have been Taylor Swift gif No, I went with Ariana Grande So like yeah, so like that's That's I think the biggest challenge that the customers are having is making sure they're not just doing it because it's cool That's that's a problem. And in fact, there's a so there's a person. I recommend following heavily. She's in this slide She's the one that's not a gif Her name is Jesse Frazzell She's like at Jess Frazz on Twitter. She was one of the core maintainers of kubernetes when she was at Docker She worked at Microsoft for a long time She worked at github and she's been doing a lot of advocacy about what like she loves kubernetes. She helped write it But she's doing a lot of advocacy about like don't use it when you don't need it And so she has a lot of great. She's got a great blog and and some great talks out there that kind of talk about that I definitely recommend it. That's why she's the one in the thing. It's like a little nod to dorks. I might know her like me So right here So you're talking about running get lab on your kubernetes cluster. What's the difficulty? Hmm? Well there how much time do you have? I mean first of all running Applications and kubernetes is tough. Like I said Running stateful applications and kubernetes is really tough running a database inside of kubernetes today is Almost about I mean plenty people do it, but I'm gonna call it impossible And so get lab has a lot of stateful information right the git repositories Are a lot of information lots of really small files, right? And so there's not a really great way today To do that inside of kubernetes. You're probably you're gonna need some sort of NFS or something behind it We're working on that. We've got a thing called giddily That's going to be able to shard and replicate and be much more of a cloud native way of storing get data But it's not there yet. It's it's in its 1.0. That's that's 2.0 if you will The database is hard, right? Like today our helm charts have a ripcord that you can pull so you can use cloud provided databases because it Amazon RDS is fantastic at running postgres or Google cloud is a fantastic at running postgres like you to for you to try and replu user to try and replicate that inside your kubernetes cluster is not smart and And and so that's some of the challenges. There's a thousand other challenges that again Jason could talk to you all for about But that again git lab being a complicated stateful application is why I would forbid people from having to be their first kubernetes application Yeah, they don't have to no no There are plenty of way I mean doctor swarm is still around you can just do it like you can just do containers in with traditional tooling The difference here is like this whole cloud native discussion right again a very buzzy word, but I think it's an important one because If you're going to containers You now have a different a different kind of thing, right? And if you apply the tools that you have today to that you can do it But it's not gonna go great kubernetes is the different tool, right? And so that's why so many people are talking about it because they had that you know a lot of people have done containers without kubernetes and have that Ship on the right Right, and they don't know what's running where they don't know what the security is. They don't you know, they have no control kubernetes gives them control So again, it's a use case specific of if I'm trying to containerize does that mean containerizing kubernetes or just containerize You if you're gonna get down that road eventually you might as well bite it off all in one in my mind But if you're not if you're just doing simple things, maybe not it depends Sorry, it depends. It's the worst answer But but that is where we can help a lot right like if you're doing that That's where autodevops helps a lot right the autodevop the concept of autodevops is You don't have a container. You don't have a docker file. You don't you don't understand a container. You just have your code We're gonna containerize it Helm chart it push it to kubernetes You're gonna be able to learn a lot about what we're doing and it's all exposed to you All right, it's open source and it's actually just a ammo file and so you can learn a lot about I mean I learned kubernetes through Playing with git lab autodevops. It's a good question. Do you still need puppet chef and ansible? puppet chef and ansible would say yes They have their use cases I think right I think that Folks will still use them To I think they'll have I think I don't think everyone's gonna put everything in kubernetes I don't think that's realistic for many people most people except for maybe Google So yes in that regard and then I think you're gonna end up I think those tools will pivot and add leverage their fantastic You know market share up to this point to to provide tooling against kubernetes that people are gonna want I mean if I was them that would be the only thing I was thinking about so Great, thank you all so much for coming really appreciate