 Yeah, welcome everyone to our session on tag app delivery, which today is co-presented in a hybrid way between Jennifer, who's live on Zoom from Europe here, and myself. So before we get started, I asked this question before, who of you knows what tag app delivery does, who of you knew before the keynote where Cornelia introduced tag app delivery that it existed? Okay, not a lot of people, which is good. So that's why we're here today. So before we get into details, let me or let us introduce ourselves as your co-host today. Maybe Jennifer, you want to start? Okay, hello everyone. I am Jennifer Stradjevic. I work for VMware, I'm a software engineer, and I'm also co-chair for the tag app delivery. Nice meeting you, without seeing you. Well, I can turn you around so the audience can wave to you. See? Okay, my name is Alice Wright-Bauer. I'm also co-chair of tag app delivery, and one of the founding members of app delivery, which has been around for a bit more than two years right now. So let's talk a bit about what we're doing, when the focus is where it's supposed to be. Yeah, if you have any questions and are on the live stream, I know that there is a dedicated channel for the session for the maintainer track, where you could obviously ask questions as well, but usually this channel gets very crowded, so ideally you go directly to the tag app delivery channel, which is where most of the app delivery work is happening as well, and it will also exist, or you can ask questions and continue them after the conversation as well. So yeah, before we get started, we have actually an awesome logo, if you didn't notice. Maybe notice through the keynotes, it's the kangaroo. Now the question is, what does tag app delivery do beyond having a really awesome kangaroo logo, which obviously makes sense, because delivering applications. And therefore let me give you a very brief insight into the tag app delivery charter. So this is copied directly from the charter of tag app delivery. If you think about the different tags within the CNCF, all of them obviously have different roles, and a lot of them are focused on, say very much infrastructure components, so whether it's a SIG runtime, or it's SIG network, and some of the other SIGs, some are more cross-cutting like obviously SIG security, what tag app delivery is for, is really looking at the application developer who wants to ship cloud-native applications, obviously on Kubernetes, but as a lot of work in the CNCF, not only on Kubernetes. So we try to do most of our work, while a lot of it is focused on Kubernetes, but being applicable to cloud-native patterns in general. So what this means is really about developing, distributing, deploying, managing, and operating secure cloud-native applications. So the focus here is really on the applications and not on the infrastructure components. That's a bit squeaky here. So what does this comprise? First of all, it's application definition. So how do we actually find applications in Kubernetes? And if you think about it, well, we all have like all the YAML and Kubernetes primitives to model all the components, but how do we define like what an application is like defining it as a whole? Not just the services that we're using, the deployments we're using, but all the things that are related to it, say storage classes that we need, passwords that we need to manage, access to external systems and so forth. Guidance and practices for application design and development to be fair, this is an area where we did not invest a lot of time in the past. I think we don't see this as our real responsibility to tell you how to build your applications. But now as we come to later on in the working groups that we have right now, we kind of are getting into this area on a very specific topic. So for example now, how we can bring infrastructure as code and like application shipment closer together. It's one of the areas that we will discuss for some time we had a working group that then obviously during the last two years because people were too busy resolved on air gap environment. So how to deliver Kubernetes applications in an air gap environment, which brings us to the next topic which is application bundling and deployment. So how can you bundle an application and ship it? Package management, obviously the whole application, delivery workflow and strategies. So these are on the one hand that they deliver a tool that you're using but also defining which application strategies that we have. There's this, I think now almost famous quote from Kelsey Hightower used to say he can't see any more Kubernetes demos during Canary deployments. Yes, that might be true, but still if you look at all the tools that are out there, how Canaries are actually defined and how they are deployed is highly different from the individual tools that you're using. Yeah, and configuration source driven workflows and last but not least release management. So we really don't want to stop where just by shipping the application but obviously also handling the application until it's retirement from production. So that's like the broader charter scope of what we're doing just to understand not everything that we have in the charter is necessarily something which we're doing as of today but that's like everything we kind of deal with and how we can engage. I have added this in here because I find it kind of like super helpful to describe a bit how like the application delivery work relates to everything else that's going on in Kubernetes. This was actually done by Lee Zhang who used to be a co-chair and founding member also of tech app delivery like how like different bits and pieces are related to each other. So what you can see here like on the lowest level you have like the platform like resource management the container life cycling network and so pretty much everything what you need as a platform to build your application. And that's also the part that we say, okay that's out of scope for tech app delivery. These are the bits and pieces that are handled by other techs. However, the first three topics are the ones that we actively work on. Everybody mentioned application definitions so this is really about having an application descriptor having an application model like how do we model what an application is? How do we kind of package it? How do we make it understandable? There are some projects within the CNCF that try to model applications that try to refine a language for applications but it's not like widely used for a lot of people. And again this is like not just having like a large Helm chart that continues that compromise of everything you have as part of your application that's really developing this kind of application model here. Once you have that application obviously you need to package it and ship it. This becomes even more interesting as we now talk about secure software supply chains obviously and also with air-gapped environments. So how do I take everything that I need to deploy an application, bundle it and ship it? This goes in directions of obviously projects like portal for example where I can take an entire bundle. So I don't, I need more than just the Helm chart and some of that information and the values files. I also need to bundle into containers and I need to ensure that they're in the proper place so that it can be installed. Then obviously the rollout and life-cycling management so everything from configuration driven obviously we will be talking about GitOps in a bit. Then rollout strategies that we're defining and also how we do diverse graphic management which is obviously closely related to rollout strategies as well. If you think of like canary deployments yes you have to deploy the application properly but on an ingress level or load balancer level you also need to define how information should be routed and then everything from regarding to this is where the overlap comes like with the platform about instance healings, scaling out, charting and also managing the life-cycling instances that you're running. So that more or less is when you could almost see that when like the rubber hits the road when you like take all this bundling that you have built and want to deploy it down on the actual platform. So this is the model which we have been using for the last two plus years to kind of describe what we're working on and what the individual bits and pieces are. And as you can see this is a bit more complex than just doing a canary deployment or rolling things out. Like there are really a lot of questions that come in here especially when you talk about enterprise rollouts. Also for your involvement if you either have said well we have built this and we think we have built something amazingly great or we are building it but we have built this and we ran into certain issues which we think should be solved in a better way also feel free to interact with us either by sharing your use case, your architecture, your model that you're using or coming to us with your question and then collaborating with other people on these topics. There's a number of working groups was in tech app delivery. So just for your understanding before I pass over to Jennifer I'll just show you all the bits and pieces that we're working on. Usually tags do mainly two things that support the TOC on the diligence for projects which we'll talk about in a while. And they also look into new areas where we should decide okay there is some work that should and needed to be done and engaged there. The first one was the operator white paper working group which well did what the name actually comprised they brought the white paper and operators who few here in the room is using operators today. Also actively developing them. Good, what we did here was well we had all this like notion of an operator and it's like kind of like super central but there was no detailed white paper how to develop them, what the principles are and so forth and Jennifer can give or will give a bit more insights because she was driving a lot of physical activities. Then there's obviously the Github's working group. There's two new working groups that are currently forming the chaos engineering working group. Like really covering chaos engineering from a very wide number of aspects the corporate delivery working group which we'll also touch base on which things of how can we bring the app development and infrastructure closer to governance or some issues that usually arise there and also their potato head reference implementation that came out of a cube contact which we did a while back that more or less allows you to use a reasonably complex but still easy to deploy so you can write on your local laptop application and test out different tools, test out different strategies. And Jennifer, I'd like to pass over to you. You want to take Github's working group as well or should I take that one? I prefer you to take it because there were some latest updates. So let's, I thought because I thought we were at the operator white paper. So Github's working group, who if you're here is familiar with Github's who's actively using it? Who thinks that they are doing it right? Well, of course you could wait a minute. Sure, I'm doing it right. So that's actually what the Github's working group was about. So they wanted to build a vendor and mutual way where to define and drive the adoption of Github's. The idea was everybody's kind of doing Github's. But what is Github's really? What should you do? What should they take care of? What's the difference between just more or less doing a cube control apply from what you have in the Git repo versus actual Github's based workflows or Github's based interactions? They also created the open Github's sandbox project which you can find under open Github's.dev. They will find the Github's principle so they define a number of principles like what a Github solution should be doing. They're running obviously a lot of events. They also have like reference and training material that they're developing around it. And there's quite some companies that are actively participating in there. As mentioned, the Github's principles and the glossary have been released pretty recently. And as you can see there's like a lot of conferences and work that they're running on right now like Github'sCon, OracleCon, the Github's one-stop shop which I think is happening at the end of October. So there's constantly events related to Github's as well. So I definitely recommend to check this out. They also had a session here and that's one of the areas that we're working on. And now we're getting where we wanted to be. Yes. Jennifer. Hi. Yes, the Operator Working Group is very exciting to me because it is how I joined the Tag App Delivery. It's finished now, but we achieved a great milestone very recently which was the Operator White Paper. And some good things about it is that it's really, it's entirely community driven. It was not just us like we received a lot of help and thank you everyone for that. The Operator White Paper provides a deep but no exhaustive overview of operators in Kubernetes but also beyond not just thinking of Kubernetes. It gives you a definition of the operators of operators and how they can be used. It also dives deep in the security issues and use cases which was a help from the Tag App Delivery. They contributed massively to this part. Also thank you on that. There are also use cases for operators use patterns but also somehow to look into the future because it's ever changing now. There are some insights into the operator design. And yeah, like it's made for as well as for the people who already are familiar with operators but it's a great introduction because it's not as exhaustive as a big book and not as short as a blog post. It's really, it's a white paper but it's a great starting point for people because it also links you to several resources that dives deep in different areas that are most interested. So there's a lot of sources there as well. Yeah, it's been released a couple of months ago so it's very leading edge now and we are welcoming contributions. We intend of course to carry on and have a second version in the future. So please take a look and yeah, contribute. Yeah, so this is also one of those great examples that we start to see happening especially in Tag App Delivery that we very often collaborate with other tags. Like in this case, as Jennifer mentioned, Tag Security which I think is also like a great way on how we work together. By the way, how this started was really by the TUC asking Tag App Delivery, well we have to short definition as part of Kubernetes what the operator pattern is but to really know what an operator is and what it isn't. And I really recommend reading it because many people are amazed that it could actually build an operator that is actually not running in Kubernetes. It might be way more work but you could also use the operator white paper there. Maybe also important, if you find anything that you don't like all our white papers are also in our GitHub repo so you can file PRs also against everything here. So we try to really like work collaboratively in the open and Jennifer and the team that were great like driving this effort for quite some time to like this very successful output. Oops. Do you wanna take Chaos Engineering or should I take it? I can give you an introduction and maybe carry on. So like, yeah, the Chaos Engineering is very, working group is very interesting because it is a joint effort across several tags under CNCS. So it's under our charter but there is a lot of engagement on the observability as well, security as well. Yeah, and it aims to define a tool-independent methodology for Chaos testing based on the current use in the industry. So the area that falls into the application delivery is the, I believe is more in the test area. So we want to integrate Chaos into the application delivery workflows such as continuous delivery processes. And we also want to show good practices for complex testing scenarios such as multi-tenant systems and hybrid cloud native environments. And yeah, so like the working group we will also elaborate on what users and organizations in the cloud native world mean like when in terms of practices when they have adopted Chaos Engineering because we are like, I adopted Chaos, like what is that? And there is like a good definition, we want to get into a definition of that. So the working group is working on that by talking to end users and having an understanding of the current landscape. They will also focus on the security perspective by ensuring resilience is maintained at all times and also develop some use cases for security Chaos Engineering to validate that the security controls or change to the controls happening in a rapid fashion to mitigate active attack scenarios. There will be no tooling comparisons and recommendations. This is an unbiased assessment and the information is to aid the adoption by users only. So if you want to understand more about the problems these working groups trying to solve, you can have a read of their problem statement and expected outcomes in the working group charter. You can find that under our channel and under our GitHub. Alice, do you have anything else to add? Yeah, I think Jennifer described it very nicely. This is an effort that is currently just like getting started. So if you are interested in Chaos Engineering or planning to, feel free to contribute. And again, contributions does not mean that you actively work like on the white paper or anything. Just if you have questions say, hey, we are currently starting to get started to work on Chaos Engineering. And like these are five or six top questions that we have for top three, whatever. Also, this is a very valuable contribution. Also, usually in this process, as we start to develop materials, even if you don't say, well, I don't want to actively write about it because I don't feel like an expert. Also feel free then to review this work. Say, hey, I understand this, I'm a bit unclear what you mean here. This is also super helpful. So don't overthink that your contribution must be to be like part of every meeting or to actively write something because eventually we do this for the wider community. And if you think, well, I'm not like necessarily understanding what you hear and they would need some other questions that I want to like get answered. That is super helpful as well. This is going to be a super challenging activity because as you can see here, there's like a lot of tags involved. So as Jennifer pointed out, it started in app delivery then we had network chaos. So that's how tag network got involved. And we had security chaos. That's how tag security got involved. If you think about it, tag security has another role because for chaos engineering, most of those experiments have massive access to the cluster. Like how can you simply kill parts or change network routes that do all those funky things that a case engineering tool can do? Like from a security perspective, it's kind of interesting. And then last but not least, tag observability got involved because you want to know whether your case experiment actually works. It does not work. So it is going to be a very interesting activity. The second one currently. So Jen, I would take this and then pass it over to you for the project if this is fine. I understood you're saying you would talk about this one. Okay. Yeah, so the cooperative delivery working group came about from considering the problems that we generally have when delivering applications due to the lack of coordination with infrastructure delivery. So what's the problem? Most commonly in application delivery scenarios, like the packaging format and the delivery mechanisms of the application artifacts are targeted, but not necessarily the applications infrastructure dependencies such as data stores, message queues, file storage, et cetera. And with the adoption of cloud native technologies, there has been a shift in landscape with applications now often provisioning infrastructure and as their dependencies with taxonomy to describe the infrastructure as resources, for example. So what does cooperative delivery mean in this context? Cooperative delivery is accomplished by describing the requirements for an application workload to operate within a hosted environment and provisioning components as they are required. And this domain includes the pipelining, provisioning and the distribution of necessary underlying infrastructure components in a new because but yet agnostic pattern to ensure that applications are deliverable in any appropriate cloud native ecosystem. We are looking at infrastructure and application like different delivery cycles, different deployment mechanisms and the dependencies across abstractions. The first goal of our working group is to understand how people are tackling this coordination problem right now and create examples. And so in the future, we hope that we identify the gaps that could aid new solutions. So all like again, community driven, identify the gaps, be able to inform everybody and show the examples that are used in the real world and then that's then maybe people can come with different new projects to solve those problems. So in under two hours now. Yeah, and you can see them in this example, there are lots of tools out there but usually they focus on one or the other aspect. So some focus on the application delivery, that's what you see in the right picture here like you have Argo, Flux, Captain, Spinnaker and then you have the more infrastructure focus tools like cross plane, Ansible, Pulumi and lots of virus. But how do we bring them together? How do orchestrate and coordinate this? So with all those challenges that that Jennifer brought up and it's really originated from some of the members of the working group just come in. These are the problems we run into things like I defined a storage class, it was there in depth but then it got deployed to staging or prod and suddenly it was no longer there or how to ensure that I run a newer version of an infrastructure configuration. How to ensure that prod gets updated with the infrastructure configuration before the application actually gets shipped. Like these are the type of problems we're looking into. So if you remember that picture that I showed you in the beginning, that's really when this layer three hits like the dark blue layer four and how this interaction between those two is supposed to work. Again, this is something where we are just getting started. If you feel that you have questions or ran into problems or found interesting solutions just get in touch with us and let us know. Doesn't need to be super formal, but let it know. Yeah, I'm taking this one because this is actually a funny and interesting one. Last year, KubeCon North America, I did a talk also as part of that delivery. You know, like there was this whole scene like the whole cloud native landscape that's getting so bloated. Nobody knows what to do. And I think all of you know all the different memes about it. And the whole idea was no action act delivery. It's great because you have all of these tools. You can combine them. You can even integrate them with each other. So the idea was to create a little demo application that showcases all of these different app delivery tools that are out there. So rather running their individual examples and having the examples that might just be starting in Nginx which is nothing against Nginx but not very exciting, have something else and also not having like a massively large application like Sockshop because quite frankly if you want to experiment and play around with it on a laptop you might run into resource constraints. On top of this going, we also wanted to build an application that's not so much focused on how you build your microservices but coming back to the scenarios we had in corporate delivery. Focus on scenarios like how do I do password management in multi-station environments? How do you handle configurations in there? How do I update in a canary deployment state for workloads? These are problems that don't require an application to be necessarily very complex from the core perspective but the scenarios that you need to handle from an app delivery perspective might be complex. That's why we saw Sockshop was not the ideal fit there. So we wanted to build something more lightweight and said, okay, we build a new application and what are you going to build as a microservice application? Obviously you use the Potato Head because that's a microservice application by design, right? Even existing multiple versions. So Potato Head is a project that we initiated from there. Then we thought it is, yeah, it's done. It's out there. And suddenly we saw people contributing more and more examples to it. And you see right now there's like a showcase for how to deploy an application with help, with customized, with sketch, with CAP, with flux, with Argo, with Captain, CNEP, with Porter, even offline, with Kubevilla, with Gimlet and more and more of those coming up as people are constantly adding them. Initially it was just like one very small services. Now like the individual body parts and so forth are individual services. Again, this was contributed by the community and is currently actively developed. And there are companies today who told us that they're using this, the Potato Head application to educate their teams on how they can use different tools or to easily evaluate them. So rather than like going to 15 tools, looking at their demo application, it's like this one spot where you can experiment with a demo application, which we will also use in other scenarios. And so far everybody thinks it's also a pretty funny way of doing application delivery. And yes, you can do really funny things. You can do cannery deployment. As you can see on this picture here, where the left foot is different from the right foot. And you would even see it here as well. And again, you can run it on your local machine. You can run it in a mini cube cluster and experiment with it because it's not really heavy. These are like tiny, tiny go binary study that you're running and that you can work with. Also, obviously if you're interested feel free to contribute to take one of those issues. So there's now constantly ongoing development on other, if you pick an example. Incubating projects. Jennifer, do you want to talk about the projects that we were working on? Yeah, so these projects, they have presented their proposals under the tag app delivery. Some of them have graduated to incubation already. So this is a little overview. It's like we provide some recommendations. We help them throughout the process. It's done by the TOC, but we like we give help whenever needed with the due diligence process. So they're currently incubating projects. Well, cross-plane has passed already at the time of this slide. So there is Dapper. There is Argo that's applying for graduation as well. Limitus chaos that's applying for incubation and captain as well. That's in like incubating phase. Yeah, so if you'd like to get more involved in any of these projects you can also review their proposal, pull requests on GitHub and show your support as well. That's like also helps them a lot. And yeah, like watch their, the presentations that they have on the on our tag meetings. Yeah, I think that's a very good point. So especially if you want to stay up to date on projects, the channel which we have five-weekly meetings is like super helpful because you see new projects that are presented. Also, if you yourself have a project, we also have presentations from projects that don't necessarily want to become a CNCF project but that some people have just worked on or a tool that you have worked on also feel free to come and present. So maybe you find people who are also interested in it find some contributors there, find other people who might be using it like we had, for example, it's a nice tool called Gimlet that was presented that came in like while contributing to Potato Head and I'm headed in as part of the meetings and then people got interested. And also if you want to like, will you see what some projects are doing for free to join our look at the recordings where we have some of this information available as well. And again, if you have something yourself that you find interesting also tell other people, hey, we're using your project you should be presenting there again. This is not limited to CNCF projects. If you're solving an interesting problem we have also every now and then presentation from projects that are not CNCF but that are doing interesting things. Yeah, and actually we want to hear from you from the community. So this is really an activity that we try to put out there for you. So what we want to do is we want you to share your application delivery stack. I think everybody can learn from everybody else how they built their stack. So if you think, okay, we have built something as I mentioned in the beginning that we found useful maybe do a 15 minute short presentation nothing fancy as part of the meeting so that other people can learn what how other people have built their stack what problems they were running into with how there's all certain problems. Also generally come and share your knowledge feel free to say, well, this is a question that I have this is something else so we can either join as I'll show in a minute our Slack channel or the mailing list or just come ask a question to start a discussion on Slack channel. You can help to contribute to documents as I mentioned, if you're afraid to write that's totally cool, you don't have to. Trust me, reviewing documents is in some cases a much harder job than getting the first version done. And people who review, contribute and help with this super helpful as well. And if you want to write code that is great to help us work on the examples. There's like lots of examples we're building and you will see that you're working with very interesting people from a lot of other companies. And it's like not that high entry barrier like into contributing to a complex project. It might actually be the project that you want to start internally at your company where you want to implement a certain tool or solve a certain problem. So start to build an example as either cooperative delivery as part of the potato head project and you have the ability to work with other people on it in a small and confined setting. And if everything works great you have a great example that you might even next year be presenting it at KubeCon. So really feel free to engage there and actively reach out to you so whatever concerns you. Where do you find us again? We have a great logo. Mr. Kangaroo. If you go to GitHub, on GitHub CNCF tag app delivery you find pretty much every information about when our meetings are happening charters of the working groups, documents like the operator white paper is available there. It's also a Slack channel for tag app delivery which I would recommend to join. There are also by the way dedicated Slack channels for the individual working groups. So if you're looking like for the cooperative delivery one for the chaos engineering one you will find dedicated Slack channels there as well so that people can have dedicated conversations as well. But if you just need help to find your way around to figure out how to engage here just let us know and we're more than happy to help. And I think with this we have theoretically minus three minutes for questions. I think we're done with the presentation. I don't know whether there are any questions online. Did we see anything? No, okay. No questions so far. Again, reach out to us on the tech app delivery Slack channel engage with us. If you have questions if you're building something interesting or have built something interesting we would love to work with you. Also if you think that like one of the working groups is a project that you might be working on in maybe half a year or so from now in your company that's a good way to kind of on the one hand learn build up a network of people who are actively doing it already engage with them and discuss with them your ideas and potential challenges. Yeah, and I think with this, Jan I think we're at the end of our talk today. Thank you for joining us late at night over there. Everything so unexpected, but all went all right. Very nice meeting you. Yes. It was well delivered from that point of view. So technology helped us here today. Again, applause for to Jen for joining us late here from Europe. Thanks all of you. I'm still here like for those who are in this room feel free to come over here ask questions. And for Jen, I think wish you a nice and well deserved evening and some time off and talk to you soon. Bye. Bye.