 Hi, my name is Thalys and it's now time we talk about pizza delivery, serverless and efficiency. As a developer I have, like most of you, spent many late nights staring at the screen feeling both unproductive and hungry. I would like to propose based on some personal experience that serverless can help reduce the development and delivery inefficiencies like pizza delivery did to the homemade pizza meals. I'd like to take you back to the early 2000s when my development troubles started. Before a release I needed to get the basic ingredients required to verify my application's functionality and performance in a near realistic environment. Back then I had to run my own mock services, database, messaging and security components just so I can achieve this. So what did I do in order to get the ingredients to cook a new release? Well, I ordered them. I opened tickets for a database server. I may even have to make calls for the procurement of software and hardware since they came in CDs and boxes back then. Well, they almost though never arrived on time. After many years of inefficiently building and releasing applications, we tried containerization and look all these beautiful containers I could fit now into my MacBook Pro. I no longer needed servers and it improved the time of testing and releasing hot into production. No more late nights needed. Well, not for a couple of nights at least because as developers, apart from baking images with our machines, we also need to run tests and have the latest and greatest features from IDs to almost anything. And let's not forget, the corporate security team also needs to ensure there are no leaks whilst we try these new cool features. Result? More delays. After a while, we learned about resource managers, Kubernetes, which were promising solutions to have an instant development environment. We could run as many components as we needed within minutes. And best of all, it was all free. Only it was not at all free and we had to explain CPU and RAM overutilization as well as the hefty Amazon Web Services build that followed. Once more, getting a development environment became complicated and we were back on for some more late nights. I recall once that incident where after creating and tuning our own development environment, its performance was so poor which meant I had to stay developing in the office past 8pm most evenings. Incidentally, this was the time when the lights changed to motion detection mode and I had to do a bit of a dance every now and then just to keep them on. Now the lights, although annoying, they were quite efficient I thought. So why couldn't my development environment be the same? This is when I learned about serverless with Knative, which in summary offers the ability to spin a service and only keeps it available for the period it receives calls. Knative will remove it when it becomes idle. On a new development on top of Kubernetes, I had the opportunity to test these efficiencies changing my services to serverless. With Knative serving, I could have three microservices, a database and a security service only available when a call came through. So normal explanations about CPU or RAM utilization and normal late nights waving arms frantically. But what happens when you want one of your serverless components to always be available, like a database, which takes time to initialize, while calls have to be answered immediately. Also, it's shared nature means that you need to tune for concurrency. So I looked it up and serverless offers annotations for the definition of concurrency and auto scaling during serving. Also with serverless, once I had a version of my components delivered, I could work on new revisions of them and then choose if I wanted to send requests to all available ones or simply drain and remove the old ones. Serverless routing even allowed me once I chewed on a not very nice revision slice to revert back to an early one. It made me even more efficient when I decoupled the services, which originally were integrated by direct risk calls. Transforming to serverless events meant that the source and sync did not need to know about each other's details. And so messaging slices would arrive magically at the correct destination. Serverless had made me a more efficient developer like pizza delivery had done to the late night pizza meals. So could try serverless at gate native.dev. It's efficient. Thank you.