 We're going to be talking about, like the slide says, platforms, cloud-native platforms, a really hot topic. Most people here, you've probably heard the past year, a couple years, platforms, platform engineering. People have been talking about a lot. The benefits it can bring, the efficiency it can bring to cloud-native development. I'm just wondering, OpenShift is a, you know, this is OpenShift Commons. OpenShift is a pretty good basis for a platform. How many people here, let's just use the word platform, identify as a platform engineer, or part of a platform team, by a show of hands. Nice, nice, pretty cool. Yeah, we're kind of interested in, yeah, the uptake of this. So in the interest, you know, we know this is an emerging trend, so we've gathered the four excellent folks here, which I'll introduce in a minute, to talk about some of the, you know, the what and why of these platforms. So we'll start, I want to introduce the CNCF work that's been happening around this. The picture, by the way, is meant, I love in the platform space the idea that you stand on the shoulders of giants, you start, you know, there's some common substrate that can let everyone get higher together, so these folks here are balancing on the top of the platform. Yeah, so CNCF, the cloud-native computing foundation, you know, we recognize this trend also, this need to deliver infrastructures, actually how it first came to us in CNCF a couple years ago. We formed a, I'm a lead in tag app delivery, where we work on all kinds of application delivery on Kubernetes, like the stuff that, where we actually get the products and applications onto the platform running for our customers. And we realize that we need to coordinate infrastructure concerns with application concerns. You know, you maybe can deploy out your clusters and your databases and your queues and all things like that, and then you put your app on top of them, but how do you make sure that you have the components ready, the infrastructure ready for your application. So we formed a group a couple years ago, cooperative delivery, about a year ago we realized that the platforms movement was the flip side of the cooperative delivery idea. The platforms are a solution to achieving that cooperative delivery that we're seeking. So we recognize that we're like, the best thing to do is to guide folks, if this is really going to enable cooperative delivery of infrastructure and apps, let's help folks understand what it is, let's try to set some common terminology, common ideas. So for the past six months, since KubeCon Detroit we've been working together. That's how I've met all these wonderful folks. We've been writing a paper, guiding kind of strategically what our platforms and why are they going to help you be more efficient in your cloud-native architectures. So check out the paper. We right now want to gather more user experiences. This is a great place to ask you all. Come join us in Slack, join our meetings. We're going to run a survey. We don't have that ready quite yet to seek interviewees. But we want to learn more so we can support you better, support end users, because that's one of the main goals of the tag is to enable cloud users to be successful. So come and join us. We're also looking to expand on some of the stuff that's in that initial paper. Go a level deeper in. Okay, I don't want to spend too much time on that. So let's just introduce our good folks here. I already said who I am. I'm Ivan Malid in Tag App Delivery, a cloud architect at Red Hat. We have Abby Bangzer from Sintasso, principal engineer, building platforms. She works on the Craddix project. Raffaele Spazzoli, a customer architect from Red Hat. He's helping customers build platforms and portals every day. Thomas Vitale, platform engineer actually was systematic and a well-known author. Read some of his spring boot books. And of course Andy Block, our distinguished architect from Red Hat who works with our customers all the time on these things. All right, so let's jump in. We're going to go around. I'm going to ask each of you a question and you could start, but everybody can chime in. We've got one mic here. And if there's time at the end, I don't see, oh, 12, 11, then maybe we could take some questions from the audience too. So be thinking if you have questions around platforms and how they fit. All right, so if you don't mind, Thomas, I'm going to start with you. So in this, in cloud computing, this context of cloud computing, what do we mean by platform? What exactly is a platform? Can you help us level set here? Yeah, platforms can be defined in many different ways. When we talk about platforms in this context, we're talking about engineering platforms. So platforms that can support engineering teams in their job, in delivering their job faster, in a more secure and safe way. And in particular, we can distinguish platforms based on who are the customers or the users of these platforms. And in our paper, we focused on internal platforms. We call them internal because the users of the platform are internally within the organization that is building the platform. So developers come to mind. So we hear a lot talking about developer platforms. But yeah, I don't like the definition because I think it's more than developers that will be using the platforms. We have other roles, other personas in an engineering team, like testers, like product owners that want to deploy an environment to show new features to a customer. But we also have other typologies other than application development. For example, machine learning. We have other companies that can use an engineering platform. We can support them in their job. And why platforms have come up in the past couple of years, but why not 15 years ago? What's changed recently? Yeah, it's not a new concept, the platforms, but I think it's becoming more and more relevant nowadays the way that we implement such a platform. So the architecture, like the cloud-native architecture of platforms is one of the main differentiators compared to the past. So we learned to embrace the cloud computing model to support all these new services, new infrastructure. Yeah, that makes sense now with more of the platform side. Yeah, Raph. Can you hear me? Yeah, one more thing that I think is changing right now with regard to platforms is that instead of just a bunch of tools, we're now trying to provide a cohesive experience. So the platform team is in charge of designing this experience for the developers or whoever the user is, such that it's very smooth and cohesive across all of the tools. And, you know, we see platforms that are constituted by, comprised by maybe 20, 25 tools. So you need a way to navigate all of these tools in a very consistent manner. You might have got more than maybe 10 or 15 years ago you might have had. Somebody had a... There was a graph earlier today. Somebody brought up a Mr. Potato Head and they put in all... And it's like your platform comes out with a proper-looking Mr. Potato Head. Exactly, not like some sort of mutant. Cool. So if a platform is, you know, it brings together those pieces and makes cloud-native development easier. What... How does this influence the... How does this... How does this valuable to our businesses? I mean, is it just developers? Does it help with the overall motion of the business? Like, why is this valuable now? Yeah, I think we've touched on a bit of it. It can help to streamline common activities across the organization. And that means we can standardize them in a way that is not just pure friction to our engineers or to our teams, right? So you're talking about security or performance or user experience, design, things like that. So a lot of people may have used kind of design frameworks before where you can go and get what a button looks like at your organization. This is just kind of taking that to the next level and saying what does an entire application look like at your organization? What does a CI CD pipeline need to entail and need to include? And so, yeah, you get that standardization without friction, ideally. Some consistency and stuff. So actually that makes me think, like in the DevOps movement, we always would say things like you build it, you run it. And now we're kind of taking that responsibility away or how does that fit together? I'd argue we keep that. So I think this is platforms can sometimes revolutionize the way organizations operate, but I actually think the concept is very evolutionary. It's not a big shift from where we've been because what we got with DevOps was this idea of you build it, you run it. The people who are building software are the best suited people to maintain and operate that with the users. And they also can have the most efficiency if they're unblocked by other teams. And we're maintaining that. We're just using our domain expertise and awareness to now craft a domain internal to the business. So just like we would have domains like a search domain or a shopping domain or different business domains that our end user facing, we now realize that there are domains internally that we can provide as a service internally. And we need to build and maintain and operate those offerings. Okay, okay. Yeah, that makes sense. And what about like, and everybody can chime in from the business perspective, does this ultimately help our businesses? Like is this just for developers that makes their lives easier? They can deliver software faster. Make some money. Yeah, at the end of the day it's efficient. The business wants to make money. No matter what, they may go ahead and juror code a lot of different things. They want to make money. And a platform can help your developers get up to speed faster, help your business make money faster because you're delivering software, and your customers end up paying more, which brings that money in. It supports all of us platform engine. Uh-huh. All right, let's, so having said a little bit about the what and why, I want to shift a little into what platforms are made of. And Ralph, I'm going to start with you on the RFA. I'll start with you on this one because I know you've been working with a lot of our customers to build platforms, but also we're hearing a lot about portals. If, actually I'm curious, who here is thinking about some sort of backstage-based portal for their platform? Okay, I was, I was actually sort of maybe a few more. I hear from customers it feels like every day about backstage and I'm trying to figure out what, one minute? Ralph, go. Tell us the portals and platforms with together. There's been a little bit of overlap between portals and platforms, right? Unfortunately, they both started with a P. So IDP can mean internal developer platform or internal developer portal. We mean platform here. And the platform is what we have described. So this set of capabilities that you build, you make available, self-serviceable, you maintain them. And the idea is, it's freedom with guardrails, right? And you may have a lot of these capabilities. Now you may need a way, a UI, a centralized UI for the developer to come and consume those capabilities. So that's your portal, right? It's a way to see what exists and operate on what exists, right? And backstage can be a good portal. I don't think it's the only option, but backstage can be a good portal for your platform. But remember, just setting up the portal doesn't give you the platform. You first have to build a platform which is all these capabilities. Then you can build a portal in front of it. It's sort of, I like to depict it as the tip of the iceberg. There is a lot of stuff that is below the water. The developers don't need to see, but it's still there. Yeah, that's, I mean, I could dig in with you for that for a while. But we better keep going. The last, yeah, well, the very last question that we can end on this is if, what are some, in each of you, we can start with Andy, what are some of the capabilities, components, attributes that you would recommend in a platform? Number one, when it comes to attributes, you mentioned your paper from earlier. There's some good recommendations in there. Make sure it's documentable. Make sure it's secure. Make sure it's flexible. Flexible is very important because, as I saw, I'm working with a lot of customers. They build these, you must, thou shall go through this pipeline and nothing can change. That doesn't scale, period. It will break. And if you're running through that right now, you say it works fine. You just started your journey and it's going to fail eventually. Number two, when you talk about capabilities, it's got to connect to your different systems, your SCM systems, your pipelines. And then it needs to connect to authorization systems. Make sure that you use the same auth that you use in other parts of your business within your platform because you don't want to have a bespoke platform team or a portal that is to be able to be totally separate from the rest of your commitment in your organization. Is that fast enough? Yeah, so any last comments? One. You want to do it? No, please. Yeah, one thing, a little suggestion if you're starting this journey with a team, building a platform team, a problem that I see often is that they do a very good job at automating the things that they control and then when they have to integrate, let's say with the DNS, that's another team or certificate, that's another team or the load balancers, the firewall, the pipeline, every time they have to cross the team boundary, if the other team is not able to provide services the way the platform needs them so to provide that consistent experience, then those teams tend to compromise and say, okay, for this one, you will open a ticket. Do not compromise there. You have to find a way to fight that battle and your mission is to provide that consistent experience so every time you publish a new capability it needs to be consistent with the rest, possibly self-serviced. Nice, yeah, hang in there, be persistent. Abby, do you want to throw something in? I was just going to say, talking to attributes, the kind of debugability and observability of it is really important because that's how you can also build trust with users. So if you think about your use of a platform being AWS, Google, Red Hat OpenShift, all these as-of-service cloud providers, you don't ever point the finger at them when something's broken. You're sort of like, it's probably my app, until the very last minute and you understand that matrix of responsibility of what is owned by which party. By you is the deployer of an app or by them as the maintainer of the infrastructure. As a platform team, you're needing to provide that same level of service and that same level of confidence in the responsibility matrix. So be able to debug your problems so that when people come knocking, you can explain to them how it's working or how it's not and what you're going to do about it. Thank you. Thomas, I want to give you a chance to, just in case. Yeah, maybe two quick pieces of advice. I think if you're building platforms, one is always talk to your users because it's very easy to assume that developers, for example, might want or need, but it's really, really important to talk with users first and establish requirements before implementing anything. And then the second thing is the cloud-native community is amazing. Let's use the community. Let's be part of the community because a lot of people have the same issues and challenges and actually working at the White Paper, I had the chance to meet with amazing people. I learned a lot coming from different backgrounds, different companies, so it's really great to be part of the community, maybe contributing to those projects that we use and embed in our platform and help those projects grow. I think that's a very important part for me. We're just starting our journey. So we need your help to help build that journey and have it evolve. Otherwise, we're not going to evolve forward. So please, as everyone said here, please help out in the community, bring your insights from your organization because everyone works differently. Let's come together and let's work together to build solutions. Yep, and that's a perfect transition to the final slide here. We definitely could use any help you can give. I know we're all very busy, but we'd love to hear your platform story. Come join us in the... And you could find all of these great folks downstairs now at lunch. Everybody should take the stairs downstairs and go to lunch. At the Project Pavilion, me, Abby, and all these other folks will be around over there. If you want to get deeper with the Working Group, we are trying to build some prototypes of CNCF-based platforms, and we're trying to go a level deeper into the different capabilities and find synergies amongst the CNCF projects. So if you're passionate about that, come help us.