 There you go. Hi. Good morning. So unlike your previous speakers I really have no credentials other than the fact that I work at Red Hat But we happen to be a sponsor and they asked me to give this get ops talk So I'm here today to talk to you about the future of get ops I've worked with Christian know for quite a long time so he can maybe vouch for the fact that I know at least one thing So a number of years ago a lot of interesting technological things happened kind of around the same time we had this birth and emergence of containers and other container-like technologies and then Google and Red Hat and many other organizations came together to work on a scheduler to deal with those technologies And so the power of all these things combined gave us this more YAML No, but in reality what they gave us was a declarative way to decide to run Workloads and through the power of this type of YAML definition and kubernetes What we get is the way to ask sort of for workload to be run within a pool of resources, right? Give me this container image that I've built myself previously that it's available in some registry somewhere Make sure this many number of them are running and keep them running for me, please Right, and so this was great. Everybody liked this so far And so when this happened, you know, we had this expectation of greatness, right? We're gonna make this wonderful dish of our cool applications and everything But then reality strikes and we realized that oh god, this is pretty terrible Running kubernetes is not easy So again, you know cool things happened along came these various technological providers red hat included and we said hey We understand running kubernetes is pretty tough. We're gonna make it easy for you We're gonna handle this quote-unquote infrastructure and make it available as a service and that was great except It doesn't really solve all your problems. It just gives you the stable platform on where you can run things But now you actually have to run things And so we have real work to be done now. We've got this kubernetes infrastructure We've got to do things with it, right? We've got to configure it. We've got to Actually make and run our workloads keep them going and we want to be able to maybe audit and roll back and etc So for all of you who are here, obviously you're interested in get ups along came Argo and flux in these other get ups like technologies that said hey, we will take that Declaration of Desired Workload if you will and we'll make sure that that happens and if we detect any change We'll make sure to reconcile that for you So in this case, we've got this engine x workload that we want to have three of and no matter what happens in the cluster Argo is gonna make sure that that stays the case This was great. So Kubernetes was doing things we had our workloads configured We have all this stuff going but not everything that comes in kubernetes is exactly what I want And so this concept of a CRD a custom resource definition came about that enables us to extend the kubernetes API I don't want a pod. I don't want a deployment. I want a chicken sandwich, right? And please make that happen in my cluster. And so when you combine CRDs with this thing called the operator framework an operator is just a controller pod that runs in a cluster that looks at these CRDs and says okay, I know what to do with that chicken sandwich. I can help instantiate one of those for you and so now when we combine CRDs and kubernetes we really can start to build some superpowers into our Environment and if we use this continued example with Argo being sort of the get-ups tool here We can have this new thing, which is a stream. Sorry a Kafka Which kubernetes has no idea about out of the box, right? We've defined it with a CRD and we have this operator pod that understands how to deploy Kafka components based on this simple definition of a Kafka and through the power of Argo and get-ups We can make sure that those Kafka instances are always running as intended and as desired and so now things are getting really interesting because Nothing says that those operators have to interact with only things that live inside your kubernetes environment So through the power of something like crossplane you can have a definition of an s3 bucket Which ends up living outside of the cluster in a completely unrelated set of infrastructure in the cloud somewhere And so really what does the future actually hold? What can we do now? Well, we can think of git or source control as being this arbitrary interface into Anything as a service anything on demand so we can envision an operator that does whatever and some company says Hey, here's this yaml spec for how to get one of our things I mean we're in the land of cars here in Detroit right like that could be a car that you write your little yaml file for and then like An hour later that car appears or whatever it is, right? So the the future really in a weird way is Declarative and we see this in many of the ways that we interact with technology and things today But this is kind of like an interesting view into what might be possible in the near future And the reality is that it's already here in this type of example, right? So whatever you can envision in your own infrastructures, whether that's inside your own premises or outside You know with an operator and a CRD you can pretty much do whatever it is that you want So that's that's the end. That's my five minutes. I don't know who's next