 OK. Thank you for coming today to all the survivors. I guess I know it's been a very long week. And welcome to my talk. Composability is the software, as compounding interest is the finance. So I'm Bill Mulligan, and I'm a community pollinator at ISOvalent, working on both the EBPF and psyllium communities. Now, as someone once said, that is much smarter than me. Compounding interest is the eighth wonder of the world. He understands it, earns it. He who doesn't pays it. Now, if you don't remember high school math that much, compounding interest is when your money is making money. And to give you a little graph of this, if we invest money for 10 years, you can see it pays a lot more to be on compounding interest than just interest with no compounding, because your money is making money on top of itself. Now, we all, this is the business value track. And the question is, what is the compound interest of software? And if you haven't guessed from the title already, I would say that composability is the compounding interest in the software industry. But this is a long, complex word. What actually is composability? Let's start with the standard definition. So going from Wikipedia, composability is a system design principle that deals with the interrelationship of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements. Now, I guess the part that I'd really like to point out here is the selected and assembled, because that is really what we're going to focus on. Now, the question is, do we see composability in the cloud native ecosystem? Do we see things that we can collect and assemble into exactly what we want to satisfy our specific end user needs? This is a CNCF talk. So of course, the landscape is going to be here. And I would say, yes, that is where we have composability in the cloud native ecosystem. It has grown and grown and grown to a massive extent, because there are so many pieces that can be selected and assembled into exactly what you need as a business. And not only that, but we can see that it builds business value. One way to track that is just the number of acquisitions in this whole space. In 2016, we had two companies. In 2017, we had five more acquisitions. In 2018, we have a whole list now. Now we have half a page. 2020 is now the whole page. And 2021 is almost the whole page by itself. As you can see, there's a lot of value being created in the cloud native ecosystem. But why exactly is that? And I would argue it's because innovation builds on itself. Just as in compounding interest, your money is making money, the innovation is making more innovation. And we can see it through the course of the development to cloud native computing from non-virtualized hardware all the way to cloud native. And another thing that we like to say, if I've seen further than others, it's because I was standing on the shoulders of giants. The standing on the shoulders of giants is the innovation building on itself, building on projects, being able to select and assemble them. Now, why exactly is composability compounding in software? Let's start with one project and look at the lifecycle of this project. Every single project is going to have a lifecycle in terms of the investment that people, the community, companies need to make into it. And it changes over the lifecycle of the project. In the beginning, you're making a lot of investments into the project. And later on, you get to reap the rewards of that. And there's kind of four different phases that you should probably think about. The first is the launch phase, then is commercialization, maintaining it and sustaining the project. In the initial launch phase, you need to do things like get the word out, be visible, making sure you're releasing the code, show momentum, attracting user interest, adding contributors, creating the brand. And this is what gets the project initially off the ground. And it's a lot of work to do that. In the next stage is the commercialization. You're still seeing a very high-level investment, but there's a lot more momentum behind things. You actually have products using the code. You have production users. You have a diverse and stable contributor base. There's a steady release cadence that people can understand and rely on. The features aren't coming as quick, but it's good because it provides more stability for the project. And there's a beginning of the push towards conformance and interoperability. In the maintaining thing, you need to do things like having an established community with products, a conformance program, interdependency, and long-term support releases. This is when the project needs to continue, and people need to be able to rely on it. And finally, in the sustained phase, we have things like making sure that companies continue to support the upstream work, providing a long-term home for the project, and making sure that things like security notices and updates are continuing to do it for people that are still using the projects. And in CNCF, when we talk about end-user-driven open source, this is the lifecycle that we're talking about, where we have a project that has end users that are using it in production. These end users create feedback. They create issues. They understand what the use cases are, what the edge cases are, and they feed that back into the project so that we drive the project forward. Now, this is what creates a virtuous cycle in a single project because this feedback from the end user makes the project better itself. So for the project, once you have the developer community and the technology, the end users put it in production. They have things that wake them up at 3 AM. And finally, they have participation through feedback. Maybe it's issues. Maybe it's even a PR into things that they're looking for. Now, if we're not looking at just a single project, but a whole ecosystem, like for instance, Cloud Native, it's not just a single lifecycle we're looking at. It's really a whole collection of life cycles that we need to look at and understand to understand why the composability is important. So let's add a second project. Now, the question I'd ask is, where do we put the curve? Do we need to make the same whole investment all over again? But no, it's not the same investment twice. Now, also going back to some high school math, what it's more similar to is the area under the curve rather than the addition. You can build on top of the existing community momentum and tools and life cycles that you already have so you don't need to make the whole same investment twice. And this is why ecosystems like Cloud Native become so valuable. In terms of the composability of projects, when you need to be visible, you already have an existing audience to tell your story to. That's why if you look in the sandbox, there's so many projects there because there's so much momentum and there's such a community around Kubernetes and Cloud Native right now. In terms of releasing code, you can reuse tooling for things like prow. For showing momentum, you can leverage existing projects momentum. Think about how many tools here that you've seen in the past couple of days building on top of Kubernetes. Attracting users, there's already users. They have problems. There's gaps in what is available. And they are looking for solutions to their problem. I mean, just go walk around the vendor showcase right now. For adding contributors, people have feature requests and gaps that they have. So people are naturally attracted to solving their own issues. It's the whole virtuous life cycle that we saw before. And in terms of creating the brand, you can relavage the existing brand. Think about how many things we've seen with either a K or some type of C themed to build on the Kubernetes ecosystem brand. For the commercialization, there's already an existing user base who are using it in production and they need to solve their issues. Think about simple things like debugging or security for Kubernetes. How many companies do you know in just those two spaces? For the diverse contributor base, the contributors are once again moving across these projects. People that have already worked together in the past are able to work together in the future. I know if you saw me before this talk, I was talking to some of our great ambassadors. And it's because we know each other and we can work together. And that's a really important thing, this trust in the community. As the rate of new features slows, you start to see some of these gaps becoming new projects. These things that people want and need may become projects by themselves. And once you have conformance and interoperability, you really have a stable base for other projects to build on top of. I mean, think about how many things are built on top of Linux because it is almost a universal computing platform now. In the maintain phase, we have an established community, but also contributors and users can move to these new projects. The stable core is allowing new projects to build on top of that. And you have security policies and bug tracking so that you can track all of these across the ecosystem. So looking at this kind of at a high level of where these fall into, composability compounds the ideas and identity of a community by helping things be visible, creating a brand, showing momentum, and creating a diverse contributor base. It compounds people and community by showing momentum, attracting interested users, adding contributors, and having an established community. It compounds tools and integrations through a stable release cadence, conformance and interoperability, and a security policy that people can rely on. And it compounds companies and profits by having products that are using the code, production users, conformance and interoperability, and long-term support releases. So the composability and software isn't just about the code, but it's about all the other things around the code, too, that can be reused across an ecosystem of projects and products and companies, the ideas and identities, the people and community, tools and integrations, the companies and profits. So let's look at this thing again, except for instead of this time looking at a single project, we can look at many projects as the ecosystem as a whole. So the developer community and technology around all of our projects is being used by end users who put it into production, have problems with it, and feedback, whether that's into the existing project or creating new projects on top of that to grow the ecosystem and expand the cloud-native landscape. These solid building blocks allow the innovation to move up the stack so that we can tackle new challenges and solve new issues. But so far, this talk is really just focused on the theory of this. You've seen some graphs that I just colored by myself. What does it actually mean in the real world? And can I actually prove this? Well, the simple one is where we are right now, KubeCon CloudNativeCon. I found this on the internet. The website for the first KubeCon in 2015, as you can see, is a very simple and small thing. If you haven't seen, it's expanded a little bit since then. We now have co-located events on Monday and Tuesday. They're covering everything from security, wasm, telecommunications, to GitOps. As you can see, it's not just about Kubernetes anymore. The innovation is moving up the stack and the challenges are moving up the stack to expand into all these new categories, too. Going back to 2017, this is also another slide from a CNCF presentation. Looking at the storage landscape, a lot of people had problems with running data on Kubernetes. And pulling from the slide deck from that era, it's hurting the consumer experience, limiting in cloud native use cases because people are afraid of running data on Kubernetes. And there really is a lot of value by being able to run those stateful applications on top of Kubernetes. And so we need to have a way for applications to be able to make use of those storage resources. And so what the community did was come together and look at this. At the time, the volume plugins in Kubernetes were entry, which means it was challenging to add support for new volume plugins. Because all the vendors that wanted to do it had to align with the Kubernetes release cycle. All this third-party code created reliability and security issues, especially if you weren't using any of the plugins or you wanted a different storage vendor. And a lot of the storage systems weren't available. So for the maintainers, it was creating an almost impossible burden where they couldn't test or maintain any of the code that they were shipping to the end users. So if we want to make a composable system, we need to provide components that can be selected and assembles to satisfy user requirements. And so the ecosystem came together and created the container storage interface. And it provides a user experience where end users have a single integration method to work with common storage operations. So this is five years ago. And what's happened since then? We see the container storage interface has become really the standard for exposing these storage systems. All the vendors can implement and update what they're doing independently. And it's removing these third-party code and dependencies from Kubernetes itself. For the ecosystem that's resulted in over 110 CSI drivers, which would be almost impossible to maintain entry, reduce maintainer burden, increase security, and a massive expansion in the number of potential Kubernetes users. If anybody's worked with businesses before trying to adopt Cloud Native, everyone has their own unique requirements. Everybody has the same until you have that one thing that's different. Oh, we can only run this on Dell. We can only run this on pure storage. This is all that we have in our data center. This is all that our Cloud provider is providing. By creating a pluggable system that people can select and assemble exactly what they need, we've increased who is able to use Kubernetes and the value of the whole ecosystem. In the same way, at around the same time, we also had the beginning of the CNI. So the CNI is the container networking interface. And it was also a simple interface to standardize how networking is done in Kubernetes. And we're really seeing that today. As I said, I work with the Cilium community. And this standardized interface is allowing people to choose and swap their networking as they need. Before, a lot of people couldn't run Cilium yet because it's based on EBPF, which requires a newer kernel. And a lot of people didn't have that kernel available to them. Now as we've gone five years later in the ecosystem, that kernel is more available. More people have access to running EBPF programs. And they can switch easily from something like Flannel to Cilium. And they can take advantage of EBPF on top of that. Cilium itself is also a composable project for observability, networking, and security. And people can select and assemble the things that they need out of Cilium to solve their unique requirements. For instance, on Monday at the Cloud Native telco day, we had Daniel Bernier talking about SRV6 and some of the telco-specific networking use cases. We also talked to customers that are running edge data centers and production manufacturing lines that are trying to mesh their clusters together. These are both great use cases, but they're very different requirements. But by making Cilium composable, they can choose the pieces that they need to satisfy their unique requirements. And also, EBPF itself is also making the Linux kernel composable and programmable. You can load in the programs that you need at runtime to modify the behavior of the Linux kernel to meet your specific requirements, whether that's something like XTP, the Express Data Path that speeds up networking, or other things like Tetragon that's providing security enforcement. Whatever your unique requirements are, you're able to do that now with EBPF. But it's not just about standardizing and creating interfaces. It's also about bringing the community together. In observability, there used to be two projects. Open, well, there was a lot of projects. But two of them were OpenCensus and OpenTracing. These two have combined into the OpenTelemetry project, which is now actually the second fastest moving project in the cloud-native ecosystem behind Kubernetes. So by bringing the community together and assembling them into a new project, we were able to accelerate the development in the massively important observability space. We also have the API Gateway, which was actually just announced earlier this week by the Envoy project, where Contour and Emissary Ingress are going to be coming together. And pulling from the blog post that they just had, I didn't write this beforehand, was it's reducing duplicative efforts, layering value-added functionality on top of Envoy proxy, and more potential users, allowing more use cases, feeds a virtuous cycle of more potential customers, and more support for the core Envoy project. Exactly what I was talking about, and this is a blog post, but written by someone else. But this is on the project, the technical, the code side. What about the businesses? I would like to go back to the cycle again, but it's slightly different this time. We have projects leading to profits, and these profits are fed back into creating new projects. We still have, on the project side, the developer community and the technology, the code. But these are then transformed into products, whether that's an enterprise distribution or a combination of multiple products together into something that companies can sell to the markets, whether that's a specific vertical market or a platform. And these profits allow companies to participate back in the ecosystem, sustaining existing projects and creating new ones to meet their customer needs. So composability compounds, ideas and identity, people and community, tools and integration, and companies and profits. If you'd like to learn more about getting involved in the cloud native ecosystem, I recommend checking out tag contributor strategy. And also, if you want to learn about how companies grows, this is another example of composability in the cloud native ecosystem, where they have guidance for projects for things like a community ladder, a runbook, and different ways to help people get involved. You should also, if you're interested in the business side of cloud native, check out the cloud native glossary. This breaks down a lot of confusing terminologies or terminology that may not have met before into specific business use cases, into what it is, the problem it addresses, and how it helps. It's also now been translated into seven different languages. I'd also recommend checking out the CNCF landscape guide. You can find this on the cloud native landscape. This is some great work done by Catherine and Jason from Boyant, a great shout out to them. And if you're interested in more generally in the business of open source and how open composable ecosystems make money, I would highly recommend Open Source for Business by Heather Meeker. This is probably my favorite book that I read last year. So thank you for coming today. Any questions? Cool, go catch your flight then. Thank you.