 special edition of Cloud Native Live today where we are joined by guests Josh and Simon. This is a CNCF livestream and as such is subject to the Code of Conduct which basically is be excellent to one another. Easy to keep in mind hopefully during these holiday seasons. Please be respectful to one another in the chat and as you interact with one another on this stream. With that I'd love to kick it over to you Josh and Simon to get started. I'm really excited for today and really digging into what you have to share with us. Nice. Yes. Thank you Taylor. Great to be here. Great to be here with Saeem. We're going to be talking today about platform engineering. We're going to be talking about some of the collateral, some of the guidance that my group in CNCF Saeem and my group, we're both part of the technical advisory group for app delivery projects and we're both part of a working group in that group called the Platforms Working Group and we've been doing a lot of work to advance the domain of platform engineering from over the past year or two. So I guess I just kind of introduce myself. I'm Josh. I lead that group. Saeem, you want to... Yeah. Thank you. Thank you very much Josh and thank you very much Taylor and it's been a player actually being on the call today and talking about the most interesting topic of today's need is platform engineering and we are really happy and we're really lucky to be working with a talented individual in the platform working group and we did manage to pull together of two platform white paper. One is platform definition white paper and one is maturity model and we will be speaking in a minute and really it's been a wonderful journey so far. Managed to pull together two of the very interesting white paper for the community and so looking forward to it. So Josh before we're starting up so can you let us know about your early interaction with the community and somebody really new to us in the platform engineering domain. What do you think platform engineering is and based on your earliest conversation with the community? How do you see and how do you define platform engineering in general? Yeah perfect segue into this into what we need to talk about first. So yeah before we can get too much into anything. What do we mean by platform? What do we mean by platform engineering? We're going to talk a little bit about why they're valuable. You know Saeem you asked... Saeem and I met a few months ago and did a similar podcast on his podcast and you asked about platform engineering then too in my opinion actually has a little bit changed since then so I wanted to talk about that. So the easy answer is to say you know platform engineering contrast it with product engineering you know your product engineers create products that are shipped and given and sold to end users to people outside of your organization as opposed to platforms which are something that you build for internal users for those product teams to build something on. So you know at its simplest platform engineering means building internal tools, internal platforms, internal facilities that enable you know other internal folks to deliver something to their customers. But really it's come to connote more and that's what we're going to talk about today building bridges for example. What do we mean by that platform engineering or platform engineers build bridges? There's a culture that's emerging around platforms around platform engineering in particular you know of collaboration, of bringing people together, of improving experience. So it's a little different than just your classic you know oh an engineer does X it's also that cultural aspect. Yeah so yeah so with that let's I guess our next question and Saeem do you want to go ahead and absolutely absolutely. So thank you very much for elaborating it. So Josh can you talk about the I think we've managed to pull together two white paper this year. So can you talk about the motivation behind the original CNCF platform white paper we publish I think during KubeCon Amsterdam and then I speak then I ask more question on that front. Yeah yeah I'll go ahead and bring up this this next slide. So you know we we actually formed the working group over two years ago and originally it was called cooperative delivery and the charter if you look at it it was all about how do we enable application developers and infrastructure engineers to work together to deliver everything in you know in a consistent easy way because we found this disconnect between our application engineers and our and our I guess platform infrastructure engineers and so we we were trying to solve that problem and what emerged from the industry in that first year was platform engineering and creating these platforms is actually what's what's solving that problem what's enabling app developers and infrastructure to work together. So once we kind of realized that we renamed the group from cooperative delivery to platforms and we decided let's go all in on this trend let's make sure especially people like like directors and CTOs and decision makers are aware of the benefits that this is going to bring so that was kind of the the motivation for our first our first paper which is what I'm kind of bringing up here to talk about. Yes absolutely so Josh absolutely so Josh I think some of the folks were actually looking at this URL tag app delivery CNCF dot io white paper slash platforms some of the folks actually were right now listening to us or doing this so can you let briefly explain who is the attended audience and what domains of PE platform engineering are covered in this white paper. Oh yeah that's an interesting question like I said we're we're targeting this was written and it's interesting to contrast this with the maturity model a little bit this first paper was written to pave the path for folks so if you read it it starts out you know why in fact originally started out with what because to me it was you know the first thing you want to know is what is a platform that we're talking about here but then we realized you know our main goal is to convince directors and leaders that this is the way and so it actually starts up with with the why of platforms and what they're going to achieve for you which is a slide a little bit later here but the second page so so yeah so that first paper will educate everybody but it will really give you a ammo to go to your to your leadership and say this is really going to accelerate our our work and in fact you know I should maybe should go ahead and just show that I'll show this this slide where we talk about what an internal platform can achieve for an organization and this was our goal with that first paper was to get that across do you want to you want to dive into this a little bit Saeem what the different characteristics we have here yes absolutely absolutely so I think like as as Josh mentioned like some of the things in here so I think like on the one I think the cube gone Amsterdam time frame when we look at the look at that time frame in a moment you actually look at it there's a platform engineering definition for people looking to have a guide available for them so can basically look and read and understand the platform engineering domain from a various perspective so I think the team has done a wonderful job curating and structuring it around in different angle I think we speak about some cognitive load on this white paper how to improve reliability how to accelerate delivery reduce rate and integrated managed services so if you're reading it you have some sort of certainty what those term means for you in your I think we have spoke there's a very long list of the paper on things in here gets through or how we organize it if somebody consuming this today so what's question or question do you think he's looking at and how we answering those questions yeah exactly exact that is a that's a good way to put it um and I'm I'm glad that you called out like each of so this section here the slide that we're looking at is actually two parts of the paper condensed into one slide that first section we talk about the why because like we said we're trying to give folks ammo to advocate for these platforms so we talk about reducing cognitive load and we should talk about what we mean by that why cognitive load has become such a such a big deal we talk about so this is all in that first literally the first page of the paper we talk about how by centralizing and leaving capabilities with experts you can improve reliability ultimately accelerating delivery is one of the top values you can get out of providing you know a consistent platform and then finally we talk about well reducing risk that kind of parallels the improving reliability but but it also makes if you have a consistent platform it actually will make it easier to bring in services from cloud providers also so all this is kind of in that first section of the paper we can dive into a little more if you won't say um then we list and actually the what here we have a section in there called attributes and this kind of uh bleeds into the maturity model a little bit as well where we try to I guess the uh help people understand what the platform engineering culture is kind of about you know the connotation like we said before not just that I'm building something for internal folks so there we talk about you know we build things as a product so before we contrast the product and platform you know but can you treat your platform as a product like you're taking it to an external user so that means a much more customer-centric outlook we talk about in that section we talk about the importance of user experience like that's another like platform engineering connotation is that we really can't maybe different than no offense to classic sys admins and infrastructure engineers but there's a little more emphasis on in platform engineering movement of what is that user experience like can we make itself service we have other capabilities you know other characteristics in there like the capabilities should be optional so that people can choose other paths if they want and then one of the biggest you know leads into the benefits on the why section make sure that the patterns that people adopt are compliant and secured by default so if you're going through that the paper that first section is the why the next section is here's the cultural aspects that we've discovered in talking with a lot of folks yeah and actually yes absolutely absolutely so yes I think the one question people quite to understand because we actually use some of the terminologies and the paper so we can speak about all of these things but we actually can concentrate on one term that basically been very heavily used in the platform engineering domain and that is reducing the cognitive load so if somebody is actually reviewing this so josh can you describe what do we meant by reducing the cognitive load yeah let me actually I want to go back to this slide to address that one so so this slide is the way we and so we've been talking about platform engineering here but the question is what exactly is this platform that we're engineering and so we attempted to kind of give some enlightenment on that in this paper as well and I think that it will also show where the cognitive load comes in because I'm actually I'm talking with the customer about this literally today and they're like yeah we know we need to modernize we're going to do containers we've got a container system and we're going to use this container system and that container system and we're all good and I'm like oh no but there's a there's a lot more than containers that you need to consider so that's what this that's what we kind of tried to call out what is this platform so the platform is something that brings together a bunch of capabilities to meet some end user need that's a pretty generic title and intentionally so we didn't want to restrict ourselves to you know a developer platform even though those are you know probably the main use case today but we wanted to consider mlops we wanted to consider you know information workers we wanted to consider third-party software I just want to run some third-party software some cut software so we defined it pretty broadly as this integrated collection of capabilities but just looking at this right now like in the platform you need beyond just your compute network and storage you know that was old school somebody gave me a server hooked it up to the network and there's a hard disk in there I need databases I need message brokers I need an identity system I need an observability system I need someplace to store all of my images and packages I need tests I need tasks and test runners that will execute my tests and will deploy my my code for me so there's a lot more than just say containers or just compute that I now have to bring together into my application and that's what these that's what these platforms are and that's where that cognitive load comes from actually on that topic I want to show one other another interesting slide so I made this diagram like five or six years ago to kind of it's a it's a microservice that they actually built or not a microservice a couple microservices that were interacting in various ways and you could see there's just two services here one written and go which is serving the front end and a back end service written in Java on the side but look at all those other capabilities that they're pulling in from the from the environment from the cloud from the from the underlying platform and this is this is a typical kind of situation in today's cloud world and so that's why you know to reduce this cognitive load that's why we've arrived at this platform engineering concept like we're going to have to aggregate this complexity and abstract it a bit from from our application developers yeah through cognitive load back to this slide where we started cognitive load is probably you know one of the main reasons I do this I did have a question that's from from the audience and it's kind of related to cognitive load a little bit but kind of more focused on teams and structure of those teams Keith was asking is shared investment or tenant costs sharing for platform sustainability consideration for the platform's working group yeah that's a great question actually when we get into the platform maturity model it's one of our theories and we've heard it from a couple companies that as you move into a product mindset one of the ways so I'm skipping ahead we're going to talk about that in a minute but one of the ways to show value is are people willing to pay you know that when you sell a product to your end user product engineering how do you really determine if the market is interested well how much are they willing to pay for so it's the same thing if I'm going to treat my platform as a product one of the ways to really show the value is to somehow demonstrate how much people are willing to pay so yeah definitely hearing some companies trying to implement that um yeah and we'll get into that a tiny bit more in the maturity model because it's one of the uh it's one of the aspects in there cool and there was one more quick one um are there any open standards for uh platforms at least that you're seeing right now uh just at a high level as well yeah this is a this is a fun one I mean what we're kind of trying to do is is reach some standard apis like if we could have a we defined uh platforms above as a consistent set of capabilities so the way to get that consistency I think is to provide it you know a standard api framework um so you will hear different opinions on this I think kubernetes actually is not a terrible api framework for consistent you know deployment of all kinds of infrastructure capabilities not everyone agrees with that and so we do have a couple other projects even in cncf a couple have been so crossplane is an example of one that people like to use another one that was submitted recently is called radius another one that's coming soon is called three port so there's a few uh efforts to create I guess less standards and more open source projects with a common api also thank you Josh yeah that's all for me I'll come back with with more questions but uh we'll hold on to this right now back to you Sam okay thank you thank you stay alert thank you very much folks I think wonderful high engine high leon from one of our platform working group and kiramat and keats and joining nice to see some of the wonderful folks actually listening and enjoying the conversation so Josh I think we have a few more minutes left on this topic and then we're moving on to the platform maturity model so before we jump into the maturity model can you define because there's a tag app delivery we actually coined some we mentioned couple of time during the conversation here and folks might be interesting in understanding the tag app can you please give us a virtual tour and role of tag app delivery and working groups and assignment of workloads under different working groups yeah for sure for sure so let me bring this up so that if people want to check this out we'll bring it up at the end too um but the the job of the tag um is really first and we really have two audiences first and foremost is our projects and maintainers in cncf you know making sure that they're supported making sure that they know what they need to do and that they have the everything that cncf promises them helping them appreciate each other see each other um but also bring to them users and use cases help them understand the industry sometimes I say we're kind of the pms for the cloud native community um so that's our second audience is our the users the people that are trying to consume all these projects what do they need um how can we help them um and so to that on the project side we often are evaluating projects that are coming into sandbox that are submitting for incubation um we're often like we have a group right now called the artifacts working group in tag app delivery where a number of projects that uh help people bundle up images and manifest and deploy them to a cluster a number of projects are finding synergies you know they actually want to find a way to search attributes of those packages across many different kinds so sometimes we create working groups to tackle a tackle a problem for the projects in the case of the platform's working group it's ended up that our main focus has been end users how do we enable end users to really succeed with cross plane and kubernetes and all of these other helm and customize and all these other tools that are coming out um that are available yeah so our job is kind of face the projects and support them face the users and enable them to integrate with the projects and and kind of bring them together so in some ways where the I want to I'm gonna we're gonna talk about the role of the platform engineer and we're talking about that person as kind of a bridge builder in some ways we're trying to in the tags build bridges between our end users and our project thank you very much josh for explaining it wonderfully well so now we'll come to the very important topic and I think that is where we're interested very we did wonderful job of actually publishing the paper earlier in cube gone chicago so first thing first what do we meant by platform engineering maturity model what do we mean by a maturity model yeah um our goal here so what happened was we got that first definitions paper out in amsterdam you know last april and we had some success I think in showing people the value of platforms what they are bringing people as you were saying saying bringing people uh to some common understandings um but almost immediately we were getting questions all right so we want to achieve this we see the value it can provide help us do it what do we need to do next what's our next steps um and so at the time cintasso actually offered us the an early version of what became the platform engineering maturity model um and it was a perfect fit because we realized like this can be something tactical for people to you know look at and and determine what their next steps are um yeah so that's kind of been the goal of of getting this effort going of the maturity model is kind of shift the shift from strategy to to tactical uh and oh yeah and the question was what do we mean by maturity model people aren't going to be able to find themselves in this model and then identify adjacent possibilities for themselves you know to to mature a level more if it's appropriate for them yes absolutely so Josh can you actually walk us through to so different attributes of the platform that's covered in this paper and what was a primary motivation behind the categorizing the way is actually categorized today when people want to read it yeah yeah so i just skipped through a few slides where it was basically a tele-story of uh and and you know how the platform engineer creates many many bridges um so here yeah that's why i just skipped through those i guess um but this here we see in this diagram kind of the the lay of the land for what we arrived at so before we were talking about uh some of the key attributes that you'll find in a platform engineering team we we were hoping they would line up exactly with these the ones that we lined up as aspects here and ended up through the conversations in the summer that we ended up at these five although we are going to go back and revisit how to juxtapose them with the seven from the original paper but basically for each of these we identified a continuum of practices where you're starting out in a very ad hoc one-off provisional kind of way you progress to something operational although not necessarily sustainable not necessarily something that you know is is can be funded or supported for a long term then we get to something scalable sustainable um and then finally we can talk about how we optimize and go forward um we were influenced to some degree some people might have seen the cloud native maturity model which is a little broader like if we're uh if we're focused on that middle layer the platform team um that cloud native maturity model is a little broader it's thinking about the app team what they need to do and the infrastructure teams what they need to do but we're really focused here on you on the platform team where do you see yourself in these aspects in the aspect of investment the aspect the aspect of adoption interfaces and we're going to we'll go into I think we're going to go into those now same yes absolutely absolutely so I think there are some questions in the chat and Taylor want to bring it up absolutely uh I did see somebody say it'd be great if there's a standard specification defining a set of pluggable based services and an extension model for creating additional services yeah I guess on this one I'm going to go ahead and since I'm sharing my screen anyway here you can see that the paper but we did try and I listed them above and you can check them out here we tried to create what I will call a hypothesis although this has been pretty reasonably vetted at this point we tried to create this list to get people started of 13 capabilities that you might consider for your environment I feel good saying about that because I know that there's a similar one that was created by the folks the cloud native operational excellence team canoe and they also created this list and there's a lot a lot of overlap actually between the two of them so it's it could be better standardized I guess I agree with that but we're we're all kind of coming together right now to understand what are these capabilities and in fact before we go I will mention an effort in the group now to try to gather more from the industry but I'll pause there on that awesome awesome I did see another question that came in and it was I'd like to take time to read the paper how would I find it and I have gone ahead and put in the link to be able to find this white paper definitely if you haven't read it check it out you know not sure what your what your wind down habits might be out there but you know if you want to curl up and and enjoy this before bed maybe that's a good thing to do if you want to read it with your morning paper also a great thing to do check it out I in in terms of folks that wants to get more involved I think that you probably will see you know more and more folks as white papers reports and other things come out people wanting to get engaged give any recommendations for folks kind of starting their journey that might want to get involved with tag app delivery or anything like that any upcoming efforts or things that you might want help on is part of the group actually yes um yes this is I'm thinking how to put this forward so one of the uh one of the categories we have here is measurement um which uh you know we talk about measurement to show the impact of a platform and its impact on the business there are other aspects of measurement too but one of the most important aspects of measurement is is getting feedback um and is getting in what we found actually interestingly is that surveys interviews are one qualitative data is one of the best ways to get feedback but it's also one of the hardest ways but that's what I'm actually bringing up now so in our group we are working to create an interview framework to allow you know anybody from the group to interview a colleague platform engineer gather up some information and share it with us and our goal is to synthesize that to to share with the industry what is the current state amongst you know average enterprises so that's something that you know come to our meetings come to the slack channel we're even looking we're going to have our first run of this next week I think we have somebody so thank you um but you know find someone from our team that you know wants and sit down with them for a half hour and let them ask you about your platform engineering practices and share that with the group um that's a great way to help so come I guess to do that come join our slack channel come to the meetings occasionally and you know we'll reach out to you we're definitely looking for support I've got ahead and shared that link in the chat I think it'll just go to YouTube so if you're watching on LinkedIn the link on the screen awesome we did have a couple more more questions and then we can start to round things out or or get to any other topics that y'all might want to get to before we close um I uh we have this question from Giovanni I'd be interested in real world experiences implementing a platform engineering's team in a larger organization that has been working without a central dev ops team if anyone can share um not sure if that might be a great place to listen to some stories within the tag and delivery group or even check out some of this previous meetings or calls yeah actually I I love this question because it relates to so one of I was I wanted to talk about the relations that platform engineers have with with the rest of the company and and one of them is indeed you know how you structure this platform team so we see this uh in the investment attribute that we talk about going from no sort of team whatsoever just voluntary or temporary and if you look at that that means me miss miss or Mr app developer realizes we have a need for a pipeline runner and goes and sets that up on behalf of the team and then a parallel team comes and says oh we also need that can we use your Jenkins that kind of thing um as we move to operational we get a dedicated team that's usually the organization realizes okay we have a bunch of teams that need a portal let's get one team to build it on behalf of everyone but often still at that point costs are not distributed um it's viewed as a expense you know that's been expected out of these teams it's it's not the value to the other teams is not realized that's what we get to scalable as product when we say we're not just going to throw money at a dedicated team we're going to get them to define the value that they're providing to the other team so that they can justify their own existence um so I guess I'm answering the question that there's a continuum like the situation where you have no DevOps team is kind of that voluntary or temporary um what to do in that case I it also depends like I was actually going to share a story here I was out of comp I was supporting the company that had disparate teams like this no you know you wanted a firewall exception you went to the network team you want a database go to the database team you want to server you go to the compute team something different for everything um I mean in a big company that might not be that efficient for app developers so I guess that's what we created the paper for so you couldn't advocate to your directors like we can achieve more and we can accelerate our delivery by consolidating and putting something consistent over this um yeah I had a story of a big company and they had a platform team that was as product and even had dedicated support teams but yet there were there was I was talking to an engineer who had built just one little capability and was supporting it all on their own for a few teams so it was interesting to find that even within one company you could find you know different uh different levels of maturity in this space so you know I guess I didn't give a I didn't give an absolute answer because it depends on the needs of your uh your group but you know getting if you're in the voluntary temporary stage getting to a dedicated team might be your next step great advice josh I think that anecdotally I've heard a lot of folks uh like you said you know what what constitutes a large team uh can differ from organization to organization maybe for some folks that's 50 people 100 a thousand three thousand uh there are many different kinds of ways that people interact and then at those different scales things you know composition looks a little bit different um in some folks I've talked to that some do have that central team that kind of handles all the things they're the catch all group for platform engineering and then others mere what you were talking about earlier in terms of productizing these different services and then even offering different kinds of you know it's it's difficult to centralize and then it might not always be the best thing to have the central point of failure um from a specific team or group or region things of that nature so um to create products that teams can then host and then get support from those central platform teams there are different differing patterns that I've seen around the ecosystem so again really great advice and uh interesting to see how there are so many different ways of solving similar problems within our ecosystem uh I did see a couple more questions pop up um uh adrian had asked that he leads a uh engineer platform team with self-service capabilities a software development framework IEC components and the most difficult point was adoption do you any suggestions to improve that strategy when it comes to adoption oh good thank you so good now we'll go to the next slide here perfect uh so here's the relationships between that platform team and uh mostly your users your application developer team um and here one of our our category is adoption which to us means uh how do people discover that these capabilities are there how do they start using them and again we try to create a continuum of practices where to start with it's just um it's it's there isn't necessarily anything in the platform it somebody creates a solution on their own maybe shares it with others um as we get to the second level this we we kind of suspect a lot of customers right now are at that second level the uh and and there's opportunity to get to the third level the second level here is some sort of incentive from the outside is having me use that service so let's say it's a database service being I actually read I saw this story recently from a company they built a database service they weren't able to attract people to it they were just kind of an extrinsic push you know you could you'll get your raise this year if you use this platform where you'll get full support if you use this platform something extrinsic but this team was actually saying you know what we added we're going to add observability some observability things some metrics some traces around our database and that changed it from an extrinsic push to an intrinsic pull people wanted to go and use their database because it gave them uh that capability um so you know that shift again from like l2 it's operational to l3 now it's scalable we no longer have to you know create incentives people want to use that platform um or that capability and then of course optimizing is not only do they want to use it but you've given them a way to contribute on their own so that they become part owners of that that's that's actually kind of tricky how do you allow them to to own and contribute but definitely if you're if you're in like the extrinsic push stage then start looking at ways that you can pull people in intrinsically great advice great advice yes absolutely absolutely josh so josh i think we we're noticing some of the similar question actually in the chat and i think the best way to can answer these all these question here is like let's say in a in a in a platform maturity right maybe we have a matrix so the table that defining the different aspect of the platform and in the horizon our leftmost row is we have some question listing in here like how and how do user discover and use internal platform and in the left at the right side we have some sort of opinionated words around things so if people are looking at this is this table or the matrix so can you just give us a very short description or in a row in a tour of how we lay down the answering and how what what what these rows and horizontal and vertical rows what question we actually trying to ask at what answer this table is actually reflecting yeah let's uh let's go ahead and do that for the operations line um the idea is for somebody to read that first question how are at your organization the platforms and capabilities plan developed and maintained and then we gave short things here because you know you're not going to put in a whole paragraph the idea is you can read the paragraphs below to kind of get an idea of what we mean but then ultimately you'll be able to come back here and you know reference these these shared ideas you know succinctly so operations talks about like how do I prioritize within my team what we're going to do next how do I make sure that the capabilities that you know are critical to the business are there how do I make sure that we're giving consistent interfaces over that um so you know as you're looking through here and in early days it might be well we don't know what we need somebody comes in and says I need a message broker so you know we get to work on that um kind of an ad hoc don't know if it's that important or not centrally tracked I can answer even go and read the description but it means that at least a central team is aware that this team is building a database service this team is building an observability service you know at least trying to put some loose coupling around them centrally enabled it means a little bit stronger governance from that central body require maybe providing a framework for people to build other services maybe actually building all those you know more of those things themselves um and then we get finally get to manage services where the services become almost end to end complete holistic services managed like you would get from a cloud provider um there's not even that you know there's a there's a much more strong separation between the consumer and the and the provider um so yeah so I guess the idea to answer your question Saeem is take that question kind of you know understand what the different categories are find yourself in there so if you find yourself right now a team came and said they needed rabbit mq so we told them go build an operator for it so that probably puts you in Sentinel that's a story that's a true story by the way that that would do it centrally probably tracked but if you could say well all systems need to be built with an operator let's say and all need to use aws or all need to use google cloud or something and everybody needs to use kubernetes as the api then you're starting to shift into centrally enabled so if you can find yourself in one of those and then say is there benefit for me because I don't want to say everybody needs to get to optimizing like you need to know is there going to be benefit to us you know in providing a more consistent interface in moving to the next level so that's kind of how we see people using that thanks thanks Josh and I think like absolutely absolutely I think that's a way of actually exploration because we literally like as Josh mentioned many of the team is actually looking at the way it's like oh how do I actually manage to put in some sort of let's say that message broker or even even if you look at the in the cloud native say I want to do a governance and automation infrastructure as code I want to push in for the service mesh so what are the different various way to operationalize and prioritize the things that the platform needs so that is basically trying to answer it as well so I think on moving on the question some of the see things are happening on the chat as well so can you actually I think before we go any further I think one thing is actually we draw upon is like in a recent we have seen many recent discussions and articles around platform as a product and a typical suggestion is that platform should be treated no differently than building any other product so if I read through the very aspect in the model what's your key take on the product mindset or is it there anything something new happening within the platform working group as a platform as a product mindset yeah very good very good segue that's a good a good place to kind of bring all this together so first I want to mention that there's an effort in our group now like I said before to interview platform builders to understand the current state where they are in this model you know verify that the model is even you know aligned with what we what's happening in industry I mean we had a lot of input on it so we think it is but we're trying to verify that so that's that's actually us treating our papers as a product and going out and learning from everybody but I think in terms of you know from the maturity model where we see that as product mindset a lot is that pink line you know as you go from being operational I've got a team you know at least providing some capabilities to being scalable to something that this could go on forever this team is providing a valuable function to the enterprise you know and is proving like we mentioned before as product in the investment category proving their value based on their users being willing to pay for them perhaps uh intrinsic pull you know I've created a product which has a market you know I don't have to force people to buy it um self-service solution so I've actually uh gone out and created something people can go to the store and and pick it up they don't have to you know call me and find me in the back channels to to actually get it and then finally well we'll skip to measurement you see insights in the third we're not just collecting metrics you know CPU usage and RAM because to collect them we actually are deriving insights and iterating on what we have based on what we learn so you know in terms of you really want to meet the the platform as product mindset that the platform engineering you know culture really advocates for if you find yourself kind of to the left of that pink line think about how you might get a little bit further to the to the other side if if that's appropriate for your for your organization amazing amazing well thank you both so much for joining us today and really telling us a lot about the tag app delivery group the white paper and just everything to focus on I've gone ahead and put up the url there in the bottom and thank you so much uh for to learn up those slides as well you can scan the qr code check out the white paper join the group all the questions that people have been asking today have been fantastic uh we didn't get to all of them uh if you want to bring those questions to the group that's that's a great thing to follow up and do um josh sign any parting words uh mantras bits of wisdom for us as we close out the stream today yes just to conclude here and then I will go over to Josh as well to conclude so I think the maturity model is a best tool to help organization reflect on their current state of platform engineering adoption and quickly determines good opportunity to mature their practices and further impact their business and the model itself reducing the cognitive load for those determining how to build a successful platforms and platform teams so josh any further words for the conclusions I think all I want to say is that you know I'm a platform engineer I guess at heart um and a bridge builder and um yeah join us it's all about collaboration and bringing everyone together so you know bridges platforms or you know bring the whole world together here so come participate with us uh come help us make the industry better thank you keep it together bring it together thank you both so much thank you josh thank you sign thank you all for watching and bringing your questions to us today uh with that wish you a wonderful rest of your day no matter where you're at and we will catch you again soon thanks everybody