 Thank you. Thank you, Priyanka. Thank you, Pinky. Really good to be here. Really good to join you all. I've already learned a bunch of things watching some of the great talks that have come on. So, yeah, I was thinking about what to present here. So, I am the lead for Tag App Delivery in CNCF. It's a group where we review projects coming in and try to find synergies and standards and improve collaboration between all the CNCF projects. In particular, I lead a group there called the Platforms Working Group. In the past couple of years, we've been trying to provide guidance and support enterprises, companies, people trying to adopt platform engineering mindset, implement platforms, cloud platforms in their organizations. So, I thought today I would talk about what that guidance is. And in particular, I wanted to tell a story around platform engineering because what it really is is it comes down to a lot of relationships at the core of the culture of platform engineering. Of course, there's the practical, technical aspect, but there's a lot of cultural aspect also. And we'll talk today about how we build bridges as platform engineers, as platform builders. And we'll relate that to some of the work that the group has done. So, I called this talk Building Bridges with Platforms because I wanted to kind of play on that idea. When we look at a bridge, a bridge kind of brings together two points. One side and the other. Point A and point B connects two points. And that's a start. But when we look at what a platform team has to do, yeah, of course they interact with application development and they provide, we'll talk about that they provide capabilities for application developers. But then they also need to interact with security team. They need to interact with the product management team that's determining what kind of products are going to be building and what kind of support they need. There's sales and marketing that need to influence what what activities are going to be happening in the company. So first you've got the C suite that has strategic concerns how is this going to increase our increase our company's value how are we going to sell more products. You've got vendors and service providers to work with. So pretty fast you on the platform team. It's going to start looking more a bit like this. Continuing the going with the with trains and railroads. So this is a roundhouse we've got a lot of multiple connections that have to be made. We've found out the conversation and take it to a full platform here's a platform inside a train station, all the trains coming in together all them meeting each other all then going back out to other destinations from this hub. So platform really. It's not just a bridge really and that was that's kind of the pun that I'm playing on the platforms build bridges in many directions and it ends up being more like more a hub more platform like this. So why is that. And this kind of ties back so so our group put out has put out two two pieces of guidance so far. One of them is an I'll share a link at the end so everyone can find it. One of them is to help platform product managers platform builders advocate for their platform and describe the benefits of it and what it is. And in that paper we kind of describe a platform as something that abstracts a whole lot of capabilities in a consistent coherent way that to present them to developers. And it's really because of that here's here's the well known diagram from our first paper, because of that. Integration asset because you're bringing together, let's say 1015 20 different capabilities for your product teams to integrate into their applications. It becomes a point of a hub point a point where people can come together. So just going over how we define platforms in that first paper. We, we viewed them as an integrated collection of capabilities, you know, pulled from many different places but in particular with an eye to the need of the platform user. Yeah, so check out that paper it goes further in depth on why this is beneficial. Some of the, some of the advantages to reducing cognitive load to increasing compliance that's all mentioned in this in this first paper. Yeah, so I wanted to now get into what we've been working on the past six months, which has been basically we have that first paper where we described why platforms are valuable. What a platform might be made of we talked about capabilities, like we saw on the last slide that that that big list or a big diagram there capabilities that you might include. So we asked we published that in April, the biggest ask was okay, we kind of see where this is beneficial to us, but how do we go about achieving this how can we put in a platform where we're going to reduce the cognitive load like you promise, where we're going to increase our developers productivity and experience where we're going to be sure we have the governance and compliance and the guardrails that that we need for our enterprise. Happily, around the same time as we published that first paper there was an initial maturity model created by Centasso and some of our colleagues there that also participate in the in tag app delivery and CNCF and our working group. And so they put out an initial maturity model and then they turned it over to our group and said hey can you guys go over this mature the maturity model together. We published it via the group, and it was a perfect fit because, like I said we needed to help people understand how they could achieve that vision that we're trying to pitch. And the reason why we want to, we really do believe that by achieving these platforms by implementing a platform engineering culture by implementing a platform in your or several platforms in your organization, you will get more benefit from cloud and you will accelerate your product, your product value your product delivery. So we created this maturity model which is I want to dive into this now a little bit more. And I want to dive into it from a perspective of relationships. So in the, in the model we've got five aspects, which there were about 50 to 50 to 60 people that went over this this summer contributed and helped us narrow down these aspects. And it came from, you know, vendors like like myself at Red Hat or Cintasso but also from end user companies from cloud companies, we had a lot of contributors a lot of insight. We ended up with these five key aspects to start with at least always open the feedback always agile. So we'll go into each one investment adoption interfaces operations measurement, and then we'll talk about the continuum and each one that that you can look to and we'll give some examples. So, let's start out with investment and measurement. What do we mean by those and who are the relationships that are affected so you got your platform team. The way we define it I'll read the question here how our staff and funds allocated to platforms to platform capabilities. So, how do you, you know, do you hire engineers, do you hire product managers, do you hire developer advocates, do you have a support team. So how do you hire and how do you allocate people to this team. So do you just ad hoc ask people from application teams to to participate and to contribute the features that they need. So from the perspective of people from the perspective of funding. The most interesting point in all of these is the transition from operational to scalable the transition from number two to number three. So, for example, an investment we see that at level two we have a dedicated team, which means I've allocated a team that's building the components that I need for my application developers, but the difference between that and as a product is that I'm not judging them based on the value that they provide to those end users there more. So I guess you might say a cost center, their value, you know that they're providing to the enterprise is not as clear, because they're just funded as, you know, take care of this, take care of this of this necessary business, rather than you are providing an active value as a product to our to our end developers. So as examples on that I actually talked to to an engineer at a company that is a pretty well known company that has a good platforms team and they even have some support engineers on their platform team. And this person told me I built a data visualization tool, which anybody can use to you know take a Jupyter notebook and publish publish some statistics really quickly visualizations. And I have to maintain it myself and people have to come to me and I can barely keep it up. And, you know, it's just this one thing that's being used by five or six teams and I want to build it up more and I was, it was interesting to me to find within one organization that's why I wanted to bring it as an example. You could be on you could have different teams, different platform like teams, or functionality at different stages in this investment line. I mentioned, I talked to one company that even has product support that you know that always is impressive, pretty advanced maturity level there if you've got, if you've got support and your your people that are actually writing code platform engineers. Moving on to the next category measurement so talking about so of course investment is a lot the platform teams relationship with the strategy in the C suite and convincing them to invest and to keep going and to maintain that that team. Measurement. This, you know, this is a really active space of conversation in our, in our space right now and platform engineering how do we, and this one you could argue that it's, it actually relates to a few in a few different ways I'm going to emphasize the relationship with this, the C suite I need to, you know, me as platform engineers, you want to show the C suite that you are having the impact that you desire so measurement is towards them but it's also towards your app teams your product teams. You know they want to know that they're going to be able to deliver faster. If they get on your platform, maybe it's the engineers first question isn't how is the business going to make more money. That might be more the strategy question, but they definitely want to see your measurements to and to some degree you also want to measure yourself of course. But this is a very interesting space because a lot of the metrics we have and I just saw a conversation in the platform engineering slack about this. Like let's say let's take the Dora metrics Dora metrics are things like how frequently you make a new release. How frequently that release fails, how long it takes to get the release out. That doesn't directly say that the product that you're releasing is so valuable, of course, I'm sure we all realize that. But what we've discovered is that these correlate with good quality products with productive engineering teams. So we found correlation. I saw some other, some other advice in that thread and the platform engineering slack that you could relate it to the time saved if you wanted to actually give a money number for your C sweet, you know the number of developer hours save the number of developers you don't have to hire because you have a more efficient platform. So a lot of times it's we have metrics but we're still working on correlating them to show impact, you know, broad organization wide impact. Another really popular one is time to, well, 10th commit. If you look at Spotify's docs on this but time to first commit maybe is also a good one time till somebody can be effective. That's something to measure. When we mentioned that in some of our papers, and then adoption things like monthly active users. I think a really interesting one here is surveys and interviews. Most folks that we talked to believe that they get a lot out of qualitative surveys. They can be difficult to run. I can tell you we're trying to run a broad interview. Program now from from the platform to actually come talk to us if you want to help us out. But it's pretty hard to get together and get everyone on the same page because you're not just trying to educate yourself as the interviewer you really need or the survey or you really need to get that information and share with your whole team. Yeah, so that's on on measurement how the platform team, you know, reflect their impact up to the C suite and to other to other teams. The next relationship. This is maybe is the one that you know we think of first is the relationship between the platform team and the application developers. And in this category, we have adoption and interfaces kind of this relationship that we have adoption and interfaces, which are kind of interrelated. So again, here I'll just read what we defined here for adoption, why and how the user discover and use your platforms and your capabilities. What makes them want to consume your platform. So here again we kind of find that split between number two and number three, where, you know, in number one and number two, it's more of the, well, I something is forcing me to use this platform for some reason extrinsic push for example means, you know, my boss says, if you want to get your bonuses here use the platform the team is recommending, or maybe it's more subtle than that it's if you want full support for your database then you need to use the database as a service from the platform team. So I don't necessarily want to use it but this is this where the organization is going. So we switch over to the intrinsic pull, or even participatory where I'm contributing in level three, and they're like for example I was reading about a, an engineer that was providing databases but they realize if we provide observability alongside this database so that you use our database you can see, you know query metrics and other information traces for calls to the database, you know, follow all the way through by providing that I can give an intrinsic pull I don't I don't have to force users to use my platform they want to come in and use it themselves. And that's that that starts to create a flywheel effect which we talk about a little bit in the, in the guide. So participatory is is what I've seen there or at least the starting point there is for example enhancement proposals, letting people from other teams that at least as a starting point begin to propose what they need and and feel ownership of the platform themselves that's a that's a very far degree. In terms of adoption I've adopted it so much that I've made it my own. Of course, you know in the open source world we kind of understand that encourage that participation make it your own. So adoption does kind of correlate with interfaces but interfaces to us. The way we were describing it is the way that your users come in and can use your platform. So API is well that application programming interface that literally is that kind of interface. Here's where we find things like backstage and portals. You know, don't be confused to think that the portal is the entire platform, but it is a really important part of the platform it can give you a consistent, you know that's the first, I think one of the reasons why backstage has become so discussed so popular is it's the first thing that it's the first experience your app developers your users have. So we talk a lot about different styles of interface API CLI's, you know, in the in the early version in the L one and L two level standard to they might just be service now tickets, at least, you know, try to bring some consistency or sorry, it's any kind of ticket, at least try to bring some consistency around that. What's really interesting is when you get to the far right integrated services and what we mean by that is an interface that's almost that is hidden. You can see that with some of the service mesh stuff, for example, like we're observability just you get it for free just deploy on our platform or identity, you know, you automatically pull up pick up an identity from the, from the environment from the platform. So we go from, you know, L to standard tooling at least you have a consistent process for opening tickets or sending an email to self serviceable solutions where I have to do a motion but at least I can do it on my own I don't have to wait. And all the way to the point where I get the capability for free. I don't even know how it works I don't have to do any sort of motion. So this is all about how the platform team and the application team interact. And then finally, last but not least, this category was in the middle but I put it last year operations. And this is really about how the platform team operates itself, how they interact with themselves, and a little bit with their, with their sibling teams so how do we staff our team we mentioned that a little and investment but again here. How do we make sure we have the right people on the right projects, obviously that's going to be within operation. We talked a lot here about prioritization. So how do, how does an organization track all of the platform capabilities that they have. How do they make sure that they are maintained secure compliance that they're life cycle if you, you know, if you need to update one that they're updated if you need to sunset one that they're sunset. How do you make sure the most important things are being done. For example, I was helping a company one time, and they really had like 10 or 12 infrastructure teams, and you had to go to each one if you wanted file stores you went to one team going to database you into another you went to networks and firewalls you went to another team if you needed a server you went to another team and maybe that's pretty typical for you know 1015 years ago. But it's pretty difficult to track priorities across your platform when you just have a bunch of disparate teams. And so that we kind of go to an L2 here we talk about centrally tracked at least loosely coupling and knowing where where all the different capabilities are being maintained. And we shift into level three centrally enabled we have a central team which is saying look, you got to adhere to certain standards if you want to publish a platform capability, a new database type for the enterprise. You need to make sure it's got, I don't know observability included. You need to make sure that it's got, you know, default configurations, golden path templates, let's say so people can get started integrating it. So they start to put some, some guardrails around that. I have seen situations where this can end up being a blocker so you do have to kind of be careful that you don't take over all the work in the platform team. You do, if you can I guess this is dependent organization but you want to be able to encourage the product teams to contribute as well I did have a situation where I've seen bottleneck essentially because only the platform team wants to build new capabilities for the platform and others have to wait. So, here in operations we have, you know, the relationship of the of the team with themselves and how they organize themselves. Yeah, so just to sum it up I guess let me take it back to the to the maturity model as a whole. We've got our five aspects in each one we've got a continuum of practices which you'll find that your organization and other organizations. And we anticipate that a lot of organizations will find themselves and that's why I have this pink line here, kind of at the L2 looking to get to L3 level. And actually, you know, if you look at the top of the L3 level it kind of says as product when you when you get to that L3 level it really starts to reflect platform engineering culture. Providing value to my to my end users at by providing, you know, my my platform as a product, they are intrinsically motivated to come and use my product. They are able to use it on their own they don't have to find, you know, rumor driven ways of actually getting what they need there's a central team which is putting standards around it, and everything is measured and we're gathering insights from it. That would be amazing if you can get the level three. Yeah, so I just wanted to relate this a little bit to get ops, because this is, after all get ups kind of of course get ups is a real key tool or a real key pattern to use in your in your platform. And what I think, you know, a way because I'm talking about relationships I think a way that get ops achieves this is by giving everybody one point of of truth in that get repo, where we can all see that, you know, and collaborate on the source of truth on what we expect to be out there. And in fact, you know, it was a revelation to me I was giving a class one time and give me a workshop, and I said something like, it wouldn't be so terrible to run kubectl apply at the very end of your pipeline and that might be a little bit like get ops, you know, if you don't get ops, you know, controller of some sort. And somebody, I'm sure I just caused a lot of consternation with that, but somebody raised their hand and said but Josh, you don't get the visualization, which was revelatory to me like I didn't think of get ops as visualization thought of it as that same repo but it was a good point and that's why I bring up this picture are go I know there's been some cool other visualization showed through the conference as well. But here's, you know, a place where we can all see the current state and collaborate. I think that's one of the benefits of get ops. So again, talking about relationships. Get ops is another way that we bring together everybody in the cultural kind of way. So yeah, I wanted to wrap with this. This whole earth coming together. And in that vein, I actually wanted to call call to action to say we're always looking in my tag tag app delivery, which by the way, in our group we have my working group, which is platforms we have another working group, artifacts, things like how do we bundle up these manifests into OCI packages we're literally talking about that kind of thing. The Ouija get ops or Ouija working group get ops is also part of our group. So I did put the maturity model I think that that's what this this QR code here if you want to take a picture of it. And then you write to the maturity model docs and the and the platform doc that we created, but definitely come join our meetings we're very interested in people stories whether you're, you know, a contractor a vendor or an end user, come tell your stories to us. Join us in the slack channels. And yeah, I would love to see you there and help us continue building the the platform engineering and get ops communities. And yeah, I'll pause there. That's awesome. Thanks, Josh. There is a question actually in the platform as well. If you don't mind so it's is there a standard model to quantitatively evaluate a platform along points you shared. Good question. Is there a standard model. There are a number of discussions. For example, Dora I mentioned which talks about four key metrics like time to delivery. There have been a couple other developer productivity frameworks or recommendations that have come out. I would recommend. I mentioned in ACM the association for computing machineries journals. So there's one called dev X the V EX and one called space SP a CE, they're all capitalized, I think. And those are other frameworks for measuring developer productivity. So far, that's kind of what we've focused on is the same measures that we use for developer productivity. Apply for these platform engineering. But this is, this is one of the areas that we want to explore together so if you want to help us come to the group and we're trying to understand how people are measuring beyond Dora and dev X and space. So, looks like that's all the questions that are on the platform so far but I have a couple. So what motivated the CMCF group to create the guidance you've created so far. Yeah, good question. What motivated us. We realized that, you know, the motto of CMCF is make cloud native computing ubiquitous. And the way to do that is, or we believe the way to do that is by a consistent platform that makes app developers really be able to take advantage of cloud. And when we looked around, it was just a gap in the space to explain to senior leaders. The value this could provide to them so we really that first paper was really for senior leaders to appreciate platforms. So that's what really motivated it all then I explained before like once, once we had that we, you know, a little less senior leaders wanted to know okay, you convinced my senior leader now how do I actually do this so that's that's where we've been. And right now, like I mentioned the interview framework we're trying to get together to further verify I mean we've had a lot of people look at all this stuff but we want to further verify and talk to people. So, yeah, that's, that's kind of been our motivations along the way. Awesome. Um, I think we'll wrap it up here. If that's with you. And so, thank you so much, Josh. Seriously, it was a pleasure that was a great session. And we are ensuring our last block of breakout sessions. So I hope you enjoy the talks the rest for the rest of the day. Um, please come back here at the end and I'll just send share some final thoughts and send off the event at that point. But thank you so much, Josh, we really appreciate it. Thank you.