 I was thinking, you're talking a few minutes about complexity. We've been overloaded with complexity. But I think there is a recipe, and there is light in the end of the tunnel, I think. I have some ideas, and I'd like to walk you through them. I'm happy to get into some discussions in the hallway afterwards. These things are always best collectively, discussing and bantering. Starting with what we all want. We all want faster time to market. That's a given. Business requirements and needs are always pressing. Customers are becoming extremely picky. We need to get features out quickly. We need to do that with predictability, with repeatability, and with reusability. That's easier said than done. I think most here are probably developers or have been developers. These are things that we really cherish as developers. Some sort of determinism in how we operate, how we work, and how the system is running. But we also want cost efficiency. That's where Reactive comes in and all these things around. And also energy efficiency. Of course we want to be really good to the planet and all of those things. And today's infrastructure has gotten us immensely far. Today's cloud infrastructure is really, really good. It's mind-blowing. Put yourself back 10 years and think about how we did things without Kubernetes and Docker and all of these things. It was really, really hard. All of that is great. But at the same time, the ecosystem and the landscape has exploded the last years, which is good. But it also makes us completely drowned, being drowned in complexity. What tools should we use? How should we compose them into a single cohesive system? This image is actually taken from CNCF. I don't mean to bash it, but this image reads almost like a joke to me. How can someone make sense of what products to use here? And once we decided on the products and how they should all operate together, as we as developers know that things usually fall apart at the boundaries where we need to hand off things. And how can we guarantee that the single system will work cohesively inconsistency. Inconsistent. Even when load goes up and failure starts, it's waiting around the corner, etc. It's really, really, really hard. And most of that actually deployed to the cloud today are stuck maintaining all this themselves, many today. I mean, this means like low balances, ingress router, API gateways, caches, app frameworks, libraries, for building the app, event brokers, databases, usually many of these things to target different type of use cases. All of this is very hard. It can be overwhelmingly hard. And I was really happy when the serverless came out. The serverless as it was presented by Amazon Lambda initially. It really pointed the way towards the future. Really bright future, how I think all software should be developed for the cloud. But in a way, it sort of fell short. Many people today still think that function as a service is serverless and service is equal to function as a service. I think it was the first step on a long journey towards this, you know, greater developer experience for the cloud that we all want. But why stop here? You know, that's something I've been thinking a lot about and influencing a lot of the work we've been doing of life in the last years. I don't think there's no reason. Serverless should be all-encompassing. Should be everything that we built should be done in the serverless developer experience. And you know, it's getting there. Most products, or many, I didn't say most, but many cloud products today actually provide a serverless developer experience. Which is great. There is serverless databases, serverless caches, serverless event brokers, etc. But having each of these individually being serverless means that we're still, as developers left with an integration project, integrating all these serverless APIs into a single cohesive functioning system that we can trust that are predictable, reusable, etc. So it's actually, we're not there yet, so to speak. I really think that we can do better. What lies beyond the current incarnation of serverless? What is really the future of cloud when it comes to the developer experience and how we built and operate things in the cloud? Alfred North Whitehead's famous quote, I'm sure you've seen it before, already before, is really apt here, in my opinion. He said the civilization advances by extending the number of important operations that we can perform without thinking about them. This very much applies to us in the software industry. We need to continue to strive higher, to climb the ladder of abstractions. And we really need to be bold enough to let go of things that we don't necessarily need to need. We don't need to be able to turn every single knob. As developers, we feel safe, we feel that we are in control, and all that is great. But that's at the expense of time to market. And honestly, also at the expense of a really predictable system that can tolerate scale, etc. Because as the system grows, it becomes more increasingly complex. It just becomes overwhelming to be able to turn all the knobs. In my opinion, we have to let go and be bold enough to delegate this to others. To platforms, to products, etc. That will free us up to focus on the core value that we want to build for our business. What I really think is vertical integration. Stephen O'Grady, at Redmond, he wrote an article about that some time ago, that really sort of pulled together a lot of the things that I've been thinking about the last years, and gave you sort of a name. And he says, There are already too many primitives for engineers to deeply understand and manage them all, and more arrived by the day. And even if that was not the case, there's too little upside for the overwhelming majority of organizations to select, implement, integrate, operate, and secure every last component or service. Time spent on managing enterprise infrastructure is time not spent building out our own business. Building value for customers, etc. The last years we've been moving from on-premise. Ten years ago, almost everything was on-premise, like 15 years at least. And in this world, we have to do everything ourselves. That's like the red colors here. Everything from running the actual hardware throughout the stack, Kubernetes were perhaps not even around back then, but something similar. Managing the whole stack. And you still have to do that if you're on-premise. The promise of the cloud was to take care of a lot of that. Half of the stack. Now, if we deploy now on all the major cloud providers, hardware, virtualization, operating system, Kubernetes, and actually some other service on that level, it's all managed for us, which is amazing. But it means that all of the rest is on us. And that is increasingly harder and harder. Especially as pressure from business comes pushing down. So what we really need is full vertical integration. The platform is managing everything but the business logic. And Lambda, really, I'm a faction of the service. Google Cloud Functions, Azure Functions really show the way. But they stop halfway. They're not for general purpose type of applications. There's a whole other talk I've been giving on that, so I want to get into that. But it's really... We need vertical integration for any type of application that we would like to build for any type of use case, more or less. We'll always be specialized, you know, when you need a real-time, true real-time type of systems or whatever. But for the majority of us, this is what we want. We want to just build business value and go home, okay? So how can we do that? As Timothy Keller said that freedom is not so much the absence of restrictions as it's finding the right ones, the liberating restrictions, okay? So we need to embrace our constraints. But what are those liberating constraints for us as developers if we take that perspective first, you know? I really think there's three things that we as developers can never ever delegate. First is the API. We need to define how we present ourselves to the world, how we communicate with the outside world, how services that we build interact with each other, how they communicate and console problems collectively, microservices to microservices, subsystem to subsystem, okay? Secondly, we need to define the data model or domain model that represents the business value in terms of data for our use case, you know? How to model that or structure it. It guarantees its constraints, its consistency, guarantees on all of these things. And finally, the business logic. How you sort of operate on that data. As you get a request through your API, you want to operate and manage your data accordingly. It means like, mind intelligence, transform, down-sample it, et cetera. I mean, making sure that it flows, you know, in the direction it needs through workflow and PubSub and all of these things. But apart from these three things, I actually do think the rest can and should be managed by someone else, by a platform, because everything else is just boilerplate. It's just stuff that we need to do in order to be able to build value. I mean, these three things, okay? Oops. So this is, you know, what we've been thinking about and working in life in the last three years. We tried to embody that in Calix, in which we have built this fully managed developer API pass that really provides vertical integration as a service. You only have to focus on these three things I told you about. The rest is enough. Throw your app up and we run it for you. So it's a super streamlined, guardrail, very high level developer experience that is, I think, beyond serverless or beyond the current incarnation of serverless because it really brings together everything you need to build real general purpose applications in this new, like, vision of true serverless developer experience. It's fully polyglot, Java, JavaScript, TypeScript, et cetera. And it's, of course, reactive at its core. Our guy's running, you know, he's running underneath doing all the heavy lifting. Alongside Kubernetes, alongside, you know, databases that we all take for granted now in the cloud, et cetera. But you never need to care or worry about that because that's all on the platform. You know, I think Calix is actually, it's probably the first in this, but I really think that, you know, this is the way we will all build applications in the future. There will be many, many. And there's already, you know, a lot of, a lot of discussions in the industry about that. So in summary, I didn't have much time, but in summary, we all need to build, like, applications faster. We need to build them more predictably, repeatable, reusable. And we all need to, you know, being really cost efficient. Both cost, you know, actually, in terms of money, but also the traditional translates to being energy efficient and climate friendly, et cetera. And I really think that cloud development today, as well as Edge, you know, there's also something that we're thinking a lot about, is too complex. Serverless is extremely promising, but it has fallen short. Let's take that experience and provide it, you know, for any type of application. Continue to climb the ladder abstractions and force ourselves to let go of stuff that we don't necessarily need, but it feels good, you know, to turn, knobs to turn, okay. And Calix is here to help. As I said, you know, it's available, it's fully reactive, it provides a really high level to develop experience. So think about these things. If you're interested in Calix, check it out. Go to calix.io. I'd love to hear what your thoughts about my vision, about, you know, what I think cloud should look like from now and onwards. And what do you think about Calix? So thanks.