 Welcome, everyone. In this talk, we will give an introduction and deep dive into the app delivery tag. We will talk about who we are, what we do, and what progress have we made this year. Before we start talking about anything, I would like to introduce the speakers a little bit. I'm Hong Chao from Alibaba and serve as the co-chair of app delivery tag. My co-speaker, Thomas, from Dinerchase serve as the tech lead of app delivery tag. We also have leaders from working groups of cooperative delivery, chaos engineering, and GitOps. So what does our tag do? We basically have the CNCF TOC manages projects under the domain of app delivery, decides what projects go into incubation and graduation, and analyze their maturity level. We also write down materials about best practice and publish white papers about app delivery domain. So what's included in app delivery domain? The first thing is application definition. We need to define what an application means for cloud native platforms, how we can make abstractions on top of infrastructure and expose application-centric APIs, like how to make sure that the API matches the majority of our user needs, and more importantly, how to extend it with more APIs. We have seen open source projects like KubeVela, ArgoCD, and FluxCD are trying to provide such application abstractions and solve problems in this domain. App delivery also covers how to decide and develop applications. We provide best practice guides on how an application architecture should do and will fit the cloud native patterns. Modern applications decide if such patterns would benefit from the community and the cloud better. For example, DAPR has empowered modern applications talk to backend services easily. That includes open source components like MySQL, Kafka, Redis, and many other cloud services. App delivery also covers application bundling and package management. Today, we already have two top-level CNCF projects, Ham and BuildPak, to provide solutions to application packaging. But they have their own pitfalls and scenarios they don't fit. For example, in Ham, it couldn't provide me the needs to define delivery workflow. As new technologies keep coming up, we believe there will be new solutions that can address previous problems and being compatible with existing software packages formats. App delivery also covers the topics of delivery workflow. Kubernetes resource model is decorative, but the delivery workflow model is procedural and how to describe the delivery workflow on Kubernetes and how to manage workflow as modules and distribute them. So how to describe the delivery workflow on Kubernetes resource model and how to manage workflow as modules and distribute them easily. We have seen open source projects like TechCon and Teton Catalog are trying to provide solutions to such problems. But we expect to see new technologies come up as the landscape has been keep shifting. App delivery also covers config source-driven workflow. In other words, GitOps, how we can make use of the Git to provide delivery versioning and team collaboration. We will leave that later because we will have the GitOps working group to present more details. App delivery also covers release management, how to manage software releases, how to roll out new releases safely, how to do A-B testing and canary roll out. We have seen new projects trying to provide integration solutions for API gateway, service mesh, and DevOps. We already have well-known projects like Nginx and Istio, but new projects are coming up with easier, more lightweight solutions, such as LinkedIn, Con, et cetera. This diagram summarizes the areas app delivery tech covers. From button-up, Kubernetes provides infrastructure abstractions across clouds. It is this layer that cooperative delivery working group works to combine application and infrastructure resources. On top of that, we have a bunch of Kubernetes operators to manage workload operations. For example, we have CADR to handle auto scaling and scale to zero. We have open crews to provide fine-grained deployment upgrade policies. And on top of that, we start to have some user-facing interface. This interface lets user define how to roll out new application releases, how to do a canary roll out, how much traffic to be diverted to the new releases. So and finally, it hits the head of the whole architecture. The application per se. Here, it defines the application abstraction. It exposes only the APIs that application developers care about. This is what projects like Kugwella and Argo CD provide solutions. Then user would define their application in such a standard format. Choose like ham, let users bundle the manifest and distribute it easily. All right, that's all I have to talk about. Now I'm handing over to Thomas to talk about the progress we have made this year. Thanks Hong Chao and Heile everyone. My name is Thomas. I'm tech lead of the tech app delivery and working for Dynatrace. This year, three projects in the scope of the app delivery went to the incubation stage. The first one, Flux, is an extensible set of continuous delivery solutions for Kubernetes. The second one, Crossplane, is a solution to compose cloud infrastructure to be consumed by application teams. The most recent incubating project is Dapper, an application runtime which helps developers building distributed applications. We are always talking about incubation projects, but what does this mean? So many CNCF projects start the sandbox projects and get more and more mature at some point in time. While the entry barrier to sandbox projects is fairly low, the next stage, incubation, follows a bit of a harder process. To get to incubation, a full due diligence has to be performed. During that, it gets evaluated if a project is successfully used in production by at least three independent end users, but also if it has a healthy number of committers and enough documentation. We as tech support the TOC during this process. The TOC takes the decision if a project is mature enough to get to incubation or graduation. We are happy that we could assist in the incubation process of the three projects. Congratulations to them. Additionally, the tech delivered its first white paper about operators this year. This should give end users an overview about them in QAnitas, but also deals with operators beyond QAnitas. As we also wanted to tackle security-related issues in the context of operators, we asked our friend from Tech Security for help and it was pretty cool to work with them. This white paper provides an overview for people starting dealing with operators, but might also be a valid source for those who want to get deeper into this topic. The document should also be enhanced in the future and we hope to release an updated version with additional content. If you are interested, we are always open for contributions. The operator white paper has been achieved by a working group and the main purpose of this group was to define what an operator is. Currently, three working groups with all bringing light on special topics exist in the tech app delivery. Additionally, there's one project, the potato head, which is maintained by members of the tech. So that said, we will dive a bit deeper into the working groups. So I'll hand over to Josh and Robert who will tell you a bit more about the cooperative delivery working group. Thank you, Thomas and Hong Zhao. As we just saw, much of the work of the app delivery tag focuses on packaging up business logic and deploying it on infrastructure. But the revolution that we've had with cloud infrastructure means that now infrastructure services themselves, they're not servers and hardware anymore. They are defined and delivered dynamically as software, like the software that is your business app too. Now that the infrastructure is being delivered at software as well, app developers have to also coordinate the delivery of their business apps with delivery of software infrastructure so that the right infrastructure is there at the right time. And the app developers jobs are already complex. So to help them succeed, we believe we should at least try to make this cooperative delivery as simple and consistent as possible. So what we're doing in the cooperative delivery working group is developing patterns and practices that will encourage cooperation between your cloud native app developers and wherever they're getting their cloud infrastructure from. So like as an example, you're building a microservice, you need a data store or an event bus, we need the credentials so that you can connect to that and the address so that you can connect to that. We wanna make sure that that gets provisioned and published before your microservice starts running and looks for it. We wanna make sure another example that you get the secrets in your workload or the identities that you need. We wanna make sure that all of your apps and services get that observability capability. Some of the patterns that we are thinking of are how can we deploy infrastructure using a get-offs practice, for example, or how can you use projects like Dapper or Qvilla and the entire open application model to kind of bridge the gap between the developers and the infrastructure providers. But some of the first initiatives that we are doing right now is that we're trying to gather user feedback, see how people are trying to solve these types of issues out there now and see how we can help with that and also gather patterns and ideas in both code and on discussion on GitHub. We'd love you to join us. Come join our channel in the CNC App Slack. That's a great way to reach out asynchronously. Open GitHub issues with your ideas, with your code, with your feedback. And if you want to join our video meetings, we hold them the second and fourth Wednesday of every month. The exact time is in the repo. Thanks so much. Thank you, Robert. You need to... Thank you, Josh. Back to you, Thomas. So it seems like this is a cool working group for sure. And I'm very excited about the findings and progress of its efforts. Another cool topic area a working group is established for is GitOps. So let's dive deeper into this with Skalp, one of the co-chairs of this working group. Hello, KubeCon China. I'm Scott Ripi here to give you an update on the GitOps working group, part of CNCF app delivery tag. I co-chair the group along with Dan Garfield and Lita Marillo. Okay, so about the working group and open GitOps, the working group is an open group inviting companies and individuals to join and contribute to the community and the adoption of GitOps across the cloud native landscape. Please join us. That's what it's for and your participation is very welcome. The open GitOps project is a CNCF Sandbox project, which holds all the lasting programs, documents and code related to GitOps. That is the goal and seems to be working pretty well so far. Some announcements, just four announcements. The first is, well, I mentioned that the open GitOps project is now in Sandbox. It's guided by the working group and it's very active. Second is, we launched the website. Woohoo, it's beautiful, I think. It's interesting, it has information on it. Please go check it out, it's at opengitops.dev. The third announcement is that the working group, and this is my favorite one I think right now, released version 1.0.0 of open GitOps documents, which includes the GitOps principles and the GitOps philosophy. So special thanks to a lot of people that contributed to this 96 interested parties from 60 different companies that participated. Please see the release notes for more details, including individual thanks, and those are linked in the slide that will be provided later. One important note here is that this principle-led meaning of GitOps now establishes a foundation for interoperability between tools, conformance, and certification, and other things, just for all things GitOps. Okay, so finally just a little bit of housekeeping announcement. This is mainly so you know where to get info, the current updated info. We're currently in the process of moving files from the old working group standalone GitHub repo to the CNCF tag app delivery repo, and the open GitOps GitHub work, depending on which files are appropriate to which. So we're mostly finished with that. And in fact, by the time you're watching this, we may be finished with it, but I just don't wanna promise anything. Just in case we're not, make sure to go to the tag app delivery repo, click on the GitOps-WG directory, and there's all the stuff you wanna know. Also on the website. So, okay, so real quick, events. The first in-person hybrid GitOpsCon happened at the first in-person hybrid KubeCon ever co-located with KubeCon NA this year. It was a huge success. It was, we're told, the most well-attended co-located event at KubeCon. There was also, this followed on the heels of initial very successful remote-only GitOpsCon. That was also part of KubeCon, but you, earlier in the year. The next is that we had a GitOps one-stop shop that had major vendors speak about their GitOps offerings, which all use Flux in the case of this one event. Amazon Web Services, D2IQ, Microsoft, VMware, Weaveworks, and Red Hat. So plus amazing keynotes. I just wanted to note, including Brandon Burns, one of the original Kubernetes authors you may know, who talked about GitOps as an evolution of Kubernetes. There's a lot of other speakers. Please see gitopsdays.com for all the info. Next, I understand that our Gocon is being planned for this December. So please hit us up in Slack and ask Dan Garfield for details who's really leaving the charge on that one. But the whole entire working group is behind it. And finally, the working group is currently planning for GitOps Convalentia in 2022. I'm super excited about this and I'm looking forward to the third GitOps Con. They just keep getting better and better so far. Okay, so how to get involved? Join us in developing GitOps case studies, best practices, and other things that build on top of the principles that are now in V1. Help us plan GitOps events, if you're into that kind of thing, we have a really great team that does that. And help with the direction of the OpenGitOps project. So thanks very much, go to opengitOps.dev and see us on Slack, bye. Thank you, Scott, for this extensive overview about this very active working group. Oh, what's this? I think there's some uncontrolled chaos in the house. Think we need a working group for that, which is about to be established. Karthik, tell us more about it. Thank you, Thomas. Hello, everyone. Hope you're having a great time at KubeCon China. My name is Karthik. I am a member of the Chaos Engineering Working Group and maintainer at CNCF Project Litmus Chaos. At the outset, I would like to thank the app delivery chairs for helping curate this working group and giving us this opportunity to speak about it. Now, for some background. Chaos Engineering, the discipline has been around for nearly a decade, as you all know. But simply, it is about injecting random and unpredictable faults to stimulate real-world events and verify system behavior. This is typically practiced by SREs and ops folks as part of game days on production or production-like environments. That said, the cloud native paradigm has changed the way the apps are built, tested, shipped, deployed, and maintained. There are a lot of changes in the way infrastructure is viewed and managed. If you take a look at this slide, the pyramid here talks about the several layers at which resiliency needs to be enforced. You have the platform infrastructure, the Kubernetes services. You have a lot of tooling from the cloud native landscape that you've pulled in to help with seamless delivery and maintenance of your services. You have direct application dependencies like message queues, databases, et cetera. And then you have your actual application with its user-facing services, middleware, backend services, et cetera. And the surface area of failure is just that much more in a cloud native environment. So this has brought in a slew of requirements and challenges around resiliency and consequently, the way chaos engineering is practiced. Despite the fact that its actual philosophy remains the same. This working group aims to establish chaos engineering as an important practice and a go-to mechanism to enforce resiliency in the application delivery world by identifying trends, developing patterns, documenting best practices, highlighting user stories from the real world, all this while being tools and vendor-neutral. It is comprised of a diverse cross-functional group with members from chaos projects like Chaos Mesh, Ritmus Chaos, Chaos Blade, and others, members from other tags like security and observability, members from the practitioner and end user community who bring in a lot of insights and real-world experience. Areas that will be dealt with in this working group include core considerations such as the integrations into CI CD platforms, importance of observability hooks, security models, especially when working in multi-tenant self-service environments, operating within hybrid infrastructure. Organizations might have a mix of cubanities, non-cubanities, cloud, as well as unpromising infrastructure. This working group is today in the early stages. It has a dedicated Git repository that houses important artifacts, such as a conceptual or semantic glossary that can be leveraged by users that are beginning their journey into chaos engineering. A white paper draft which captures the state and practices of chaos engineering in the cloud-native world. User stories gathered by speaking to end users across different domains and organizations, et cetera. If you are interested, please join us and do contribute to this effort. You can help with enriching the glossary. You can help with improving the white paper. You can participate in the user interviews if you're already doing some kind of chaos testing or you have an resilience engineering team. You could also take the survey. It has a set of simple questions designed to capture chaos trends. Or you could just hop on to the chaos engineering workgroup meetings and just join in discussions. The working group meets every alternate Thursday at 8 p.m. specific time. The event is listed on the CNCF calendar. So you can just join and participate in the discussions and get involved, add yourself in the interested parties. I hope this was helpful and a quick insight into this working group. Once again, thank you. Thank you, Karthik. It looks like we get some really interesting material about chaos engineering in the future. Another side project of the tech app delivery is a demo application called the Potato Head, which has been introduced to demonstrate cloud native application delivery at the KubeCon Northern America 2020. In the meanwhile, a single service and a multi service application exist, which is being used for showcasing application delivery tools and packaging microservices. But also as a lightweight application for educational purposes to demonstrate microservice architectures. Currently, many demos have been provided by maintainers of projects like Helm, Catch, Argo, Cineb and Porter, Gimlet, Flux and Captain. We are always looking for new use cases like service meshes and stateful services. So if you would like to contribute some demo use case or have any idea how to extend the Potato Head, feel free to reach out. We want to get more insights about the things going on in the wild and we are close with the community and end users to help all of them establishing appropriate delivery solutions by creating content and discussing them. Many of you might have deal and spend a lot of time with a cloud native delivery solution. So if you have created a cool delivery stack and you want to share your insights, just contact us and present them in one of our tag meetings, happening each first and third Wednesday of the month. If you like to work with the working groups which have been talking here, just join the slack channels and attend the working group meetings. There will be interesting discussions and things to do and they're happy about everyone who is participating. If you're trying out delivery tools, you can use the Potato Head demo applications and the examples. If you think there's something missing or if something which could be improved, please provide these examples. We think that there might be many additional knowledge about operators which could fit into the white paper. So if there's something you want to share or you think it makes sense to be in the white paper, raise a pull request. Last but not least, we are happy about all of your ideas and your feedback. Just reach out to us in the Tag App Delivery Channel of the CNCF Slack. You can also find all of the information about the tag and its working groups on GitHub. Last but not least, one of our main communication channels is our mailing list. We hope that you enjoyed our talk. Got more information about our work and we hope we could encourage you to join and follow our efforts. Thank you for your interest in this talk. We are open for questions now.