 What makes Kubernetes or cloud native so complex? So when it comes to complexity of Kubernetes, I'd say, well, first of all, the foundation of Kubernetes is container scheduling and container orchestration. And if you want to operate workloads that are big enough, container orchestration gets fairly complex. It's just a complex problem to solve. So there's a certain lower barrier of complexity in Kubernetes that's just unavoidable. However, the container orchestration part of Kubernetes has its complexity in implementation, but it's hiding that under wonderful abstractions. And it makes it fairly simple for people to use. So the application developer experience isn't dominated by that complexity too much. So you can still express, still get applications and services to run without having to deal with all the possible options to do that. So I think they did a good job here. But what increases complexity over time is less the problem of running one single Kubernetes cluster, but it's more dealing with a lot of Kubernetes clusters. And that's definitely inviting some complexity, especially because you rarely run a Kubernetes cluster as it is. But instead, there's a growing ecosystem of Kubernetes extension. So the ability of Kubernetes to be extended by custom resource definitions and controllers has forged Kubernetes to become the framework for building cloud automation these days. And so that ecosystem with a lot of possibilities in extensions, that's adding another layer of complexity. And if you combine all these things, you'd have a lot of Kubernetes clusters. Each Kubernetes cluster may look different. And that's a complexity that also affects the operations because it creates a lot of operational friction if you don't apply best practices and automation in a rigorous way. If you look at the complex, if you look at ecosystem because sometimes technology come in and the ecosystem matures and then the focus shifts to the users. And we are talking a lot about developer stories these days. Do you see that this complexity will go away? Or you think, no, complexity is here to stay. What we have to do is make it simpler so a lot of folks can start, I mean, they're already using it. But they can consume Kubernetes and all these clouded technologies in much better way. Well, first of all, when it's about complexity and dealing with complexity, I'd say about Kubernetes on its own that the solutions out there to deal with Kubernetes, they became more mature over the years. So that reduces complexity in the sense that it becomes simpler to bootstrap Kubernetes clusters. You don't have to have that expert knowledge right away to get your hands on a Kubernetes cluster. But at the same time, by adding more features to Kubernetes and adding more extensions that are in demand regularly, any Kubernetes offering also requires a certain amount of popular Kubernetes extensions to be there. And then we enter slowly an area that's not as developed as you may think, which is lifecycle managing more extensions and managing multiple extensions in a graceful way. Again, I'm looking at that from the perspective of running a lot of Kubernetes clusters. So if you think about most extensions, they'll give you the ability to apply, let's say, YAML specifications as one way to install them. And then there could be another package manager. It could be a Helm chart. Or it could be an old M package or anything like it. But the question is, if you want to run a lot of Kubernetes clusters, and there are so many different ways of lifecycle managing Kubernetes, if the YAML specification layer is not what you want, then the question is, which tools do you want to use, and how good are they? So when it comes to data service automation, which is one of our passions, we've tried several of those lifecycle management tools, for example. And none of them is really suitable to cover it all. And even if you accept multiple of them to be coexisting, it does not feel as easy as it should. So I think that's an area of ongoing development, is if there are more extensions, how to deal with them gracefully and guide those extensions through their lifecycle gracefully. Because in the end, application developers, they will set up a cluster once, develop their applications. But when their applications develop, they also have to lifecycle manage all the extensions these applications depend on. So it will be essential. Like when using libraries in your code, like do you have a good package manager that complexity management and dependency management is in general a hard problem to solve. And I think it's one of the bleeding edges in Kubernetes these days, especially looking at a large number of Kubernetes clusters. With a good CI and CD pipeline, you can manage the lifecycle of a single cluster with a few extensions with ease. But at scale, large organizations, that's a different story.