 Hi, my name is Liz Rice, and I'm the chair of the CNCF's Technical Oversight Committee. At the last KubeCon back in November, I made some predictions, and I thought today we could check in on those predictions and see how the technical landscape is evolving. And I'll be joined by my TOC colleague, Harry, who will give us a deep dive into the trends we're seeing in cloud-native developer experience. For those of you who are new to the CNCF, let me just briefly explain what the Technical Oversight Committee is. We're a group of technical experts elected by the Governing Board, end users and project maintainers. And we set the technical direction of the foundation. You can find out more about our role and our activities on the CNCF website. To help us in our mission, the TOC works with groups of experts from across the community in different domains within cloud-native. These groups have, up until now, been called special interest groups, or SIGS. But there have been groups called SIGS within the Kubernetes project for a long time. And we've been finding a lot of confusion between CNCF SIGS and Kubernetes SIGS. So to remove this confusion, starting from after this KubeCon, the CNCF groups are going to be renamed to technical advisory groups or TAGS. Let's look at the different domains that these TAGS cover. Runtime is about running workloads, ensuring that application code gets executed in the cloud. This includes projects like Kubernetes, which handles the orchestration and scheduling, as well as container runtime projects like Container D and Cryo. Cloud-native applications often need to save and access data, and that's covered by the storage tag. Security is about keeping workloads and data safe. This tag looks after security-specific projects like Notary and Falco. But it also helps other projects across the CNCF with recommendations for improving security. The network tag covers projects that allow workloads and control plane entities to communicate with each other. Once you have applications running in the cloud, you need to be able to see their status and troubleshoot issues, and that's covered by the observability tag. App delivery is about bridging the gap between a developer writing code at a keyboard and that code being packaged and delivered as an application that can be run in the cloud. And then finally, contributor strategy is a special case in that this tag isn't involved with the technology of projects, but more about the way that projects run. This tag helps projects run effectively and grow their contributor base. Setting aside contributor strategy, we can look at how projects are distributed across these different technology areas covered by the tags. If we look at the more mature projects in incubating and graduated status, we can see they're distributed fairly evenly across these major areas. The fact that all these areas have mature projects corresponds to the fact that there are thousands of end-user organizations running cloud-native applications in production every day. But what about the future? If we look at the distribution of sandbox projects, we can see there is experimentation and innovation across the board, but some areas have more activity in the form of more numbers of projects. At the last KubeCon, I mentioned we made those predictions about the areas that we think are going to be significant in 2021. Six months later, let's see how those predictions are shaping up. We talked about Chaos Engineering, Kubernetes for the Edge, Service Mesh, WebAssembly and EBPF, and Developer and Operator Experience. Now, you'll find talks about every single one of those areas at this week's KubeCon. And there was a co-located event on almost all of these topics, so there are clearly technologies and topics you're interested to discuss. But are we really seeing these technologies manifesting in the form of cloud-native projects? Let's take a look at how these technology areas map to projects in the sandbox. So we've now got two sandbox projects in the realm of Chaos Engineering testing the resiliency of a system in the event of failure. Three projects are underway that relate to running Kubernetes at the Edge outside the data center. Four sandbox projects relate to Service Mesh. We have one EBPF-based project in the sandbox, but it's worth noting that there are incubating and graduated projects now innovating with these technologies, too. We're also aware of a lot of WebAssembly runtime projects that have been speaking with the runtime tag. But by far the area where we're seeing the most experimentation, at least as measured by the number of sandbox projects, is Developer and Operator Experience. Making it easier for developers and operators to build and run cloud-native applications. We've got 11 projects in the sandbox working in these areas. So let me hand over to Harry to explore some of the trends in these areas. Hi, thank you, ladies. Yes, so I will continue to talk about the trend of cloud-native from application development and deployment. Yeah, this is right, that the new trend of cloud-native is in trying to make sure that developing software be very easy on cloud-native stack. And this is actually enabled by a widely adopted pattern which is known as Sidecar pattern on Kubernetes. It's really important because Sidecar is essentially a small container that is running alongside of your application container. So in that case, it will handle all the inbound and outbound traffic of your application. In that case, the application does not need to really care about how to handle this traffic. It just focus on its business logic, which is the most valuable for developers. And on the other hand, if a structure such as Kubernetes and platform engineers will use service mesh and similar technology to handle the traffic part by leveraging the proxy system enabled by Invoy. In that case, your application will be able to focus on its own thing and letting structure handle all the traffic management, security and observability parts. And what's more important, with projects like Dapper, now you actually have another power to even to consume the cloud resources and services based on Sidecar. So in that case, your application can just talk to local host to consume a cloud resources, for example, at Redis. And this also enable you to deploy application to anywhere regardless where is this cloud resources, whether it's on AWS or Google Cloud, it doesn't matter. It can even be a local maintained Redis instance because your application only talk with the local host and let this Sidecar to handle the rest of the resource consumption as well as service binding by leveraging the Dapper runtime. And this is new chain and this is really game changer. We call that it is the local host oriented programming because application now really need to care about, really don't need to care about the dependencies, the external resources, just the focus on your application deployment. And speaking of the application deployment, it's actually another chain that a clone native is trying to make it easier. Because we already saw there are a lot of platforms tools that are trying to fix this problem because, you know, deploying application is really, really matters if you want to have a consistent way to maintain your software. But if we also notice a change is that these platform tools are not trying to create a new abstraction on top of Kubernetes or trying to give you a restricted product. They don't need to do that because they're leveraging new technology, which is so called the X as code. So in these platforms, the capabilities of the deliver system are defined as code, the main specific language or template. So they are categorized as a renewable component that these actually enable developers to assemble them into application deployment and then deploy software to this to Kubernetes or any kind of infrastructure. And this confidence of deployment is then in turn maintained by GitOps workflow or by Kubernetes controller itself. This is early game changer because in that case, no application deployment will never cause something like configuration drift, which is normal, which is a normal issue in the traditional infrastructure code system. This will never happen in Kubernetes. And this essentially make your platform to work and grow where your application needs grow. There will never be restrictions in capability, there will never be restrictions in abstraction because everything today is programmable. We see there are a lot of existing projects that are trying to make this happen. For example, Kubevela from Alibaba, CD Kubernetes from AWS, and there are also more and more yet to come. This is the world and the chain we're calling that programmable application deployment. Speaking of deployment, the developers are not just want to deploy and they actually want to deploy continuously. That's why we have continuous delivery in the CI-CD pipeline. But in the clonative world, CD pipeline is also being making more easier and more efficient. And we call this clonative CD, which is actually enabled by a pattern which is GitOps. GitOps is actually a natural extension of a Kubernetes control loop because it gives a way to maintain the consistency between desired status, which you maintain in the GitHub repo, and the real-world actual status, which is running instances in your cluster. And Git is a tool that you maintain this kind of workflow by just doing whatever you are familiar with, like pull request, send out issues, commit a change. This is all what's happening by trigger a GitOps deploy workflow. And GitOps actually give you the way to have consistency and accuracy in an automation of deployment so you can do it repeatedly. And you are using the tools which your developers are familiar with. For example, Git, nothing new you need to learn. And this also enables you to build highly extensible deployment workflow. You don't need to have something like traditional pipeline to do that. You can just use InventDriven to do this if you want, because Git is actually a very common, widely used event source. And in this case, you have much smaller attack surface because your application cluster, for example Kubernetes, they will use a pull model instead of a push to make sure that everything works in the target cluster. This is GitOps. This is how Kubernetes is trying to empower your developers to deploy and continuous deploy software with a consistent and with a confident approach. So you can see the chain in Kubernetes is very easy to understand now. In trying to make sure that developing software, deploy software, and continuous deploy software, they're easier with high efficiency. And there are a lot of projects that are trying to make this happen. We see that Argo CD from Intune, we see there is already Flux CD from VWorks. We see there are a project named Keaton from DynChance which can give you more power to do observability and use observability metrics to drive your workloads. This is a new chain of the clone native we're talking about. And I will then hand over to Liz to talk about the next step of clone native. Okay. Thank you, Liz. The common theme here is that a lot of innovation in cloud native today is centered around making things easier. As Harry has just shown, there are trends towards making it easier to develop and deploy applications. And across the broader cloud native landscape, there are initiatives and projects underway making cloud native easier to secure, to test and to debug. Let's talk about a few more trends that we're seeing. Quite a few of these new projects that make things easier are being brought to the foundation by end user organizations. Companies like Spotify, Lyft or Capital One. The projects they're bringing address problems that real users come across in real life situations as they adopt the cloud native approach. Another trend we're seeing is towards projects that make it easier to run cloud native applications anywhere. Hybrid cloud and multi-cloud are real. Public cloud vendors have embraced this and give you options for running workloads on-prem just as they do in the cloud, making it an easier transition to the cloud or between clouds. And we're also seeing projects that help manage your infrastructure, whether it's bare metal or distributed across clouds. And there are projects helping you manage security across these boundaries between clouds. And of course, as we've already noted, Kubernetes is running at the edge and for many new applications. Cloud native networking functions are an area of innovation in the world of telecoms, where they have completely different requirements for characteristics like latency and jitter, compared to handling web requests that many of us are familiar with. Another area that lends itself very naturally to running in the cloud is machine learning. Organizations are renting compute in the cloud to handle massive amounts of data and to train their machine learning models. So it makes sense to leverage cloud native approaches for these kinds of applications. And we expect to see more projects in this area coming to the CNCF. Another theme that we're seeing is the emergence of what I'm calling project ecosystems. I'm sure you're aware that not all CNCF projects are alike. Some are massive, like Kubernetes. And these large projects are starting to become the center of their own ecosystems of projects. For example, we have several projects in the sandbox working on custom resources and controllers that aren't part of core Kubernetes, but there could be very valuable in a variety of use cases. These ecosystem projects only make sense in the presence of the larger central projects. And we'd like to find ways to help CNCF participants navigate their way around these project ecosystems more easily. Cloud native is in a great place and the growth of our end user community goes to show that together we're building the technology that enables applications to run successfully in the cloud at any scale. Even though many of our projects are mature and in large-scale production use, there's still a lot of room for innovation in the world of cloud native. The CNCF is centered on open source community projects, but we want to see healthy business ecosystems around those projects with vendors large and small able to build successful businesses. Competition is healthy. We see it between projects and between vendors and competition encourages innovation. Collaboration is even better. We love to see competitors coming together to tackle a common problem. And enabling that collaboration is why the CNCF exists. There's opportunity for all of us in the world of cloud native. Thank you.