Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2022, 1 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Composability is to Software as Compounding Interest is to Finance - Bill Mulligan, Isovalent

Description

Don’t miss out! Join us at our upcoming hybrid event: KubeCon + CloudNativeCon North America 2022 from October 24-28 in Detroit (and online!). Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Composability is to Software as Compounding Interest is to Finance - Bill Mulligan, Isovalent

The cloud native ecosystem is built of composable projects that can be stacked, recombined, reused, and built upon. This composability allows cloud native developers to iterate and ship functionality fast and creates compounding value to businesses from telcos to machine learning to gaming. This talk will trace the history of composability within the cloud native landscape from making Kubernetes pluggable and extensible through the CNI and CRI to standardizing observability with Prometheus and OTel to eBPF making security and networking composable with Cilium. Along the way we will discover how each interface and extension built the value of the project and the ecosystem as a whole creating a learning and business value flywheel. The audience will learn how the composability of cloud native has helped grow the public cloud, generated many successful startups, given meaningful careers to a wide variety of people, and why buying into composable ecosystems compounds business value.

A

Okay, um 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 I surveillance, working on both the ebpf and psyllium communities.

A

Now, as someone once said, that was much smarter than me. Compounding interest is the eighth wonder of the world. He who understands it earns it. He who doesn't pays it now, if you don't remember uh high school math, that much compounding compounding interest is when your money is making money and to give you a little graph of this.

A

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 with no compounding, because your money is making money on top of itself.

A

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.

A

Now I guess the part that I'd really like to point out here is the selected and assembled, because that is really what is we're gonna we're gonna 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?

A

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.

A

You know 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.

A

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 be a lot of value being created in the cloud native ecosystem.

A

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 is because I was standing on the shoulders of giants.

A

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?

A

Let's start with one project and look at the life cycle of this project.

A

Every single project is going to have a life cycle in terms of the investment that people the community companies need to make into it and it changes over the life cycle 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 it's commercialization, maintaining it and sustaining the project in the initial launch phase.

A

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.

A

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 in interoperability.

A

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 in the sustain phase, we have things like making sure that continues.

A

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 and user driven open source. This is the life cycle that we're we're talking about. Where we have a project.

A

Has end users that are using it in production, these end users create feedback, they create issues, they understand what the use cases are, which 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.

A

Once you have the developer community and the technology, the end users put it in production, they have things that wake them up at 3am 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 life cycle, 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.

A

So, let's add a second project now the question that 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.

A

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.

A

When you need to be visible, you already have an existing audience. 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 prowl for showing momentum, you can leverage existing projects, momentum! Think about how many tools here that you've seen in the past couple days, building on top of kubernetes attracting users there's already users.

A

They have problems, there's gaps in what is available and they they're. 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 you have. 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.

A

You can re-leverage the existing brand think about how many things we've seen with either a k or some type of c theme 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. You know 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?

A

The contributors are once again moving across these projects, uh people that have already worked together in the past are able to work together in the future. um Like 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 we can work together and that's a really important thing. This trust in the community, uh the rate as the rate of new features slows. You start to see these some of these gaps becoming new projects.

A

These things 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.

A

The 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 uh track all these across the ecosystem.

A

So looking at this kind of at like 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.

A

It combined it compounds tools and integrations through a stable release, cadence conformance and interoperability, and a security policy that people can rely on and it combines it compounds companies and profits by having products that are using the code, production users conformance and interoperability and long-term support releases.

A

So the composability in 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.

A

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.

A

These solid building blocks allow the innovation to move up the stack, so we can tackle new challenges and solve new issues, but so far this talk has 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.

A

This is. I found this on the internet. uh 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 uh 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.

A

This is also another slide from a cncf presentation. Looking at the storage landscape right, a lot of people had problems with running data on kubernetes and pulling from the slide deck from that era.

A

It's hurting the consumer experience limiting and 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.

A

At the time the volume plug-ins in kubernetes were in tree, 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.

A

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.

A

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, inter integration method, to work with common storage operations.

A

So this is five years ago and what's happened since then. um We see this. The container storage interface has become really the standard for exposing these storage systems. The 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 in tree reduce maintainer burden, increase security and a massive expansion, the number of potential kubernetes users.

A

If anybody's worked with businesses before trying to adapt, adopt cloud native, you know everyone has their own unique requirements. Everybody has they're 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 plugable system that people can select and assemble exactly what they need.

A

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 integration or a simple interface to standardize how networking is done in kubernetes and we're really seeing that today. uh As I said, I worked at, I work with the psyllium community and the standardized interface is allowing people to choose and swap their networking as they need um before.

A

A lot of people couldn't run psyllium 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 psyllium and they can take advantage of ebpf.

A

On top of that, psyllium itself is also a composable project for observability networking and security, and people can select and assemble the things that they need out of psyllium to solve their unique requirements. For instance, uh on monday, at the cloud native telco day, we had daniel bernier talking about srv6 and some of the telco specific networking use cases.

A

We also talk to customers that are running edge data centers in production, manufacturing lines that are trying to mesh their clusters together right. These are both great use cases but they're very different requirements, but by being making psyllium composable, they can choose the pieces that they need to satisfy their unique requirements and also ebp off itself is also making the linux kernel composable and programmable.

A

You can load in the 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 creating interfaces. It's also about bringing the community together.

A

In observability, there used to be two projects open. Well, there was a lot of projects. There was, but two of them were open census and open tracing. These two have combined uh into the open telemetry project, which is now actually the second fastest moving project in the cloud native ecosystem behind kubernetes. So by bringing the community together and uh assembling them into a new project, we were able to accelerate the development in the like massively important observability space.

A

We also have the api gateway, which was actually just announced earlier earlier this week by the envoy project, where contour and emissary ingress are going to be coming together and pulling from the blog posts that they just had. I didn't write this beforehand.

A

Was it's reducing duplicative efforts, layering value added functionality on top of envoy pro 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?

A

I would like to go back to this cycle again, but it's slightly different. This time we have projects lead into products, products leading to profits, and these profits are fed back into creating new projects.

A

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 their 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.

A

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 run book and different ways to help people get involved.

A

You should also, if you're interested on the business side of cloud native check out the cloud native glossary. This breaks down a lot of confusing terminologies or terminology that you may not have met before into specific business use cases into what it is, the problem it addresses and how how it helps. It's also now been translated into seven different languages.

A

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 buoyant a great shout out to them and if you're interested 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.

A

So thank you for coming today. Any questions.

A

Cool go catch. Your flight, then.