 Welcome. Thank you all for coming. We're ready to get started. Good news. We've actually got a two for one today. We're going to walk through delivering an application on a platform. We'll talk about platforms and operators and the like. And we're also going to use this opportunity to introduce you all to tag app delivery and what we do and how you can contribute. Before we start, I just wanted to ask if you could raise your hand. How many people here have read or referenced the GitOps principles? Nice. Nice. And how many people have read the operator's white paper or referenced it or used it? Okay. One last question. Who here is title or is part of a team that's called platform engineers or platform team? Okay. I've got quite a few of those. Well, the reason I'm asking is because actually the GitOps principles, the operator white paper and right now we just released the platform white paper. That's come from this group the past two or three years. So thank you for benefiting from our work. We hope we benefited you. All right. So let us now introduce ourselves. My name is Josh Kovant. I am a solution architect with Red Hat and one of the technical leads for tag app delivery. Yes. Hello. My name is Tom Schütz. I'm Tech Lead of the CNSF Tag App Delivery. Furthermore, I'm a consultant, educator, CNSF CDF ambassador and whatever. And just happy to meet you all here. Hello. I am Jennifer Stradewicz. I work for Canos and I'm a co-chair of the Tag App Delivery. Very happy to be here. Just a quick run through of the agenda already mentioned by Josh, but we are going to just talk a little bit about our tag, the mission and a few updates. Josh is going to go through the platforms, the work with the platforms white paper. I'm going to go through a bit about operators and some of the changes in the landscape in the last couple of years. And we'll end with Thomas talking about what is a cloud-native application and trying to define that. So who are we, right, if you have heard of us? We enable, we help end users and projects by providing some unbiased feedback and also onboarding new contributors and matching, like, trying to help both sides. We provide some advice on projects that want to join the landscape, the CNSF landscape, sandbox or incubation. We also provide some materials like white papers for people who want to get onboard onto the open source world and the cloud-native. We also help facilitate working groups, creation, and by providing some structure and helping form them as well. So one of the working groups that we have is the platforms. We had the operators working group, which was short-lived. Throughout the time we created the operator white paper. We are trying to get a new version now, so it's coming back. A new working group that's coming is Artifact, and we also have the GitOps working group. I'll hand it to Josh. Thank you. All right, so I'm going to start off by talking about platforms and showing an application deployed seamlessly, quickly, flexibly, efficiently on a platform. I put this picture because when I think of platforms, I think of people supporting each other, being able to build on the shoulders of giants. So here you see how high one person could get when they've got a lot of other people helping them. So we're going to talk about what exactly a platform is, or at least the opinion that we've put in the paper. And how they can help with that development, a little bit about why. I'll show you a demo, and then maybe we'll go a little into the capabilities and attributes. So what and why? Yeah, so in the consensus that we reached working on the paper was that a platform consolidates, brings together a collection of capabilities that an application needs in a consistent, coherent, directed way based on the real needs of the user of the platform. So for example, in the cloud-native world, bringing together observability services, database services, event buses, artifact management, all these different things that need to come together for your application to work, the platform provides consistent interfaces and consistent ways to get at them and also to integrate them. Let's not leave that out. Part of the purpose of the paper that we wrote, and I want to talk a little about why, is that we wanted to enable platform engineers or leaders of platform engineers to convince their enterprise, like, look, if you want to move forward with cloud-native development and really maximize the value of it, you should adopt this platform model. And so we put a lot of whys in there, too. Some of them include, I mean, I'm sure you've heard the term cognitive load, make it easier for your app developers to focus on the task at hand, the business logic at hand, and not all the collection of stuff that's underneath. Instead of having many, many teams building that full stack underneath, dedicate a team that becomes a set of experts on this, becomes much more resilient, reliable. We mentioned sharing. If you have a common platform, it becomes much easier to share code, to share knowledge, to share people even. It's much easier to switch teams. It reduces risk. This kind of is reflected in the kind of funnel shape here. There's a choke point here for all the code going into production where you can apply policies, you can apply security checks, you've got a little bit of control. And it also enables, a lot of times, this bottom layer, you might think it's data centers that you maintain or something like that, but could also be cloud providers. But you can't just, I mean, maybe you can. A lot of times, you can't just throw out cloud services and say, oh, use them. You need to provide a consistent way that fits in your enterprise. So it also enables you really to better use all of the software as a service and provider capabilities. So tell your CEO that. Yeah, so here I just wanted to illustrate, here's all that platform stuff that we illustrated before. Here I put, actually I built this app a long time ago, but it's a typical logical diagram of all the components that have to interact in a cloud-native app. And interestingly, and I think I mentioned this in the last slide, it becomes distributed. I mean cloud-native and distributed are pretty closely related. But I like this because it kind of shows you, I didn't want to draw lines because you would never be able to even see this page, but it kind of shows you how all of these pieces get pulled into an app and integrated. So with that, I wanted to show just a quick example of, this is just an API service. Let me see if I can get it to come on over. Come on over. Oops, must be going the wrong way. Sorry folks, there we go. Yeah, I wanted to give an example of a set of capabilities, making up a platform and then an app writing on top of them. So let me just make that a tiny bit bigger. So I'm first to show you the end result, actually, which is just a widgets API. I'm sure that's hard to read up there, but it's just hostname slash widgets and it's just returning a list of widgets that I inserted. That's the end result. But it's using a database. I could actually show you it's got Yeager tracing established on it. It's using a bucket for some stuff. It's got a certificate. It's been deployed by Argo CD by GitOps. Forgive me, I'm using OpenShift here, but it's operator lifecycle manager behind the scenes, which is part of operator framework, which is allowing all these operators to be quickly installed. So I've installed a database provider. I've installed distributed tracing, a couple of different parts, which gives me open telemetry. I've got Minio, which gives me buckets, search manager. So this is kind of my platform in this case, my capabilities. And this gives me, remember, we said that consistent coherent interface, these are all just Kubernetes manifests. So I've got a build. This OpenShift has a built-in build controller, so that wasn't in the list before, but I've got a build. I've got a certificate. I've got my configuration. Images is a way OpenShift stores. So that's my artifact storage for my images, instrumentation gets me open telemetry installed, PGDB. I'll just open one of them for easy. I mean, I don't have to go through all of them, but look, that's the simplest of things. And then, of course, there's a customization, and it all gets deployed out by, and Thomas is going to talk more about this, but here's an application YAML, and that kind of expresses, pick up all that stuff, put it into the cluster. I've already done it. I'm not going to do it right now, but here's that entire application, or actually the core code. I didn't even show you the code of the application. It's in another repo. But here, I've just, with that set of manifest, deployed the application, integrated all that capability from the platform right into it, and there we go. Much easier than having to build that whole thing from scratch. Let's close that out. So the next step that I probably would take with this app, if I was building a platform, would be to templatize that, and say, oh, you're looking to build an API server, and here's a standard framework for all the components you're going to need in your API server. That's also an important part of a platform, is templates. The last significant thing I wanted to go over, in the paper, we have functional attributes, or functional components that you might want to consider for your platform. Here, these are the non-functional ones. We really want to emphasize, and we really want to help you all, and we're working on some stuff for that product mindset. You've got to really emphasize with your app developers and understand what they need, and try to understand if what you're providing meets those needs and iterate with them. That kind of fits in with the next one, developer experience. Your core is to let those platform users have a good experience. Documentation, self-service. Things should be automated. I can click and get it as much as possible. Reduce cognitive load. You want to abstract and encapsulate as much as you can. Optional, there's always going to be people that want to go around. Composable, and of course, secure by default, like we mentioned. The last one of my slides, I don't have a timer here, but I hope I'm not taking all of Jen and Thomas' time. I'm not going to go through all of these. Actually, this is what's listed in the paper as capabilities to consider in a platform, so people have been looking at these. It's got some synergies with landscape, and we're going to be talking about that with them. A lot of people had eyes on this, and we felt this represented the things that you should look at and think about, including in your platform. With that, I'm going to turn it over to Jen, and she's going to tell you about operators. Thank you, Josh. Hi, everyone. I'm going to talk quickly about operators because they aid platforms and applications. As you know, in Kubernetes, the primitives like deployment, pods, and replica sets, they are operators behind the scenes, and the operator pattern and operators came to provide developers and platform engineers with ways to customize that, create custom resources, and controllers to manage those resources in the same way as you do manage like a deployment or something. That abstraction also allowed for platform toil to be reduced with the same kind of automation as you would do for application lifecycle management. Also, these operator patterns over the years have evolved so much that they matured beyond Kubernetes itself. Just quickly going through basic operator reconciliation example here diagram. It's on the operator white paper as well. You have your business language, your business domain knowledge that you apply into custom resource that you create for users to declare based on your needs. You then implement a controller, implement a watch that will be watching this resource and matching it against the current state in the cluster that's going to take actions, apply changes to reconcile those. You also will report to them. My view on this is that the operators make platforms more product-like, as Josh mentioned with the platform capabilities. You think of it as a product because that allows you to develop ways and to provide a foundation for creating portals and the CLIs so people can consume that in a more product way, I'd say. One example of this is, let's say, a user journey that could be is like a developer trying to consume a database, create a database. I will show you an example of cross-plane, for example, which uses leverages, CRDs and controllers in order to provide a couple of personas in this case, for example, a developer has only to concern, has lower cognitive load, like Josh said, on just concerning themselves with their knowledge about the application and on the infrastructure side, all they need to know is what kind of database they need. They just need to worry about designing the database so they decide that they need a NoSQL, they decide about the performance they need and the size, for example. So the cross-plane provides a way using operators for you to declare your ubiquitous business language, I'd say, via customer resources. And then the other persona, the operator here, which would be your platform operator, will then declare their business policies and ways that what means a fast database and, for example, a provider could be a cloud provider, could be on-premises APIs. So it's totally abstracted from the developer these details that the operator would be concerned with. Next. So another thing that is also available on the operator white paper, it's some of interesting operator patterns that have emerged over the years and one of them that I'm going to talk about quickly is this operator of operators, which is basically an operator that's concerned with managing other operators that have other concerns. So for the user that consumes this operator, they are seeing just one, but in fact, in the actual implementation, it's other operators that are being installed by those and being managed by this meta operator, let's say. A few popular operator frameworks you've probably heard of since you answered Josh's question in the beginning. It's CubeBuilder, the operator framework. Interestingly, there is a few, with the landscape changes now, there are some emerging operator frameworks that you couldn't read about as well. It's like Metacontroller, which again is similar to the idea before, but it's just a way to create those Metacontrollers as a service. And also there is Juju, that's a model-driven operator framework that is catered for more enterprise use cases, multi-cloud, and actually transport the operator. It can create operators outside of Kubernetes, not using the same reconciling patterns. So it's just quite interesting, you should check out. And yes, I've been talking about the operator white paper quite a lot now, and we have made some changes since the publication, which was in 2021, the first version, but as you may know, like for example, GitOps was like 1.0 version, and lots of changes have happened, and we added a few more things in there. It's constant changing, but I would like to call you to tell me your story about your usage of operators as well, and either talk to us through in the meetings that we have by monthly and also on the Slack channel, and also you can submit a PR on our GitHub. And yes, so the Slack channel, and take a look at our blog that we made, Tom is going to show a bit more, but we have a new website, very nice. Please, I will hand to you then to talk about applications now. Thank you very much. Thank you, Jennifer. Yes, I can only encourage everyone of you to contribute to such white papers or whatever. For Jennifer and me, this was the way into the tech, and it was very much fun to work on such a white paper. So, yes, as announced previously, I will talk a bit about applications, and as I said before, I'm a teacher. So, who wants to tell me what an application is? Well, has anyone an opinion of it? No. A collection of services that provide business or end-user value. Thank you. Another one. An executable. Okay. Jarek? Yeah, so I would say there's not one definition of application, but from a business perspective, it could be a set of services that serve one business stuff, whatever. Okay, thank you. As you heard now, it was a bit of an easy example. Normally, when you talk to three people about applications, you get five opinions. And I think the same is about applications in the Kubernetes environment. So, at the moment, at least in my opinion, not a really clear definition of what an application is. So, in the first step, I just want to show a bit how cloud-native applications are described normally. So, sorry, there's too much light. So, we have an application. An application could consist of one service or multiple services. So, in fact, the application is more or less a boundary for a thing which fulfills a business purpose. In this application, the services should be able to scale independently. So, when we find out that one service is overloaded or whatever, we should be able to scale it alone and not have to scale all of them. And finally, we could describe that the infrastructure and the configuration can be seen as part of the service. So far, so good. So, that's what I understand as a service. As an application, sorry. And now, so we talked a bit of what is an application and you might ask yourself, what is the problem now? At first, we are living in a cloud-native world and all of us are thinking that services should be always developed and tested individually. That's the thing we read in the books. In fact, it's always different. So, there's a lot of applications out there which are more or less micro-monoliths which are tested, developed, and so on together, which are multiple services, but only work in a certain version combination. Furthermore, when we deploy things in Kubernetes, we know that our workloads are running. We know that they are most probably in the state we defined somewhere, but we never know when the application, the deployment is finished. So, there is no resource at the moment in Kubernetes which tells us in which state the application is. The same is there for workload and application health checks. So, we always know that the workload is running technically. So, we define somewhere in our manifest that we want to have three replicas, we want to have resource limits, resource requests, and so on. We know that we want to have these environment variables and maybe we have some health checks which help us defining if our application is somehow running or if our service is running. But in fact, these are only scoped to the services. We don't know if the application is running. And last but not least, there's a standardization issue. So, there are application definitions out there. But if we have five application definitions from different vendors, we don't know how to switch between them. So, some weeks ago, I said down a bit and investigated a bit about application definitions and I will show you some results afterwards. But at the moment, there are about three types of application definitions. The first one, our application definitions were the whole application. So, all of the deployments, services, and so on are defined in one resource. This is, for example, in Open Application Model and in QVilla. The second ones are the types of application definitions where a source to the, where a reference to the source is stored in the resource. Many of you, I think, know ArgoCity. This is one of the things where we simply reference to a git repository, but we don't have single resources defined. The second one I found here was cover and cap. The third one is an application definition where the reference to objects is stored in the resource definition. And this is how cap operates at the moment. Okay, so, as I said before, some weeks ago, I said down, I took our demo application, the Potato Head, and tried to deploy it with various application definitions. So, just out of curiosity, Potato Head was a demo application which was created for KubeCon NA, I think, 2021, 2020. And what you're seeing here is an application which consists of six services. So, the body of the Potato Head is one service. The left arm is a service. The right arm is a service and the same for the legs. You can put arms up and down and so on. And this is also a thing which is done in the tag app delivery. So, what we are doing in the tag is not always very, very serious. But I think this is a very, very funny example of funny work you could have in a tag. Okay. So, this was Josh's entry point. Okay, so then let's take a look on the first application definition. This is, what? Where are we? Sorry, I'm not used to working with this. Okay, so this is a typical application definition of AgaCD. We see that this is an application. This is called Potato Head. Yes, and so on. The interesting part of this is we only have a reference to a kit repository which tells us that everything what's there in this kit repository is the application. But we don't know from this definition how many workloads we have, which configuration we have, and so on. In the second example, this is for the open application model which is used by Cubila. And there we see the application is defined in a very different way. In fact, this is also an application only with a different API behind it. But what we see in this definition here, we have all of the components in there, such as front-end service, as in left-arm service, right-arm service, and however they are called, we have all of the environment variables, all of the configuration, and so on and so on manifest. It's also a very valid way. And in the third case, we have the captain way, we always simply have references to such things. So in this case, the deployments and so on are simply annotated with a name and a version, and the application manifest simply puts down all of them together. So as you see, we have three tools and three different opinions. And there is at the moment no way to switch between them. So to get back to the slides. And this is where we are at the moment. So the whole application definition topic is a very new one in the tag at the moment. And this is a question I have to you. Is anyone interested, has anyone such problems that you don't have standardized application definitions and would need one? So it's a good idea to do this. Okay, so if you were afraid of raising your hand, and you are interested in this topic, just feel free to reach out to us. And if you know more than the definitions I've showed you until now. So these were only three examples. I have two, three for another one. You can always provide examples for the potato head. So this was the initial thought of the service to showcase how such application departments could look like, how such scenarios could look like, and to always have them testable. What we want to get out of this application, of this whole application were things. Maybe a proposal for a standard, maybe we could provide some new project out of this and so on. We only also want to create blog posts so we started a few months ago and a white paper and a working group. And as I said before, we want to provide some examples. Yes, this was the application part now to wrap this up a bit. Some weeks ago, a member of the tech was so nice and started creating a website for the tech app delivery. This is there on the tech app delivery since the FIO. And what you can find here are all of the white papers we have created all the blogs and so on. You can also find meeting times. And the nice thing of this, with this white paper section here, we could change our white papers to a more or less rolling reads model. So we can update them in place and when you are looking at the white papers there, you always have the newest version. And some of you might ask or might not ask what you could do for the tech. And the first thing would be if you have use cases, experiences and so on about cloud native application delivery. We are really glad to hear this. So the things we are doing there should not be academics. They should help you. They should help other end users but also our project to involve. So if you are doing cool things just get in touch with us and you can always show this in some of our tech meetings. You can always visit our website and read our white papers. You can always provide examples to the potato head and you can support the tech in its technical domains. But at the moment, we have the, as we said before the platform's working group, there is the work on the operator white paper. We might want to do something on UCI artifacts and applications and so on. So there is enough work for everyone if someone wants to work something. Okay, so I think this was it from our side. Thank you for being here and have a nice rest of the CubeCon. Sorry, are there some questions? Kind of combining both topics with the operator and app delivery. So if you don't have access to the operator life cycle manager, is there any type of push to treat operator or what's the reasoning behind the operator life cycle manager? If you don't have access to one can you just use your typical app delivery means to deliver operators? Yeah, actually I have a repo full of operators and capabilities that I add into my clusters and one of them is a home chart, one of them you download a CLI tool and you run it, one of them you run a special, like in certain clusters you'll run a special add on add. So the advantage of operator life cycle manager, and you can install it in any Kubernetes as part of operator framework is that it gives you a marketplace and gives you a way to, the way it works is you create a subscription and then it will install it for you. So if you discover and install operators the other option would be just find each individual one it says install the home chart do it that way so that's the advantage of, I think it's something to think about like some consistency across clusters and that, but yeah operator life cycle manager is one option. Does that help? Thank you. Any other questions? Alright, well we're here for the next couple of minutes. If you want to talk and thank you so much. Thank you.