 Awesome and thank you very much. Very excited to be here and essentially talk about what's a platform and this quote that I've got following this that it's essentially that thing that you're speeding slash developing on. So to get things started, just a little bit about myself. So you know my name is somebody you can find me on most places online is just that summary. You know, I've been working in this industry for over two decades. You know, I've had a lot of different positions, you know, in that time done everything from, you know, software engineering as an individual contributor to working in the platform infrastructure and reliability space. I've worked at previous companies like Airbnb Uber and Twilio and I'm today now in the VP of engineering at upbound. So if you go back a little bit further in my background you will see that I've also got a string of startups and you know businesses that I've tried, you know, and, you know, had some successes with and some failures over the years. But you know there's been one common thing throughout my entire career and it's this notion that I've spent, you know a lot of time basically building internal platforms and it's one of the big reasons why, you know I wanted to do this webinar is to really just kind of share, some of my thoughts, you know, and anyone that knows me knows I'm always constantly sharing my thoughts. And then an interesting fun fact about myself. I am an electronic music DJ and producer. I used to do it a lot more when I was younger. In fact, I often refer to my time, you know as an individual contributor as essentially living like a Superman slash Clark Clark Kent life. What I mean by that is that basically I would spend my days writing code, you know, and shipping things and I'd spend my nights and weekends actually traveling and DJing. Obviously I don't do that so much anymore as I've gotten a little bit older and you know started a family but you know it's definitely a very, very interesting time in my life so just a little bit of a you know interesting facts about summary. Now I'm going to quickly go over the agenda and what we're going to cover today. And you know I really have this belief that platforms, you know kind of have this storied history, you know there are things that everyone kind of knows things they know what it is, but you know but you ask 10 people, and you'll get 10 different answers as to what a platform actually is but I really do think that platforms kind of often evolve out of necessity and they're not necessarily created or designed. And so I do want to spend some time today, you know really trying to unravel this a bit more and understand why so you know we're going to start off I'm going to, you know, define some terms so well, we'll start off defining what a platform actually is from the summary perspective, you know and then I'm going to tell some of my own stories about replatforming that's a term I'll define as well too. Then we'll talk about the natural evolution of a platform and you know how that leads to replatforming. And that really you know one of the big lessons that I've learned over my my career is really about abstractions and making sure that as you built these platforms why creating the right level of abstractions is so important, and essentially doing this quote unquote, all the down, and then we'll summarize everything at the end, and we will have a q amp a at the end so I have allowed some time to take some questions I love answering questions, but we'll save all of those for the end. So if that sounds good, you know, we're going to go ahead and jump right in. If you, anyone that knows me knows that I always like to start like a talk or a presentation with really defining terms and really making sure that we're all on the same page and you know starting from the same page. So, let's start with defining what exactly a platform is and I'm going to start by actually telling a story here. So, anyone that's from California and specifically Southern California, you know, probably remembers from the 90s the series of commercials that were always on TV, and the commercials were by a company named freeway insurance, and the commercials always ended, you know, what's a freeway, you know there was a couple of hunks, and it was hey it's that thing that you're speeding on. And so when I think about platforms, you know, it's almost like the same thing sort of pops into my mind where you know freeways are always these things that we're always driving on you know we we use them especially in California to get from point A to point B, you know they're ubiquitous like they're essentially everywhere. Right. And you could not imagine, you know, living in Southern California, you know without using freeways to essentially get around but most people never really take the time to think about them. You know, again it's just part of life. And so that freeway insurance commercial always made me think hey, you know when someone's actually thinking about a platform in the essence it's similar to a freeway it's just that thing that you are developing on. It's ubiquitous. It's always there it gets you from point A to point B. And a lot of times you don't even realize you're on one or that you're speeding and you know going 100 miles an hour. So let's start with the first term that I wanted to find and I've actually went online and I did a little bit of research here and I kind of pulled together some definitions from a few different places. But really, you know, somebody's definition of platform is really like this bullet point number one, you know, and it's an environment where software is executed. It's seen as a constraint or an aid to the software development lifecycle, and ideally it's going to abstract the underlying complexity in which applications are consumed and run. And so, at a very core level. That's what I think a platform is right. What about replatforming though, you know, replatforming is this notion that, you know, you often start out with a single version of a platform and then it kind of evolves and iterates over time. And it's usually the result of the increased complexity required for your engineers to be productive so generally over time, especially if you start out of startup and you build sort of version one of a platform. You'll notice that as you hire more engineers and as that company grows, you know the complexity of that platform that you probably didn't even set out to build but you actually built indirectly starts to increase and so you really start trying to look for ways to kind of reduce that complexity, and ultimately, you know, make your engineers more productive because at the end of the day, you know, productive engineers ship codes and features and functionality that really enable the business, you know, to make money, right. And so this notion of replatforming really is about, you know, starting to think about things like self service provisioning and deployments for engineers again reducing the context required to build deploy and operate services and not just deploy. You know, potentially put build deploy and operate, because a lot of times we deploy a services and then we operate them for years in production, you know, and that is a part of the platform lifecycle to. And then again this third point it's really about abstraction of the underlying complexity of all these different vendors that you're probably interacting with, you know, manage services and providers as well and so I think of replatforming almost as an opportunity, you know, because you generally set out not starting to build a platform, you kind of learn a lot along the way and then you decide hey there's a great opportunity to sort of evolve and replatform. So now here's kind of like a graphical representation and maybe even simplified form of a platform, you know, and again, this is an environment with which abstracts the underlying complexity at which applications and infrastructure are consumed. And so kind of going from the left to the right, you know, you've got your engineer on the left side. Generally, your engineer does not actually care about the underlying components of the platform. And, you know, some of you may actually disagree with that but I'm going to say this is most organizations is probably true for 80% of engineers. You know, they are there to basically, you know, write features and ship code, you know, for your core product and so really their main interface, you know, to your platform is essentially like a set of interfaces. And so, you know, everything in this essentially this green box, you know, consisting of things like workflows applications and infrastructures are all things similar to the freeway that enable, you know, your platform. And so the way that your engineers are actually working with things are primarily through these interfaces. You know, taking a step back from that though, I want to actually maybe define a couple of other terms here as well too because, you know, at a certain point in my career, you know, the cloud started becoming ubiquitous. You know, everyone originally thought the cloud was about virtualization. And if you remember some of the early cloud providers like that's all they were talking about. But I really did think the cloud back in those days where it really was about sort of these API's and automation, right where we really started to see the industry, you know, evolved from this, this notion of if you've heard the Cattles versus pet analogy, where we were really starting to think about everything that we did, you know, more as cattle and not as pets and automation was a huge part of that. But actually challenge anyone. If you go back in time and really look at what was going on, you know, was the early stage of the cloud really about virtualization. No, I don't think it was it was about automation. And it was about essentially, you know, these API's that the cloud provider started giving us that allowed us, you know, similar to a platform to have all these different interfaces that interacted with that API. You know that again abstracted away all this underlying complexity, but you know now allowed us to really start to do some amazing things really started. You know if you remember back in the day, you know we were configuring physical hardware and oftentimes it would take weeks or months to set up a new host. And now you could essentially do that with like a single API call, and it was like a game changer and so we've definitely seen the cloud, you know evolve over that over that time and you know I'm kind of picking on AWS and using them as an example here. But now again similar to our platform example, you've got these interfaces on the left, you've got a strong API in the middle, which is backed by you know an awesome control plane. But now that you've got this centralized API you now have the ability to build out all these centralized management services. And so these include things like centralized security, and policy and billing and monitoring logging, you know the whole nine. And now as we've seen over time with these cloud providers they really started launching more and more services, you know backing them anyone that's used AWS and ever, you know, logged into their console, kind of intrinsically understands this as well. So, that's a definition of a cloud or a public cloud. So, the last thing I'm going to define here is essentially a cloud platform. And this is more of like a thought exercise and anything because I really do think that we're moving to this world where you kind of want the benefits of both you know we've talked about a platform it's that thing that you're speeding slash developing on. We've talked about all the wonderful components of a cloud. And a lot of that is really like the strong API is an automation that you get with that as well. And so if you start thinking of maybe this future thing, you know, called a cloud platform it's really this, you know, it's this construct that kind of makes you the best of both worlds and kind of reading from my definition here, you know it's an environment providing organizations with self service applications and infrastructure, and a single point of control that aggregates across everything that they do. And so, I think this term cloud platform is something that you all are going to hear a lot more and more about, because it really is about combining the best of both worlds and I'm going to talk a little bit more about this later. I'm going to spend some time defining some terms. So now I want to dive a little bit more into this notion of replatforming and what that entails and so again anyone that knows me knows that I love to tell stories. And so, I'm going to tell three stories here of things that happened at companies that I have worked at in the past. I intentionally changed the names to protect the guilty. But I've already noticed some of you on this webinar. Some of your former coworkers as well. So I think it'll be pretty easy to kind of figure out some of the companies that I'm talking about, but I digress. So let's talk about story number one, and you know replatforming example number one. And the interesting thing about, you know, this replatforming example is many of us can probably relate, you know, to breaking up the monolith. You know, and generally if you work at a startup or a smaller company, you know you don't actually set out to build a microservices architecture you generally start out with one code base and one monolith you start building upon that you start hiring more engineers. You eventually get to a point where you realize that you've got so many engineers, you know, working on this sort of single code base or project that it's really starting to slow down their velocity. Now, the interesting thing about this example is at the time, I don't think we actually thought of breaking up our monolith as replatforming. We were just breaking up the monolith. And, you know, hindsight is 2020. But, you know, at that point, our monolithic application was used by close to 1000 engineers. And, you know, it was an absolute train wreck, in terms of getting features fastly, you know, deployed or quickly deployed out to production. And if you can imagine, you know, this many engineers all working on essentially one code base, you know, and everything that that in Intel, you know, you can you can just start to imagine some of the problems that we were having and so we set out to break up the monolith. And we did a couple of things. One is, you know, we created a framework that made it very, very easy to create and launch new services because we wanted folks to migrate their code out of the monolith. And so this was a great thing to do in practice. But because we reduce so much friction here, we very quickly went from a world of one monolith to a world with thousands of microservices. And this was absolutely crazy. And because, you know, we weren't a bit more thoughtful when we, you know, started out this work, you know, who's to say we needed thousands of microservices and not hundreds, you know, or even dozens, right. You know, we just sort of made this process easy. We made it really easy for folks to launch these new services. You know, and so, you know, our engineers definitely took advantage of that. Now, one of the things the big takeaways I actually think from this story is, I actually think it was both a success and a failure that we made it easy for folks to create new services. Because once we reduced all that friction and I believe the SLA around creating a new service before them was probably like weeks. It's been a while, but once we reduced all that friction, folks really took advantage of it. And similar to when I was talking about the cloud earlier, and it really being about not about virtualization but about automation. This was like a prime example of us showing that we were actually like in folks way. You know, it was actually more important for us to make it really easy for engineers to deploy these services, you know, on their own and to self provision, but you know, we could have also provided a bit more guidance and structure, you know, as we did this as well. And so the interesting thing about this and my third bullet point here is, you know, part of this process meant we deployed all these services without any like SLAs or service level agreements between teams. And so it meant that if you were a team, and we made it very, very easy for you to deploy a new service, then if you had a dependency on another team, it was often easier to just like fork that teams code base into your own service, like, you know, build out any additional functionality that you needed yourself, and then, you know, launch that as a new service and run that yourself as well. And so, you know, this is definitely something that folks did and it actually took us years to unwind sort of this decision and actually kind of bundle things into slightly larger quote unquote domains or blogs or you're starting to hear these terms like pop out in the industry a lot as well. Example one number one of replatforming breaking up the monolith, we did not think of this as replatforming at the time though we did really just think we were breaking up the monolith. So my second example and this is probably something that a lot of folks are going to be feeling familiar with as well, especially as we're starting to see Kubernetes get adopted more and more in the world right now is essentially moving from Docker to Mesos and like the migration that that entailed, you know, and so this actually was another form of replatforming, even though we were only focused on the compute part of the platform. Right. And you know a lot of folks can remember we very quickly evolve from like Docker to to Mesos to Kubernetes and you know you're really starting to see, you know our compute technologies, you know, iterate very quickly right now. I mean we essentially did this at the company to all of our engineers as well, but we also changed a lot of other things while we were doing it and again, we did not look at this as actually replatforming. We just thought hey you know what we're just changing the compute layer of our organization and so there's a couple of things that we did, you know that essentially forced a lot of toil on our engineers. One, you know at that point in time all of our engineers actually were writing puppet configs themselves. So, we basically forced them to just switch from puppet to Docker. Now, you know, using Docker was obviously a little bit easier, but there was still a lot of constraints and we still require folks, you know to go through these migrations to essentially do these translations from puppet to Docker, you know, and then very quickly after that, you know we forced another Mesos migration on top of them as well, which required a little bit less work to do but we were, you know, pushing content or toil onto our engineers. One of the things we realized here is that our engineers actually didn't care about like our compute underlying compute technology again, but they were just focused on moving quickly and shipping code to production and shipping fee features for our product. And so by us kind of doing these rapid migrations and iterations, you know, again, we force a lot of toil onto these folks. We also missed the opportunity here because we were a little bit myopic and just, you know, iterating on the container and orchestration capabilities to kind of make our services a little bit more portable to make it so that these things could actually run from anywhere, and we're so close tightly coupled, you know with the core technologies and underlying technology that we were using. So that's example number two. Now my third example. This is the one config or one ring example. And this is probably the example that's closer to replatforming in the sense that we did sort of know that we were iterating on our platform, and we did approach this this problem essentially saying like hey, you know what, we don't want engineers to require context across you know and understand like 50 different tools or services to be able to deploy something in production and so in this example we actually did set out to build a unified configuration format for provisioning and operating microservices. And the idea here it was, it would abstract away all of the underlying complexity from all the tools that were actually required to make that a reality. So, we introduced our own configuration lamb language in YAML, and literally every single person on this call is probably doing something similar today we're all inventing our own configuration, like YAML and Jason based formats. And so we were no different at the time. Again, as we were going through the three platforming exercise, you know, we again introduced a lot of toil onto our engineers, we didn't actually make this migration. Easy for them to do and it was a migration. They actually had to do a lot of work to kind of validate that their services, you know, could migrate safely in the process we actually use. We actually changed the abstractions that we were using. And so this meant that we actually broke things after engineers had shipped things into production, because we realized we didn't have the right abstractions or interfaces. You know, and again this just introduced even more toil and more frustration, you know, onto the organization. And then, you know, we, you know, YAML is great. It's also very verbose. And, you know, part of us changing some of these abstractions were essentially trying to, you know, reduce like some of that verboseness of these configurations and making it a little bit easier for engineers to kind of understand like, you know, when they were changing things, you know, what was happening, you know, underneath. And so this again resulted in a lot of toil from the organization. But this was actually one example of us replatforming where we did sort of understand, you know, what we were trying to do. And we were intentionally trying to evolve the platform. So those are my three stories. And in each of those examples, except for the last one, you know, I've repeated this several times already, but we actually didn't realize that we were replatforming and we were, we were iterating on our platform. And it was really important that we sort of that were not myopic when we do that, that we don't just focus on solving one tactical problem, but we actually use it as an opportunity to envision, you know, that thing that you're developing and speeding up like what's that actually going to look like over time and how can we further like reduce the context for our engineers like required to do their jobs. So, there's this concept I have called the emergent platform. You know, and it's really this notion that if you're going to change the underlying component of your platform, and it forces a migration and toil on your engineers that you're doing it wrong. You really want a platform that from day one has the right level abstractions so that as you iterate on those underlying components, you can, you know, change them you can change underlying technologies without sort of forcing work onto your onto your engineers and this is why, again, designing the right abstractions which we'll get into a little bit later up front is so important. And so there was a couple of things that you know points that I wanted to outline from the previous example. One is you know really this focus on tactical work, blinding us to the opportunity that we had to replatform in front of us. You know, the second one is not really having a holistic view of how our changes we're going to impact that overall developer experience or platform experience and this is something that even to this day. I think a lot of companies are, are, you know, really bad at, because when I say developer experience, it's not just building, it's not just deploying but it's also operating over the end to end lifecycle of your service or feature in production, and everything that entails and at many companies today that can be, you know, work that's the spread across hundreds of services and tools, etc. And so you really do want to take the time to take a step back and you know view, have a holistic view of that into an experience. And then the third one is really, you know, if you're going to replatform if you're introducing new technologies, you actually should be reducing complexity and context, not increasing it. And so this is always an opportunity when you're replatforming, you know to essentially do this as well. So I've kind of talked about replatforming a little bit and I've used these past three examples to talk about that but I actually want to take a step back and you know kind of holistically look at just one way that platforms, you know, evolve over time. And so I'm going to use like a typical startup as an example, where, you know, you can almost think about version 1.0 of a platform as a startup as the thing the founders built in a weekend or the thing that the early employees built in a weekend. You know, when you're when you're iterating on a startup, especially in the early stages, you know, it's more important to validate all these hypothesis that you have and really iterate on them quickly than it is to focus on, you know what things might look like three or four years out, because you don't know if your lunch is going to be there next week. And so it's more important to iterate and move very quickly. And so this is a big reason why for version 1.0 of platforms. They're designed, they just kind of get cobbled together, and they very quickly get iterated on over time, you know, the early employees at a company, you know, kind of jump in and have a big part of sort of driving the story. But again, you know, especially at an early stage startup you're moving so quickly, you don't really have time to be thinking, you know, years in the future. And you'd almost be irresponsible if you were doing that as well, you know, focus on the now, you know, validate the concept you can always iterate later. And that's generally what happens with version 2.0 of a platform. And generally, version 2.0 often happens when, you know, a company it's probably in series B or series C or even D land, where the company starting to grow very quickly, you sort of nailed your, your product and your product market fit and your go to market strategy. You're starting to see your sales like ramp up or, you know, your users and adoption ramp up relatively quickly. And now you're starting to realize that hey all those decisions we made in a weekend, when we built version 1.0 of our platform. You know, now all of these decisions are coming back to on us now, you know, we've got a bit essentially scale the platform up as fast as possible, you know, to meet this increase demand we have with users and, you know, customers, etc. So generally with version 2.0 of a platform now, you know, you're essentially evolving and scaling this thing up quickly, you're figuring out wherever your bottlenecks are and just focused on like improving those. But again, you often don't have the time to take back take a step back and take a holistic look at essentially what you're trying to build and, and what you're trying to do. And then that gets us into version 3.0 land and version 3.0 of this platform is this is generally the opportunity that all of us should be taking to replatform to really take a step back and really envision that end to end developer experience across the bill deploy and operate, you know, life cycles really imagine what that's going to look like for years really imagine, you know, how are we going to reduce our engineers complexity how are we not going to force migrations on them. How are we going to enable our underlying technology to keep evolving over time, you know, and, you know, introducing best of breed solutions, etc. And so generally when you're jumping from version two to three, take this opportunity to replatform take this opportunity to really design the thing that you're building. So, one of the things I actually wanted to call out here is often when we're setting about to actually sort of do this. You know replatforming and introducing new technology it's an opportunity to actually introduce new technology, and really to see, is there a better way, you know, of doing the thing that I'm trying to do. And I 100% believe that that's true today. And I think as we think about building platforms and replatforming in the future, you know the underlying component and the thing that needs to change and improve is you know, let's evolve from using infrastructure as you know to build out our all of our platforms, let's now move into the 2020s, and you know essentially what we're calling like the era of the control plane. And I really do think control planes are sort of the next revolution of technology and building platforms and managing applications and infrastructure, and I'm going to talk a little bit about why I think that that's actually the case. So, first of all why now why why does it make sense, you know to really deploy, you know, these to do this replatforming and to introduce this new technology and control planes. One is I really do think this is the era, the era of the rise of internal platforms, you know we're talking about it a lot I've said it several times in this presentation reducing context required to be productive for engineers and providing that consistent we're now also starting to see platform teams pop up at companies all over the place, and not only platform teams but tooling that actually, you know, targets these platform teams as users as well. These teams have emerged to build these internal platforms to essentially get us from version two to version three, and they have this you know increased charter to you know accelerate development and you know control operations over that life life cycle and life and the third again I repeat, you know I'm repeating myself here but I really want to drive home this point is it's all about reducing complexity, you know, and making sure that you know the thing that we're exposing to our users. You know we're not requiring them to have a lot of context to actually be able to do their jobs. This is a great opportunity to really take a step back and make sure that we're actually building and the providing the right level of abstractions, essentially, all the way down. And so what do I mean by this great platforms, I think are designed upfront with easily consumable abstractions for your engineers to use. I actually think it's very very hard to do this in practice, but you know if you get the abstraction right then you can essentially go through those platform evolution steps and those replatforming steps without throwing a lot of toil and migration and force work on to your engineers. Well, one thing I want to talk about and one way to essentially do this is, you know with cross plane and cross plane to an open source project, and it's a control plane for framework that gives you sort of these building blocks to compose your platform. Now, anyone that's familiar with cross plane, I am grossly over simplifying what cross plane does here, but I want to kind of introduce these as some high level concepts to really think about, you know how you can, you know start building, you know the right abstractions and use the right technology as you evolve and as you replatform. And so, generally, when you're setting out to build a platform, there's a bunch of things that everyone does that are all the same. One, you know we all built these abstraction layers to talk to, you know clouds right very few folks actually expose things like the AWS APIs directly, they generally build some abstraction layer on top of that, you know, and that's sort of where everybody starts. One of the things I really like about an open source project like cross plane, it is essentially gives you that abstraction layer upfront. So now this is just one component that you don't have to rebuild and that you don't have to do you can just kind of take this and use this as a foundation and it's open source for really building out what you're doing. And then the second is this this notion of composing resources together or defining resources. You know I talked about in one of my examples of replatforming the fact that we had, you know the one configure the one ring example the fact that we had sort of created, you know our own configuration language to define like the things that you know our engineers deployed and operated in production and you know again was another level of abstraction. And again, if I went to 10 different companies today. I bet you that I would essentially find 10 different version of these configs or these ways that you defined and compose resources together. And so again by taking advantage of an open source technology, it gives you the opportunity to just build on a standard that's essentially already out there. You know, kind of moving to this third building block this is the notion of essentially like a universal package right. And the simplest way I think about this is like how do you package up the thing that you're building, you know that your engineers are taking and using and consuming and making it really really easy for them to essentially do that. The last building block is a control plane. Now that you've got like this nice package or this bundle that's got all these resources in it, you know that knows how to talk to like different cloud providers and abstractions. You actually need the engine that's going to take that thing, and then it's going to run and it's going to execute it. And so generally if I think of these four building blocks. When most companies are actually going through a notion of replatforming, they're essentially building some version or iteration of all of this. And it's always bespoke. It's always something that's unique to your organization. The second you, you know, build something like this at one company, and then you go to another company, you know you're essentially reinventing the wheel and building all of this stuff over again. One of the things I would actually challenge folks with is, you know, we have a great opportunity to standardize on the way that we're starting to think about building platforms, so that we're not always reinventing the wheel over and over, you know, over time and so that we can actually get to the more meaty part of replatforming without you know essentially again reinventing the wheel and doing all these things over over time and so, you know, taking advantage of open source talk technology is a great way to do this. Another example I often like to use here is essentially the, the database abstraction layer or ORM example, right, you know, if I went into a company today, and I essentially, you know, Toby engineering department. Hey, I want to build my own database abstraction layer, you know, everyone would look at me like I'm crazy they're like no there's like a million tools to do this that already exists why would you go reinvent the wheel yet again. And that's essentially what all of us are doing every time we replatform today. And again, I think there's really an opportunity here to start standardizing so again we can, we can focus on providing more differentiated value and not sort of reinventing the wheel over and over. I kind of already briefly talked about you know this notion of composable resources. And you know how you can kind of construct all of this together, but now I want to actually get into a little more of the notion of, you know, these abstractions right. Many of you are probably already familiar with Conway's law. It's this notion that every platform or infrastructure team, you know, inevitably exports an internal platform that mirrors how the engineering, how the engineering organization is structured internally. So, if you are at a company that is already thinking about replatforming today, and providing like this next level of abstractions and I use this in one of my earlier examples as well. You're going to find that you're going to actually need to change these abstractions. If you start out by building them based on like the company's organization structure. And this is a mistake that I've seen companies make repeatedly, you know, again, if you're going to, if you're going to provide like the right level of abstraction, you know, it's not going to look anything like the actual organization looks like. And this is just always something to keep in mind you don't want to sort of expose this leakiness, you know, to your, your developer and engineers with how your own internal infrastructure and platform team and CI CD team, etc. So if you are all operating, you really want to give them something that's easily consumable. That's more closely tied to the work that they're doing and the perspective that they have on their end, versus, again, just exposing the underlying complexity of the engineering organization. The lesson here, do not create abstractions based on your organizational structure. If there's anything that you remember from this talk, this is probably one of the biggest ones because going down this path, you know, similar to the examples that I called out previously, are going to just cause you a lot of pain, you know, long term as well. With that said, let me kind of quickly summarize like all the different things that we've talked about today and some of the points that I've made and, you know, you can really sort of walk away, you know, from this discussion with, you know, these three main points. The first, you know, this definition of what a platform actually is, you know, it's, it's that thing quote unquote that you're developing on, you know, it should accelerate the software development life cycle, and it should reduce the underlying complexity required for your engineers to do their jobs. And then it should exist over that whole build deploy and operate like stage and life cycle. Number two, everyone, every single one of you on this call, whether you realize it or not, you're either building a platform or your replatforming. And, you know, it's always an opportunity to take a step back and take a holistic look at what you're doing and essentially use that for bullet point number three, which is, you know, hey, your platforms are always going to evolve. So you should use every opportunity to ensure that you're designing the right abstractions, you know, for your engineers to easily consume. So that was a mouthful. There was a lot there actually want to take some time to take any questions right now as well too. So I'm going to pass things back to the Linux foundation and we'll talk about next steps. Thank you everybody. Thank you so much summary and if anyone has any questions. We can give a few minutes to have you put them in the Q&A box and he'll be able to answer those. So I'll just give everyone about a minute. You have any Q&A feel free to throw them into the Q&A box at the bottom of your screen. All right, it looks like we got one asking, will there be slides or the talk made available after this. The recording will be on the Linux foundations YouTube page, usually by the end of the day. And then summary, you're more than welcome if you would like us to share the slides as well that will be on the landing page. Okay, happy to do that as well of course. Okay, it looks like we got another question. So no abstractions around org structure. Can you give some examples of abstractions you do think work well. Yeah, so you know definitely take this with a grain of salt. But you know, I'm going to use a very simple example here think of maybe an engineer that works at a company that has like a typical lamp stack right where, you know, maybe a key and my sequel and a very simple cache and a web server like engine X, you know, and then some very simple routing, etc. Right. You know, you could imagine that, you know, if you're using my example of tying this too closely to the organizational structure, you know, part of that might be owned by the infrastructure team, you know, part of that might be owned by the database team. So that might actually be owned by like the caching team if you have one and then part of that might be owned by like the service discovery or routing team. So a bad abstraction there would essentially be exposing all of those individual components, you know, to that actual engineer, because that engineer really is just thinking about that whole application as the abstraction. Maybe instead of exposing all those individual components you just give them something like application, and the application has all of those things bundled into it and maybe you know those things aren't even tied that closely like to the language so maybe there's just a concert or sorry type that closely to the underlying infrastructure maybe there's just a concept of application, and that could be tied to some type of database that could be tied to some type of web service that could be tied to some type of caching layer, etc. But it's essentially the only thing that you're exposing to your engineers is that application so now they can just take that abstraction and they can use it, you can iterate on technologies and everything on the background but it's not necessarily tied to those individual organizations. One of the things that you will have to be careful with is that, you know, there is this intersection point of the abstraction, and then all the different organizations that lie underneath. So someone doesn't need to own that, you know, and someone does need to be responsible for that, and ensuring that you're having like the right coordination and whatnot across all the various components but I think generally that ends up being like your platform team. Any more questions. The next one. Can you give us some practical examples of platform implementation of the principles you outlined in the webinar. So, sorry, can you repeat that question. Yeah, can you give us some practical examples of platform implementation of the principles you outlined in the webinar. Yeah, so let me go back through history a little bit here. This is kind of similar to, you know, the last question that I just answered as well where essentially, you know, at one company we essentially did provide like application as a construct, you know, to our engineers where we essentially said, Hey, in order to configure and operate this all you're going to need is like four lines of yeah, right. And those four lines of YAML were all the information that we needed to actually deploy the entire underlying application stack. It started by just essentially declaring you know what language, you know that the engineer was going to be using because that language implied a lot of underlying like assumptions as well too and so we we then iterated on this over time we then sort of created, you know you can just think of like Java service like Python service, Go service, PHP service, and you essentially define that at the high level, and then everything else would just magically happen, you know underneath and so we essentially made a lot of assumptions for folks and we again reduce the complexity that was required for them to actually deploy these applications because at the end of the day. They're like great okay now I can just focus on actually writing code. I've got a place where all my code lives and then everything else is sort of transplant apparently handle for me under the background. That was actually one of our, the more successful examples I think in my career, we essentially just started out with that single abstraction. And it took sort of a while to implement the first version of that. But once we did that it was very, very easy to like build on top of that. So, we did that with our own sort of bespoke like solution. Now I would 100% like do something like that by just like leveraging crossplane, it would have made it like 1000 times easier. All right, we got two more questions. And the next one is, can you share an easy analogy of what a control plane is that would be helpful to use when talking to non platform engineers. Wow. An easy analogy of a control plane when I'm talking to non platform folks. All right, I'm totally making this up on the fly but like let's see, let's see if this works so I would almost imagine like a control plane is like imagine you're in a car. And there's a driver who's got like the steering wheel and they're driving, and then you've got a navigator who's sitting next to them, who knows exactly where you're wanting where you want to go. I think of a control plane, almost as like that that navigator that when they realize that you're making a wrong turn or like you know, going off road or going to slow or going too fast. Basically kind of take over the wheel and sort of fix it for you. So maybe the driver starts falling asleep, you know, that navigator essentially grabs the wheel and puts it back on track and like wakes the driver up. I don't know. That was probably a terrible analogy. But that's just a simple one that I can kind of think off, think of off the top of my head. One last question. How does something like cross plane connection. Sorry, let me start over again. How does something like cross plane connect to the various cloud services and their API CLIs or you guys. So, essentially cross plane is extended by what we call providers and so you know if you think about cross plane as it's core I mentioned that it's a control plane framework. But basically it enables you to abstract away and talk to anything that has like a public API so you can write a cross plane provider, or like use an upbound official provider that you know, for literally almost anything out there and it's not just other public cloud providers that have API's it's also private clouds as well that have their own API's. It's also things like managed services so in essence you could have a provider that talked to like Elastico or Twilio or Syngrid, like all of these things can essentially be abstracted away and so the primary way of doing that is via a cross plane provider. I think I answered that question fully but if I didn't let me know. Awesome. I think that sounded great. And so that was the last question. So, I will go ahead and say thank you again to summary for your time today and thank you everyone for joining us. As a reminder, this recording will be on the Linux foundations YouTube page later today. We hope you join us for future webinars and have a wonderful day. Awesome. Thanks Linux foundation and thanks for everyone that attended. Have a great day.