 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 party is 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 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 and 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. This was the start of a massive transformation at Amazon. And it all comes back to that API mandate. And they didn't stop there. Literally, they got really, really good at building services to the point where they started seeing all the architectural patterns around them. They started separating control from data and building common machinery for control, whether it's identity and access control and building frameworks for how people build these control planes that they're running and metering and billing and policy in a config store. All of that happened inside Amazon. And then they wrapped it all up into a platform API, a single API, for the entire set of services. And they built interfaces, lipstick I hear, on top of those APIs, CLI, SDKs, and a console they built on top of this. And cloud computing was born. They launched it all in 2006 as AWS. Literally, platform engineering led to cloud computing. And it's likely the largest success story in platform engineering. All right, it's 2024, 22 years later. Most enterprises, and despite the fact that everyone's building on cloud computing, most enterprises remain a jumbled mess of systems. Ticket ops, planning meetings. I need a database in Amazon. I have to ask someone to create a ticket. They send me credentials. I send emails. Literally, still a jumbled mess of systems. So what do we do about it? I think we need a new API mandate. Here's a refreshed, updated API mandate for 2024. It starts the same way. All teams must, must expose their data and functionality through APIs. Teams must communicate with each other exclusively through these APIs. But it's 2024. Please don't go build everything Amazon builds. Please don't. We've come a long way since. So number three, all teams must use Kubernetes and cross-plane. The machinery required to build these services that gives you the same power Amazon had when they were building theirs and refining their patterns. And don't waste time or money investing in your own machinery. It's truly a waste of resources, pun intended. No exceptions on that one. And the same way, anyone who doesn't do this will be fired. All right, so what does that actually mean? If you start with cross-plane and Kubernetes, you have the machinery required to expose a set of services that have well-defined APIs in your organization. It's this much YAML to define what an API is in cross-plane. We call it an XRD. And it's a similar amount of YAML to define what you want to happen when your customers call that API, whether it's to deploy a bucket or configuring or set up networking. That can happen without you having to build a ton of machinery. It's the fastest way to get going. And by doing this, you're leveraging the entire ecosystem built around the cloud-native community. You're using identity and access control and policy and systems that are built around this API, the Kubernetes API. You're tapping into a rich ecosystem where you don't have to start from scratch and work on your own. And then finally, you have to layer all your interfaces on this API. It's the same recipe that Amazon followed. And so I'll leave you with that. If you're building a platform, do it like Jeff did. Thank you.