 Hi everyone. Well, this is pretty special to be here in Paris, in France, especially because it's here. I would love to see who here is actually from France when raising your hands. OK. All right, so it's really special because I'm French. And I was telling my friends, oh, it's going to be so amazing we're going to share this moment with the French cloud native crew. And then they said, they're not going to know you're French because you don't sound French. So I thought I would read a little quote from a French artist. A really profound quote just to share what's in my heart with all of you. It's in French, I apologize. I hope that's OK. And I'll translate it after. OK, I'm going to stop here. So the English translation is, it's all about the people. Or you can just ask a French person next to you. OK, so I'll stop joking around. Or not. Really, it means there's so much for me to be here with all of you because we're all platform people here. We have a difficult job. Our job is to help other people make their dreams come true while we toil away in darkness, making everything work. And it's a difficult job. It's a rewarding job. I love that job. So yeah, I think we got so much done in the last 10 years and more. And I want to talk about that a little bit. What we've achieved and what we can achieve still in the future. So it did start here in France, at least for me. I think maybe not everyone here knows this. But actually, within walking distance of here, in my mom's basement, is where we got the first working build of what you could recognize as maybe one day docker. And yeah, we were just a painted picture. We were nobody's. We were young losers excited about this weird technology for some reason. There were a lot of exciting things going on in the world of technology. We were not part of them. Nobody knew about us. Nobody cared about us. But we were just excited. We had a lot of time. So we started building things. And just to set context for what was going on at the time. This is 16 years ago, by the way, 2008. We got this first working build, just to paint a picture. 2008, cloud. The word existed, but it was this new kind of dreamy thing. Serious people did not run serious applications on the cloud. That was not a thing. And if you're into systems programming and platforms like I was, which at the time meant racking servers, the really exciting word for me was infrastructure. This concept, that was a really bleeding-edge word at the time. And it blew my mind this idea that instead of deploying one server at a time, probably by hand, and then having a developer deploy their application of that one server at a time, you could take all the servers and combine them into sort of one big computer, and then somehow the application would sort of consume all of it. And if a server goes away, blah, blah, blah, you know all this, but at the time it was amazing, an amazing idea. And nobody knew how to use this for applications. There were no tools. So I thought that was really exciting, to create tools for this new model for applications. And we didn't know any of the best practices at the time, because, again, no connection. And so we're just sort of building weird tools that we thought were exciting in our gut. And so the technology that attracted us was what we now call Linux containers. But it wasn't called that at the time. I think it was called lightweight virtualization, Linux virtualization. And it was very new in the Linux world. It existed in Solaris. Ask if someone here, Solaris people, Sun people? Yeah. Well, we did containers before you. You did. You did. But Linux did have lightweight virtualization. You had to patch the kernel. You had vServer. You had OpenVZ. And people did that. We did not invent that. People did that in production. It was a nice trick if you had big farms of servers. But it was a way to virtualize your machine. So it was a spectrum. Do you want to use VMs? Heavyweight virtualization, which was also pretty new at the time, or lightweight virtualization? It was all in the same plane. It was all about trade-offs, faster, more strong isolation. And what we wanted to do, let's take this container tech and stack it on top of VMs, because we thought it could be units of application virtualization. And that's the part that people thought was very weird, because it would be like running a VM inside a VM. Why would you do that? It's like a cool hackathon project, maybe. But we thought it had more potential than that. So it involved things like patching the kernel twice. Once for VMs, you had to apply Xen, for example. And then once for vServer, OpenVZ. And you had to find the right combination of patches. And so it was just really janky, weird stuff. And then if you want containers to be an application deployment unit, you need to bring in other technologies. You need a copy and write file system. You need some way to manage these images, not at the block level, but at the file level. And you need a way to track changes to them, move them around efficiently. At the time, what we did was we put the whole file system in source control. Not git, but mercurial. Remember, this is 2008. And yeah, we managed the state in CouchDB. So we had a very 2008 stack. It was already in Python, because Python is making a comeback now. Anyway, very weird. No one cares, by the way. Did I mention that? Nobody cared. Meanwhile, the industry, the real computer industry people over there in America, were kind of converging towards a way to do this, a way to deploy applications to the cloud. And they called it pass, platform as a service. And the idea was you choose a winner. You choose the best compute, the best storage, the best build, the best application runtime. You just bundle it all together in a black box. And then developers send the code, and it takes care of everything, and it's beautiful. It's the cloud. And you just got to pick a winner. And then the PASWAR started. Because of course, everybody wants to be the winner platform, the one platform that's going to run all the applications on the cloud. People really believe that would happen. We believe that would happen. And we thought, well, we could do that, because containers are good for this. And so we started this Pascal.cloud. And we were competing with the giants like Google App Engine, and Heroku. And we were in awe, starstruck, but still competing. And our approach was, well, we think the most modular platform will win, the most customizable platform will win. And containers are great for that, because you can have multiple. You can easily swap out application runtimes, databases, et cetera. We ran all of it on containers. And then we realized, OK, this is not going to be enough. Because even the most modular and customizable platform in the world will just not be modular enough, because this is just too big. There's just too much choice, too much diversity. It's all of the software, all of it's going to the cloud. And it's growing, software is eating the world, et cetera. And so at some point we realized, OK, we're definitely not going to run all the applications to the cloud, because we were like 10 people. But no one is. It's too big. And so we thought, OK, this container thing, maybe we could build an ecosystem around it. So of course, the rest, this part of the story is better known. We pivoted to Docker. And then did our best to convince everyone to use it? And somehow they did. And then I think you heard the rest of the story earlier. But really this approach to modularity, the fact that the way to solve this is to rebuild all of the infrastructure around a unit, a fundamental primitive that everyone can then compose and choose how they compose. That was the key. And look at us now. We're there, right? 10 years later, we have this ecosystem. We have all of the things, all of the components, all compute, all storage, all everything. Just rebuild around containers. And then all you have to do is just pick everything and just assemble the perfect platform. This is one problem. If you're a developer, the experience is not great. It's actually less good than in the past days. If you were lucky enough that your application did fit in Heroku or Google App Engine, life was good. You push the code, you forget about it. And I think some developers kind of missed those days. And some of you are thinking, well, my platform is just as good as Heroku, I billed myself, et cetera. But maybe. But it's just not the average developer experience. So this is where I think as an industry, we have to be careful because the temptation is to go back and say, you know what? Paz was actually not that bad. Let's just do it again. Let's pick the best of everything now. Let's bundle in a black box. And then let's just say, that's the platform that's going to run everything. And you just can't do that at the scale that we're talking about here. You can't run all of the applications that way. You can't standardize on that. So we're just not done. We have to somehow figure out a way to get the best of both worlds. We've got to embrace and own this choice and diversity that we have now with this crazy huge ecosystem. But still, we've got to give developers a great experience every time. So I spend a lot of time thinking about that. And my favorite analogy for this is factories. So the physical world has actually figured this out. It's just us and software still working on it. If you're designing a great physical product, you're also designing how to manufacture it at the same time in an integrated way. When Apple designed the Macintosh, they didn't do everything, finish everything, and then go to the factory and buy a factory at the factory store and say, hello, I'd like a factory. I'm going to manufacture a Macintosh. It's a completely integrated process every step of the way. You choose components. You think about the price, the sourcing, the manufacturing process, the partners, et cetera, et cetera. And that's the model that we should follow. And a natural consequence of that is that every factory is different because it aligns perfectly with the product being manufactured. And it's natural if you think about it in a physical world. So I think that's our model. We need to approach this as a manufacturing problem. And that means if you're building a software project and it becomes successful, you're going to have to own the factory that ships it. It has to be you. No one else, you can't outsource that. And some people do that already, but here's the other thing. It also has to be, as agile, a process to improve continuously the factory than it is to continuously improve the application. And that's where I think we have a little bit of work to do because when I talk to people, say, I have my internal platform, we built it, it's awesome. But you spend a year building it. And next year, there's going to be a new thing that you have to incorporate into the app, maybe an AI feature, maybe. And now you're going to start another 12-month process and spend half a million dollars rebuilding a new factory. It's not sustainable. You just need to do this the same way you do with applications. Continuously rapidly iterates the product and the factory. So I guess my message is, it's OK to own the factory. You have to do it. But you have to set a higher bar at we. I have this problem, too. We have to set a higher bar and think of it as an integrated process. So that's mostly what I wanted to tell you. And the last thing I want to tell you is the same friend who said, they're not going to know your French. Also said, you talk about the AI. So OK, I'm going to talk about AI because, thank you, friend. No, it is relevant because I spent three amazing days with all of you. By the way, please come say hi at the dagger booth. That's the tiny booth in the back, all the way behind the docker booth. I would love to talk. I would love to talk about this with you. Yeah, but one topic that came up a lot in these conversations was, well, is AI, we're the cloud and everything. It was hot 10 years ago. But now we've grown older, we have gray hair. We're the legacy now. All the cool kids go to the AI conferences. And I say, that's a mistake. You are wrong because those AI is software. AI apps are apps. And guess what you need to ship an AI app? The same thing you need to ship any app. You need a factory, you need a platform. You need this group of people. We're going to ship these apps for the years to come. And now's the time to think about, OK, how do you improve the factories to do that? So I think this is the most exciting moment for the platform community since the containers, the whole new generation of apps to ship. So we've just got to figure out how, of course. But yeah, we'll figure it out together. So that's it. Thank you so much for having me. Merci.