 Good morning. Bonjour. So I'm Bessam Tabara. I'm the CEO and founder of UpBound. And I'm also one of the folks that started the CrossBlade project. How many here have heard of CrossBlade? Actually, not bad. Good show of hands. So I thought this is our first platform engineering day, and I was thinking about how to get us started. And I thought maybe a good way to start. Oh, you guys can't see my slides. Hold on. All right, let's go again. So I was thinking about how to get us started today. And I thought, why not start with what I think is, and maybe tell me at the end if you agree, the largest success story in platform engineering. Let's get going. I'm going to take you back to 2002. There was a small startup in Seattle working online book company in Seattle. And they had this really big initiative they wanted to go to. They wanted to transform themselves from being an online book company to a global marketplace for e-commerce. And their CEO, Jeff Azos, you might have heard his name, he recognized one thing. He recognized that there is no way that they could do this, given their current ID system processes and how they're organized. At that time, they had lots of different data centers. They were building all sorts of different systems. Each team was provisioning their own hardware. Every time they wanted to do anything, it required changes across a number of organizations and planning meetings and emails and tickets and craziness that happened. He described it as a jumbled mess of systems. And that if they didn't fix that problem, there's no way they can go through with that transformation. And so what did Jeff do? He wrote an email and sent it to the company that became known as the API mandate. Let's go through the API mandate. All teams will henceforth expose their data and functionality through service interfaces. What we would call today APIs. And that teams must communicate with each other through these APIs. And that no other form of communication is allowed. Very critical points that he's telling everyone here. He didn't care what technology stack you were using. At that time, this is a data thing. And you'll see he changed his mind on this later. But the final part was that he wanted everyone to make sure that these APIs were addressing a public audience, third parties, integration partners, et cetera. And if you didn't do any of this stuff, you'll be fired. Literally, this is the exact memo, an excerpt of the exact memo that Jeff wrote. Within two years, Amazon transformed itself. Literally, it went from a jumbled mess to organizing into teams that are building services with well-defined APIs for them. It didn't matter how these services were implemented. There was a ton of Perl scripting at that time, believe it or not. And tickets and things are happening inside each of the teams. But what they exposed was an API externally. So services emerged for compute, for storage, for networking. And then later, message hues and relational databases and caching and merchant systems and third party system, all these services started emerging inside the online book company, all with well-defined APIs around them. And the teams that were starting new initiatives, creating new projects, no longer had to go sit in long scheduling meetings and figuring out which hardware they need to deploy. They called an API to get compute. And they called an API to get storage that they need for their own initiative. And that created an unbelievable amount of flexibility in the organization and a separation of concern. Now teams can specialize. Not everybody had to understand storage. Not everyone had to understand networking. It also helped them with their hiring. They didn't have to hire experts in everything. They could actually get to a point where they have people that had to only work on the things that they actually need to work on.