 Hello. Welcome. Good afternoon. Thank you all for joining our session here, joining our panel. Platforms all the way down. The reason why we named it that, we're partially representing CNCF's App Delivery Technical Advisory Group. And the group has been writing papers to help users adopt platforms and platform engineering. And in the definition of platforms that we shared in our first paper that we released in April, the way we defined platforms as bringing together a consistent set of capabilities to serve some purpose, some end user purpose, ends up, turns out that that describes not just the platforms that we use in cloud computing, but really describes all of the layers of platforms and abstractions that we often have in computing. So here's an example where we go from the early reprogrammable hardware to operating systems abstracting out hardware to infrastructure as a service abstracting even more hardware, and finally we get to today's platform capabilities. I wanted to ask, before we start the panel, how many people here work between the layers of infrastructure, you know, rack and up servers in the data center, and actually writing app code? How many people are a platform engineer or a DevOps engineer, someone supporting, wow. Good, I guess I at least stated that clearly. I was a little worried about that. Okay, so with that, I want to go ahead and introduce our panelists or ask them to introduce themselves. So we'll, if you could just share your name and your role and why you're interested in platforms. We'll start with you, Colin. Hi, I'm Colin Griffin. I'm founder and chief engineer of a company called Crumbware. We're a software development consultancy. We teach software vendors how to develop and deliver cloud-native solutions. Platforms were important to me. I got involved in platforms because I come from the application development and delivery side. And as we started to teach and work with software vendors and help them understand what is this containerization stuff, what does this look like, we started to realize when we were trying to deliver products and hand them over to IT ops teams and folks that were going to maintain these applications, they couldn't even spell Kubernetes. They didn't know what the heck we were handing over and it was really, really, really challenging to actually get them to adopt this new way of thinking. So it forced me back into understanding how do we actually treat operators as someone we can deliver to and how do we treat them as an end-user and develop our software and experiences to be supportive of the operators and not just the vendors. Very cool, thanks. Hi, my name is Abby Bangzer. I'm a principal engineer at a company called Centasso and we're building a framework called Craddix to help platform teams build those internal platforms to their specifications. My background in platforms is that I actually started in software delivery as a quality engineer and it's been an entire journey over the last, over a decade in the industry of how do you deliver software faster, cheaper, safer in different ways and that started maybe as test automation or analysis, but it evolved quickly in my career into DevOps and platform engineering and I've had about five years of building platforms in organizations before I thought this is too hard and now I'm trying to make it a bit easier for everyone else. Hello everyone, this is Srinivas Peri. I'm from Adobe. I'm a director of engineering there and I'm part of a developer platform's group which is the foundation platform for the rest of the platforms. I've been at Adobe for the last 20 years and I've seen quite a bit of transformation that Adobe has gone through over the last 20 years. Adobe products. Cool. My name is Joe Natali. I've been a discoverer for 15 years. Most of my time focusing on the payments line of business in software development, software architecture, that kind of thing. The past three months I transitioned over to the platform area curating our platforms and observability. Yeah, and I guess that leaves me. I'm Josh. I am a solution architect for Red Hat and so I'm constantly encountering customers that like Colin was saying, I just need to help their platform engineers, their supporting teams enable their app dev teams. So I just find that that's so important and that's why I'm part of our platform's working group, CNCF Tag App Delivery to try to help customers develop these in-between teams to best support our app developers. Okay, so thank you all for introducing yourself. Very cool platform of platforms I especially like because that's something we've realized this year is that it's not just one platform like we were saying before. It's a whole bunch layered on top of each other. So the first question that comes to mind in a panel about platforms is can you all define for us and we'll start with Abby on this one. I don't remember which one we said we would start with. That's okay with you. Can you define what is a platform? Yeah, and I think you gave a bit of an explanation that just in the English dictionary a platform is something you can build on top of. You can build a higher level of abstraction, higher value on top of. What we're here talking about is cloud-native platforms and so in that space what we're talking about is a set of capabilities, documentation, processes, things that are common to your organization that help your business value get delivered to your customers faster and safer and easier. And so what we're often talking about is, as I say, a set of automation, but it's not always automation depending on where you are as an organization. Alright. Colin, would you like to take a shot at that one too? So everything Abby said, obviously, which is great. One of the reasons we're working with and we have the Platforms Working Group is there is a lot of different opinions about what a platform actually is and what that definition is. And so we're working to try to define some of that language. For me personally, the concept of a platform is a cohesive set of tools, processes, services, a singular set of things that we can provide to end users where we're enabling end users, the operators themselves, those folks that they can actually play in the same sandbox. And the work that they do and they contribute via the platform moves the business forward. It accomplishes some sort of business value. And the strategy to make those tools and systems work together and serve that common purpose or that greater purpose, that to me is the concept of the platform. Bringing together something to serve a greater purpose. There was someone in the Keynotes this morning that reflected on a platform, four platforms and she talked about MLops platforms and data platforms and other kinds of platforms. So that struck me also. One of the things in our definition of platform that we put out in April is we talked about a bunch of capabilities that you should consider and should strongly consider having in your platform. So I wanted to specifically ask Perry and Joe what experiences what are the most important capabilities to provide? What were some of the first ones you provided in your platforms? So Perry, can we start with you? Yeah, so let's also start with what we see as a platform, right? That'll be great. So I think if I have two words to define the platform, the first one I would say is the multiplier effect. Meaning you have this security patch that you need to do. How long does it take for 40 teams to do it? What if if one team, everybody is dependent on using those libraries and they upgrade it and we are done, right? I think multiplier effect is one of the big things that we at Adobe take into consideration while we do it. And while doing it, right, the second word I want to use is it has to be when it is all working, it is invisible. We do have one of the platform component called BBC's. We call it as a blessed base images. In 2016 and 17 it was a pioneering because we had to kind of like how do we get this images, what do we do it and all that. We hardened it so much, we put a factory around it and all that and as we speak day in and day out people use those BBC images all the time. We never talk about it in our team meetings or in our next plannings and all that. I think when it is working it works. I think multiplier effort and the invisible are two important components from the maturity perspective. Coming back to capabilities, the way we kind of look at the capabilities is security and compliance of table stakes. Because when you are not, then you are not getting the deals that you are looking for for the enterprise deals. That needs to be there and you got to make sure there is always there. So those are clearly the stable stakes. Then it comes into the next two things, which is infrastructure, reliability, stability, stability as a product and that part of it and then the developer experience on top of that. And cost efficiency is always an attribute. We don't start with that, sometimes we have to start with that but that is always there. Okay, so those are four top cost efficiency developer experience, security and infrastructure. Yeah, great, thank you. Joe, what do you find have been the most important capabilities that discover? Yeah, so we try to focus on establishing sort of a consistent user experience between like our private clouds as well as various public cloud offerings. So that is something we still find to be a valuable piece of the platform is sort of that cloud neutrality or infrastructure neutrality. On top of that, we built a lot of self-service capabilities. Things like queuing, caching, databases these are all things you can declare in your YAML and the platform will provision for you. And then on top of that secrets management, managing and rotating secrets observability and then like Perry mentioned, some of the table stakes stuff like security and compliance. So our pipelines can submit a change ticket for you if you're doing a production deployment. They stash off your testing results into a place that's auditable and you can retrieve that stuff for regulators if they ever come asking. So just hiding some of that stuff from the developer community and making it consistent across thousands of developers is something that we find kind of attractive from a platform perspective. Really interesting. I'm kind of hearing from both of you that whatever capabilities you do, the important thing is to be as transparent and best experience possible for developers and be a stable because you mentioned stability too. So it's about those qualities. Alright, well thank you all for helping us define what a platform is. That kind of takes us to the next question, kind of begs the question. So we understand what a platform is. Why exactly are you or your customers building these platforms? What values, what goals do you hope to get from them? Colin, we wanted to start with you on that one. So platforms, why are platforms important? I think we're joking outside when we came in. The two big words that we're hearing a lot at KubeCon this year, it's Argo and platforms. And I'm glad we're not playing a drinking game around that. But platforms for me are very important, or at least the concept now that we're bringing up and we're highlighting this term of platforms. A platform strategy or platform engineering is not a new concept. It's been around for a while, but the discussion is very new. It's very fresh, and that brings some new ideas. Implementing a platform strategy allows us to, it works as a carrier where we can bring in product strategy and teach infrastructure providers or internal platform teams how to care and assess for their end users. And these are things in IT ops that may not have necessarily been on the forefront. When we introduce and inject this platform strategy concept, the idea of understanding what your developers actually need to get their jobs done and use that as a driver for developing new technologies and these new capabilities and these tools, then it allows the organization to move forward and hopefully actually pick some things, but most importantly it creates that dialogue between app and dev, between IT ops, between the data teams, it creates this centralized conversation, but we don't have to treat internal users only with this mindset. If we're developing SaaS applications and everything else, we can treat outside parties and external developers with the same mindset. When we talk about removing and eliminating cognitive load and making things easier, if we're thinking about it from a product development strategy as well, approaching a product development with a platform mindset allows us to eliminate thinking about our users in different ways. We can think about our business, our people, our external users in one similar way. Cool, so platform, by adopting platforms you kind of direct the attention to the user's jobs to be done. Cool, thank you. Joe, at Discover, what are some of the why did you build the things that you've built? Yeah, so we saw a need for sort of more of a full end-to-end flow for developers. There was what I'll call some high-friction processes as far as moving code from your laptop development environment all the way through to production. There were lots of manual steps, like I said, lots of high-friction processes to get that done, and what we wanted was a consistent way to do that across varying scrum teams throughout the whole organization. So having that sort of consistent delivery process across the board is part of that value proposition for us. Very cool, very cool. So I'm kind of hearing from both of you, accelerating development, accelerating your app developers. Perry, if you could answer that, and also are there particular values that you espouse in your team, like platform as product or self-service? Yeah, at Adobe, why have you adopted platforms with one of those values? Yeah, like I mentioned, I think platform has been there for a long time. We have been using for a long time. So I think the first thing, why the platform started and why we do that is always very clear because there is a business need, and it helps with the business velocity at that point of time. So it doesn't have to be a platform that has to be adopted by an entire company at that point of time. If there are some big business things that are happening that time, and for that product team cannot handle it, and there is a subject matter expertise everywhere, and this is the time probably we have to start it. I think most of the platforms at Adobe from 2011 have started small, trying to solve too big business use cases at that point of time. And then later on evolved into the big part of it. I think that's one of the things. And second thing that I would say here is developers, most of our development teams have a breadth skill and depth skill. So you have a subject matter expertise. There are some React developers, there are some Go developers. You have to enable for the business to move fast that group focus on that part of the thing and then free them up from the other concerns. That's where the invisible thing comes into your mind. And then you have the development team here as well. So if you can group the similar kind of groups at one place, so then they can watch the trend of what's going on, who is just responsible it is to watch what's going on with the Kubernetes and upgrade the APIs and everything and all that, that group because the rest of the Adobe can focus on the other parts of it. I think these are the two big things on why we have to do this. We have to go through all of that. We can talk about that. Got it, got it. Thank you. Yeah, Abby, do you have any thoughts on this? Yeah, I think these three have covered why platforms really well. I think you also were asking some questions there around what characteristics of the team kind of drive out that platform delivery and I think some of the things I think about is that what platforms do is they scale for us. DevOps is the kind of way of working of believing that you build and operate your services. But when you need to build and operate from kind of the bare metal all the way through to the design of the user interface, that's a lot of things to build and operate and what platforms do is they take some of that aspect away and give that to a different team and this is not back, you can think this is back to dev and ops, we've been talking about the dev and ops but it's not, it's applying the dev ops principles but at layers and allowing us to build on the shoulders of giants. So the platform team builds and operates their services while the application teams or other platform teams that build on top build and operate their services and so I think this is what allows us to scale specialists in an organization as big as Adobe and Discover and others where you still need to have the data consistency and reliability that you need. I think the other, the only other thing I'd call out is the kind of as a service pattern which I think I really like that we're talking about providing services to the users of platforms these days because we kind of all as humans know what services are, we know what we expect, we know that we want them to meet us where we are, we want to not have to think about how they work, we can find them when we need them, we don't have to pick up the phone, we can talk to someone, we can get access to them when we want, how we want without help. We're now finally applying those human expectations about services that we have for booking our restaurant reservations and getting access to TV shows. We're applying them to our daily jobs and I think that's a really key aspect of what platform engineering is bringing today that is I think reinvigorating a very long term conversation about platforms. Very cool, yeah. So we're able to I heard a lot about we're able to isolate and let people focus and we're able to deliver better products as a result by letting people focus on specific things. Okay, so I don't know how many people here are aware that CNCF just published a couple weeks ago a platform engineering maturity model. That's pretty good. I see a few people. Thank you, that's great. And thank you very much to Sintasso and to Paula Kennedy sitting over here. Thank you very much for getting us started with that and donating the hardest part is getting started. So this kind of reflects at a high level the matrix that that maturity model offers and there's a lot of caveats around this and you know don't put yourself down if you're not at L4 and read the paper for more on that. But essentially we sum things down through a lot of conversations with some 50 people over the summer from various backgrounds to five aspects to consider within your platform engineering maturity and in those five aspects a continuum of four levels of potential characteristics of potentially where you might find yourself. So the five aspects are investment, how your company, how your organization funds and puts people into platform engineering products. The next one is adoption, how it is that your users go about finding and picking up and using your products or your platform. Interfaces which is the CLIs and the APIs and the UIs and the different tools that you provide to users to use your platform. Operations is the way that you prioritize work within your platform teams and the way that you organize those teams what kinds of roles you might have on those teams. And then finally, measurement is how you measure the impact of your platforms and whether they're having the success and meeting the goals that you wanted them to meet. So I wanted to ask the panel now around, so this kind of adds like a dimension of time to the whole thing. Like how have our platforms changed over time? And so I wanted to maybe start with Perry on this one. Especially in the adoption, let's start with the adoption interfaces aspects. How have you seen Adobe's platform change over time in terms of the interfaces you provide, the way people come to use it? Could you describe that for us? Yeah, sure. Before we just do that, I think I bumped into this only two weeks ago and I started an internal thread. We are actually having a good brainstorming on that and how we can map it to this one. This is good. And I also want to call out for the folks who don't know, there's another project called Kano CNOE. So they are also trying to get this part of it. I mean, these kinds of initiatives are great, so then we can map it to what we are doing to the bigger picture, right? Yeah. I think on our side, actually I was having a debate with my team. My team is sitting over there, whether I should bring this up or not, but I will bring it up anyway, okay? So the thing is adoption and migration are the two different words, right? So the thing is if you have signed up for the platform team you pretty much are owning the migration. It's your responsibility to make sure you do the migration. You just let your clients know that so and so, so and so is migrating so that they know about it. You don't put them on the spot and then add to their sprint back locks and all that we are migrating, you got to do this, right? Yeah. I mean, that's one of the big things around it's a hard job. I think as a platform, you cannot do that all the time, right? I think that's where as you build the platform and they will commit that never happens. That never ever happens, okay? So adoption is one of them. No, if you build it, they will come. Yeah. So adoption is one of the very, very interesting challenge of the platform and there is no magic to it at all. You got to start with and you always need to have your friend and your buddy on your product team who are actually talking about your product or talking about your group and then be enthusiastic about why we are building it and using it. That lighthouse phase of it is very, very important. Most of the platforms that we build that's how we were able to become successful with that, right? By marketing. Yeah. So we call them actually, we call them platform champions. They are not part of our platform group. They are part of the product group, we actually call them as a platform champions and we actually train them, we give them the badges and we give them all the recognition, everything and all that because they do all the hard work of getting to, letting us know how it is going and all that, right? I think that's a big part of our product. And it's not like you do one time, you are done with it. It's not because if you think about our journey of what we did over the last six, seven years, right? It's kind of crazy to be honest with you. Okay, we started with our own CICD tool, right? Because we did not have a good CICD tool, it was in 2015. And that time we knew that there is something called Kubernetes but we can't even spell it that time. So DCOS was the right thing. So we had our CICD tool, in-house custom tool work with the DCOS with a good abstraction, right? So that's a good part of we did abstraction. We did an abstraction in 2016. That helped us quite a bit in 2018-19 to go to Kubernetes. We said it's a migration as a product. Our end users does not have to do anything. We moved all of them behind the scenes, okay? That worked out quite well at the point of time. But that's not it, right? I think the story is with the Kubernetes, if you keep abstracting everything, so then you are actually making it slow. So then you need to kind of get into these GitOps and the new kind of a thing. Now we are going into another phase where we have to continue that journey again. So depending upon maturity of where you are, it's an ongoing journey. It's an ongoing journey to continue to invest on it. Yeah, that's a really good insight. It's not enough to just start the team one year and then just let it go. You've got to continually train up those folks. Colin, do you want to take a shot at that? How have you seen things change over time? So I kind of want to look at the measurement and look at some of the aspects as well. As far as kind of measuring and looking at how things change over time, because a lot of us are here to figure out what the heck a platform is and how do we get started. It was one of the reasons we wanted the maturity model or built that in the first place. And thanks to Centasso for donating and getting that rolling as well. That was a huge help. From a measurement standpoint and thinking about where we get started, we have to start with a baseline. We have to actually document our platform. The first measurement of the platform is just our inventory. Mapping out the capabilities that we need, making sure we have a clear understanding of who our users are and what they actually need, what tools we have in place, and making sure that that's documented. That also goes back to operations and interfaces. Your documentation is an interface. It helps people understand how they're supposed to use the platform and leverage the platform to get their jobs done. So the best place to start is to get a tool to define who is responsible for what today. Over time, as you learn more about your users and more about the capabilities they need, that will change. And you'll be able to introduce new capabilities and swap out old capabilities and start to move on that path to migration. Now, that goes back to another measurement which is you could call it, I guess, Net Promoter Score or something similar, but how well do your users actually understand how to use the platform? That could be, if you're providing a platform to third-party users, does your documentation enable them to get the full experience from what your platform provides? Is that there? Does that exist? For most cases, it does not exist. So getting that documented and measuring how well users can leverage your platform and effectively use your platform is important, but then that all leads down to velocity. I want to make sure that as we introduce these new capabilities that we're helping people get their jobs done easier and faster, that we ship products and that could be a data workload that's generating a report. That's a product. It could be a new app that we have developing. That's a product. It could be a sales report that needs to be sent over to my super. That's a product. So is our platform enabling them to do those kinds of things? But it starts by working through the process and map yourselves to the maturity model. It actually works really, really well. Thank you, Colin. Thanks for talking about measurement. Abby, is there a particular category in here which you would like to share your thoughts on? You could take adoption and interfaces if you'd like, but... Sure. I think we've covered those a little bit. I think maybe one of the ones I'm most passionate about because I come from more of the internal infrastructure upside of things is operations. Because I think one of the things that I run into a lot in my experience as a platform engineer, I was so proud of the capabilities I provided to my teams, that I jump-started teams, got them moving quickly with templates and quick starts and things like this. And then we had to migrate. So you're talking about migrations. You're talking about the fact that you want to move to Argo to get ops and things. That was exactly my journey about four years ago. Three years ago, something like that. And we had... It was a pretty medium-sized organization. There was maybe 50, 60 different apps in a team of maybe six or seven platform engineers. We had to manually figure out how to move all these along. They all started with our template, but everyone loves to change a template. And it wasn't something that we could operate on day two. And I think the thing about operations that we were trying to... that we really discussed in depth with the members of the group as we were doing this, was what it looks like to have day two operations built in as a mature early-stage aspect of your platform. I think there's concepts around... you'll hear like fleet ops or fleet management, things that allow you to have that sort of impact of rolling out upgrades, having that sort of transparency to changes on your platform. And I think that's what you're starting to see through that operations aspect. And again, there's like 15 pages behind this that describes a lot of characteristics that you might see yourself in and will help you attach to some of these. And I think that's really exciting. Cool, thank you. And that reminds me, we actually have some papers up here and if you want to come get them after you can, or we'll have them at the Tag App Delivery booth later on, but they contain some of this information for quick reference. Joe, would you be interested in trying to discover what you want to pick up investment? That's the only one we didn't talk about. If I must. No, I think one thing I'll say just holistically on the maturity model is I think maybe a trap we've fallen into is we're pretty reactive to identifying gaps or enhancements to our platform. And so having the maturity model will give you a snapshot of maybe where you need to make some investments. Maybe it's you need more focus on your platform team. Maybe you need to reassess just the way you're provisioning back-end services. Whatever it is having that maturity model that you can kind of come back to on some cadence and actually track your progress will help you just be a little more proactive as far as just reacting to when a consumer says, hey, can we get this on the platform? So I think that's where I see a lot of the value of this thing is just to measure yourself and track your progress. Cool. Thank you, Joe. Thank you everybody. So before we wrap with one more question I just wanted to put up this call to action. We're always looking for end-user stories for people that are passionate about helping us edit up our documents and the advice that we try to share for people that want to help us create prototype platforms or sample platforms to help others please come join our tag, read the papers, come visit us in the project pavilion the next couple of days. We'll be there in the evenings. Join the Slack channel. There's always a lot of chatter there. Yeah, and with that I want to ask everybody and we'll start with Perry here. If you could share one last story, something unexpected some lesson that you can share with us about platforms and platform engineering. Yes. So I think as shiny as it sounds it's very, very, very hard work. If you are signing up for being a platform team, whatever the size is, wherever you are in maturity, you are taking on a lot of responsibility. And people will remember you only when things go wrong. That's what it is. I think some of the areas where we will do better and we all have to do better is every day is a good day. Every day we need to learn something. We need to show the glass half full story of how fast you have made your deployments and what is how did you improve your success rate based on four weeks ago. And all those kinds of things we have to invest on that part of it and show your progress because that will keep your team motivated, that will keep your leadership motivated, your clients motivated. You have to tell that story and you have to be very, very motivated. And when we come to this conference like this, we learn stuff and when we go back, some of the things that we promise that we will be doing, we have to think back and see maybe that is not what we do. Maybe we found another partner, we found something else. I think those are the kind of conversations we need to have while that is still fresh. And then when the plans change, we have to communicate accordingly. So I think you have to enjoy this. Once you are enjoying it, you will just be aware. Yeah, Abby, would you like to give us a sum? Yeah, I think it is hard work because it is a product and products are hard work. I think that is the thing I see the most is that this isn't new or different. We need to think about our users, we need to write extensible, maintainable software. We need to think about how to absorb commodities as they become available in the ecosystem. Just like you do in a product, people today aren't really building their own payment front ends anymore. You can use Stripe for a lot of these things. There is all sorts of things we used to have to build we don't have to anymore. That is true in the platform space as well. I think what makes it so hard work right now for platform engineering is that the tools aren't there. We stretch arm-stronging between very low-level aspects to very high-level abstractions that are being expected of us. It is something that we are starting to improve on as an industry. You are seeing that in the vendors here at KubeCon and around the industry. I think that is the exciting movement right now with this re-invigoration of platforms. Would you like a chance to go Colin and Joe? The only thing I will add is along this, just to add to what Abby mentioned about products is platforms are a set of capabilities in products and they should with the same rigor that you would treat a product you expose that generates revenue. A backlog, a product owner product management, proper teams like having that stuff established day one is going to be critical to the success of this thing. Alright, thank you so much everybody for joining us. Thank you so much our panelists. We really appreciate these insights and have a great rest of your conference everybody. Thank you.