 Hello everyone. I'd like to welcome you to our next session, Platforms and Portals, a book and its cover by Josh Gavin. Josh is a solution architect in Chicago, North America, helping Red Hat's enterprise customers build application platforms using Red Hat OpenShift middleware, runtimes, developer tools and services, basically an all-star. He also leads a CNCF stack app delivery, where together with the community he develops, advocates for consistent patterns, conventions for cloud app delivery and cloud app platforms. In today's talk, he'll be sharing how platforms and portals work together, like the title says, and increase your app developer satisfaction and productivity. So I will get out of the way and let Josh take over the stage and present the most interesting topic today. All right. Thank you. I'm excited to be here, excited to talk with you all. Today we're going to be addressing the recent trends, recent conversations about platforms to make cloud computing better. There's been a corresponding discussion recently about portals, backstage, so we're going to talk about how those things relate. I'm going with the analogy of a book and its cover. This is the first time I'm using that exact analogy. We'll see if it works, but hopefully it will help you understand the concepts a little better. Like Ramsey said, I work for Red Hat with our customers to help them build platforms, help them succeed with their applications in cloud native frameworks. And I also work with the leader and tag in CNCF, trying to make cloud better for everyone, make it more efficient, truly realize its potential. So our agenda today, I'm going to spend a few minutes talking about kind of setting the stage, what exactly is a platform and why you'd want to adopt them, why in particular now, how they're coming about. Then I'm going to shift into a little more technical discussion of why Kubernetes is a great platform for building platforms. It's an ideal answer to some of these requirements, why we want platforms. And then we'll end with the cover of the book, developer portals and how they make it possible to use the platforms or understand what they're about. Okay, so we'll start out asking what exactly is a platform and why it's valuable. So for a really in-depth review of this, check out the white paper here. The URL for this whole deck is I'll share it at the end. But check out the white paper from the group that I work with in CNCF, where we try to kind of provide a common definition that we can all kind of rally around. And I tried to highlight here the key points. So there's kind of three layers in this diagram on the right, which is seem to be pretty popular. You've got your product teams and your application teams on the top. You've got your infrastructure or service providers on the bottom. And then you've got your platform, which is bringing together a collection of capabilities. Sometimes you might write them yourself, but a lot of times you're going to be getting them from providers either inside your company or outside, bringing them together in a consistent, coherent way to serve some purpose, needs of the platform's users. That's why I highlighted it here. It is really important that they, well, they need a pipeline for some purpose. They need a message broker. What are the needs that your users have? So a platform is this consistent, coherent, full coverage collection of capabilities that you can integrate into your application. At least that's how we define it there. What we kind of realized, I actually have been talking with the other folks in the group, and they've come to the similar realization is that based on how we define platforms as collecting up capabilities for a common purpose, it's really always been this way. Computing has always been a platform somewhere. It's just a question of where you draw the line. The ladies at the far left here reprogramming the machines, they were certainly reusing the same hardware, programming it in different ways. In the 80s with the emergence of data centers and operating systems like Linux, Linux definitely made the machine reprogramble, so it didn't need anybody patching cables like in the far left, provided a common layer over the hardware and the data center. In the 2000s, infrastructure as a service, VMs, EC2, cloud, the initial wave of cloud lets us not even worry about the machines, the hardware at all, the operating systems are on those. We just get compute, we get network, we get storage, and we get to use them. However, we don't see the data center underneath. Where we're reaching today is platform capabilities. Rather than just giving out compute network storage and saying, install your database, install your application, developers are demanding higher level capabilities. Those icons are all AWS services in this case because I first put the graphic together there, but it's SQS, it's code build, it's RDS databases, I'm giving a higher level capability to my application developers. Of course, none of these really go away, except maybe the patch cables at the far left. There are still plenty of use cases for using direct infrastructure as a service, but there's a lot of possibilities from the higher level. That also begs the question, this slide, why is platform so important now? Why are these platform capabilities? It's been around, there's always been a platform line, why are we talking about platform engineering? It's because of this. This is a cloud native application. This is a diagram of one that I built five years ago, even. The point is to show that my application is distributed and it's got a lot of capabilities that it needs to bring into. There's only two microservices here, that service that says go and a service in Java, and then of course the browser side application running in the browser. Those are distributed, but then it's got all of these capabilities that needs to pull from the environment. Databases, blobs, it needs an observability system, it needs a directory so users can authenticate, and then the bottom left you've got the whole developer story where a developer needs to store their artifacts and push them in there. So with these distributed applications, we end up needing to account for distributed capabilities as well. So now this is those from that middle layer before, I didn't draw the arrows here, but pick and choose from the stuff on the bottom and match it to the capabilities that your app dev needs at the top. We tried in that paper, which I linked above, we tried to posit an initial list of the capabilities that you should consider for your platform, mainly to give people a place to start and to think about and think where they may be missing, because again we always emphasize build it for its users. So if you don't need a certain capability then don't do it. But these are a good foundation to start. Before we wrap up this kind of introductory section, I did want to just give another potential tip that could help us understand and develop a common understanding of where platforms and DevOps are coming in. So this was one way of characterizing it. I've seen this with customers that I've been talking to, kind of this three tier. I'm very curious if other people are seeing this and you want to put it into the chat or in the definition slack. There's an application team or a product team or a workload team that's creating the actual end applications that you're serving to user or services that you're serving to your end user. You've got the classic infrastructure folks who are building data centers and racking up servers, maybe installing OSes, maybe running clouds and running cloud accounts, things like that. But when I ask those folks like, okay, who's providing Kubernetes, let's say, or who's providing pipelines to their application developers, a lot of folks talk about a DevOps team or a platform team. So I'm beginning to think that there is a trend like that. Like I said, I've heard it from several customers. I think there might be an evolving trend where we've got this three tiers. You've got the people that are building your value stream applications, the stuff that's delivering your value to your end users. You've got the folks that are in the back room, making sure the lights are on in your data center. But then you've got a team in between that's kind of bridging and bringing those capabilities in a consistent way to the app dev team. So I kind of characterize that as you build it. We run it, which honestly, I think it's always kind of been this way, like somebody runs your data center, most application developers have not wrapped up a bunch of servers. It's always a cooperative effort to be honest. But yeah, just emphasizing that more here, like the platform engineer is going to help your application, your DevOps engineer is going to help your application developer. And together they're going to be running it. So the platform engineers might run Kubernetes or run Tecton, which is a pipeline's framework. But it's going to be our application developers who say, okay, here's a deployment or a pod or a pipeline that I want you to run. They actually create the stuff that's going to be run. Similar thing with all the other characteristics, the platform engineers will write, let's say, an operator to manage DBMSs. But then the application developer says, okay, I actually want a specific database for my app. Platform engineers might run an enterprise-wide message broker, but then an application developer says I need a topic in there. Platform engineers might run an overall telemetry system, but then the application developer says, okay, I'm going to insert my instrumentation into my app. So that's one possible way to think of that relationship. Okay. So now we get into, this is really what I have always been into before I tried to justify why we need platforms. Kubernetes is a great platform for building platforms. It's maybe the best one to address some of the requirements above, provide that coherent consistent set of capabilities. So let's talk about what a control plane might look like without Kubernetes, a platform control plane. So if we kind of look, I took AWS as an example here, but you could substitute any other cloud provider really, what their control plane looks like or how you get into their platform. So looking at kind of that middle box, if you think of that as the control plane where they're providing their interfaces, mostly going to be API, even if they build experiences on top of that, let's hope there's an API at the back. There's an API which a lot of toolkits build on. And then behind the scenes that that relatively consistent API, AWS, depends on the cloud, some are more consistent than others is going to deploy all of the capabilities and resources from the, from the cloud provider. Where I'm really going with this though is what happens when you want to go multi-cloud, you want some services from Mongo or Cloudflare to go along with your AWS or Azure services. You end up with a different control plane for each of those providers. Even if it's just as simple as getting a database from Mongo, their API set and framework is totally different from Azure's. And of course, the big clouds are each different. You're going to use cloud formation in AWS, you're going to use Azure Resource Manager in Azure, even if you use Terraform, which does bring a little consistency, but there's still different API attributes and shapes. VM and Azure has a different parameter to define its type than one in AWS. So this is what ends up happening without Kubernetes. But Kubernetes lets us bring this all together in one consistent API. So a little bit on Kubernetes' API. So this middle layer here is kind of Kubernetes in a nutshell, missing the scheduler, but you've got that API interface, which everything on top is going to interact with. So CLI SDK, things like CDKAS or kubectl, infrastructure is code tools, Helm, even Terraform and Pulumi are using client though and things like that underneath to talk to the API. GUIs like backstage or headlamp are also calling the API and even GitOps tools are ultimately, Argo CD is calling the Kubernetes API to do its work. The API just persists something into at CD and then controller manager, that's what CM stands for on the other side says, oh, something relevant to me has come in on the API server or yeah, actually doesn't go from at CD to the controller manager goes from the API server, but that's close enough. Controller manager learns, I've got something to do and then continuously reconciles that that's what you see next to the controller manager, the CM icon there, that's actually the GitOps logo. So it's supposed to represent continuous reconciliation. And in this area, I think it's worth mentioning there are really three, maybe even more kinds of resources, which Kubernetes manages, up to the first few versions of Kubernetes, the focus was really on built-in types, kind of like the initial release of iOS, didn't even have an app store. So up to version one, seven, there wasn't a stable, that's when CRDs were introduced, one seven, but those first ones were just, oh, I need a stateful set, I need a deployment, I need a demon set, those are compute, I need a service or an ingress, those are for network, I need persistent volume, that's for storage. So just not coincidentally, those are pretty low-level infrastructure as a service primitives. But with CRDs, with that ability to extend the API, we got a couple other kinds of things here in cluster. So that's all those CNCF projects and I could have just copied the landscape down here. A lot of those can be provisioned, almost, I'm pretty sure, all of those can be provisioned via Kubernetes APIs. And then even provider-managed services, so stuff from AWS or Azure, they provide first-party, it's created and maintained by Azure and AWS themselves, ways to project their APIs through the Kubernetes API essentially. And if you're looking for more cross-plane supports, even things like GitHub and GitLab to create repos, DigitalOcean comes through there, so there's even more there. So the point is that that basically Kubernetes, everything moves, if you kind of look at it, this bottom box, everything moves behind the Kubernetes API. And that gives you a consistent, coherent way to deploy all of the capabilities for your application alongside them. So it kind of meets our platform requirement. Yeah, so I want to switch over and do a quick demo of what a platform built on Kubernetes could look like. So I'm going to show a platform that I'm going to show an application being deployed onto that platform. So I'll start out here in my hybrid cloud console and then jump over to my AWS instance. I've got OpenShift running here in AWS. And one thing that I like to show, I think this highlights the point, API Explorer, which by the way, you can do this at the command line too with OC or kubectl API-resources, see everything that's been installed. But here's a nice way to search it. I like to just point out like, hey, I want to see, I've already installed the things that back, that implement these APIs, these resource definitions, but I could create a Quay. I can create a key cloak I've installed here. I could create a Yeager instance. There it is. I can create a Postgres cluster actually. And some of them, I'm not going to really spend a ton of time here, but I could actually, they come with a form. So let me go to instances here. This is how you do an OpenShift, just to create deployment. You'll notice everything we give a form view that's already filled out and you could even drill in here and find out more details about the parameters. Sorry, there's a YAML view and a form view. Some of them have form views. So I'm not going to really spend too much time, but pretty quickly I could get spun up here. A deployment, a service, an ingress, any way I want, and create the things I want in a consistent way. There's also search, which lets me do the same kind of thing over those resources. So if I want to find all of my Quay registries, I can say, give out my Quays, and then all projects, let's just say. And there's my one registry. Kind of related to this also, when you're going to install new capabilities in Kubernetes, it's unfortunate that there still are several different ways in the community for doing this, but one nice way built into OpenShift is Operator Hub, which lets you in a consistent way, remember I love that consistency, pull in operators for all kinds of different resources. So here's certificates, here's my cluster logging stack, Yeager, here's the Loki stack for monitoring, et cetera, OpenTelemetry, Quay, this isn't even all, everything I've installed, TechTons here somewhere. Okay, so I've showed you the cluster. Now I want to show you on top of this platform how I would deploy apps. So I'll just show you, luckily GitHub is back up now, I was counting on using this, I'll make this a little bigger. This is my platform repo. So I've got clusters here, where for example, my deployment of this cluster is all documented here. But then I think what's most interesting, and you might want to refer to this later for some ideas, is the, is this collection of services. So basically for every one of these, it's a few YAML files and a script to deploy them. This could be, sorry, GitOps purists, I know I could do a little better than that, but that's the platform repo. But now what I really want to show you is the Spring API server repo, and how it's going to use that consistent set of interfaces from Kubernetes to deploy this app. So in my, the main point of this repo, the main place that I'm going to show is in this deployment folder, deploy folder. And here in this space, I mean, if you use Kubernetes a lot, this is not going to be a huge surprise, but it's, you know, here's a config map for my configuration, deployment for my compute, instrumentation to add open telemetry, PGDB gives me a cluster, a Postgres cluster easily. Here's my Prometheus monitoring. At the top level, because this is where it needs to be for the implementation and openshift, I've got tecton runs. So if I make a change, if I say that I want to deploy three instances of this Postgres database to make a change here, it will instantly pick up and run the pipeline run that I've described here. Yeah, so then at the end of the day, when that gets applied, I use, I'm using the cluster Argo CD, which may not be the best practice, but it eventually, that's defined down in here, the same Spring API server under deploy, it applies that Argo CD application, which says, look to this path, pull up all the manifests from that path, reify them in the cluster. Luckily GitHub is back up and working now, so it's able to sync. And then I could go in and OpenShift has this nice dashboard. I just find my Spring API server and it says, hello world, working, there's my widgets too. Okay, so yeah, let's keep going. So we showed there a, we showed how you could build a platform using Kubernetes and OpenShift, provide a consistent set of interfaces by extending essentially Kubernetes with additional resource types and then leverage all of that in a separate repo in your application, where your application developers just declare that, they use the API and they declare, I want these resources and then some sort of GitOps tool makes sure that they are there as declared and stay there. Okay, so till now we focused all the platform or at least I would call it the platform, the core part of the platform. This is kind of the book, I guess, in my analogy, a book in its cover, you know, the core content, the core stuff that's going to run your infrastructure, your compute network storage, your pipelines, your databases are all part of that platform. But a book without its cover is not all that appealing or it's hard to know what it's about or it's hard to use it. So we need a portal of some sort. Yeah, I think we're kind of spoiled in our, I'm kind of spoiled with OpenShift because I get that dashboard out of the box. But even that isn't necessarily the ideal experience for some users. So here we get into the interfaces for these platforms, this probably should say interfaces for platforms. Mostly we focused here so far on APIs, which I would argue should be the ground zero for how even any portal interacts with your platform. We talked about cloud provider APIs and Kubernetes APIs. There is another popular form of those APIs, which is compositions. Crossplane has compositions. There's a few other projects that try to provide a simpler API in front of the Kubernetes APIs. But then we get to GUIs. So I put a picture there of a book, an old old book, and said maybe that's what a CLI is. Some of us like old books. I like old books. But a lot of people probably wouldn't be that interested in a book with that cover. But here for GUIs, we've got interesting covers, interesting things that will help you find what you need right away. And I think it's important here to kind of differentiate. Backstage I think has been very popular because it is geared towards app developers, to making their experience with your platform good. It orients on an application. From that perspective, like Argo, and I've heard this, Argo CD, you saw the thing I showed just a minute ago showing what's been synced and what's not. That GUI is also pretty application-centric. And I think people appreciate that. I've also heard, like GitHub is also when you fall into a repo, it's in some ways a lot like Backstage, bringing together a lot of capabilities in one place for the application developer. But there are of course other GUIs. So Schooner and Headlamp are two projects upstream, Kubernetes dashboard, the OpenShift dashboard. Let's keep going. What is a portal? So I wrote here kind of put a picture of an ideal way to set up a portal, like I've been mentioning, whether it's Yeager, why do I have Yeager up there? Backstage, Schooner, Argo CD on top of APIs, which ultimately are on top of the big, the end of the iceberg, the other part of the iceberg, which is the giant platform underneath. But it is worth mentioning that within Backstage, what is the popularity of Backstage and what are people looking for there? It provides a software catalog. We're going to look at this right now. It provides templates for creating new services and new software. It provides a quick way to find documentation about the projects and it makes it easy to search. So Backstage is actually another application that I'm running on this same platform. And there'll be links at the end, like I said, but Backstage on OpenShift. At this repo with this app, I haven't tech-tonified it quite yet. But otherwise, there's some similar stuff here. You can look at my base and you'll see here, I've got another PGDB. Only have one instance, so I get in trouble sometimes with that one. There's another instrumentation. There's a few other things. Let's show what it looks like once it's deployed. So here is, I'm just going to go to home of Backstage, make that a little bigger. So like I said, the software catalog is kind of your point of orientation here. I've just got two apps registered. But one of them is my SRIG API server. I'll show you how I register that in a second. And then what Backstage does, like I said, it's calling into a bunch of APIs to return information in the context of this app. So if I'm on the team that's building the SRIG API server app, I can pretty quickly jump in and check out how is my CI CD status. So when GitHub was down a half hour ago, this said unknown and had some sort of problem. How was my last push? It's even got some helpful links. So I jump over to here, see how my last pipeline runs went. I can jump into Quay and it's calling the Quay APIs. It says, oh, your last one had a vulnerability. I can see my Kubernetes. I actually have it, the filter a little bit wrong. So it's picking up all the push pipelines. But here's the actual deployment. Actually kind of cool. You've set it up. Okay. Maybe I haven't set mine up quite yet. It'll open the OpenShift dashboard from here. APIs, dependencies, docs. So this is pulling back docs. Docs list of all the docs that I have and then create Bersho this morning in the keynote. But same idea. You've got the templates to create new projects as well. The way this all gets set is also still part of my original application, my Spring API server. So down in there, I've got this backstage catalog info where I kind of say, here's the names and the namespaces that you need to look for across all of my infrastructure. So again, it's still all down in my app repo. My next step here, if I was building this for a platform within a company would be to kind of templatize this whole repo and just reuse it for many, many Spring API servers. I did want to show one other thing about backstage, which now that you've seen what it looks like, the app config file, what you'll notice is that essentially it's a bunch of APIs. So I'm calling GitHub. I'm calling Quay. I'm calling Argo CD. My authentication is not set up so well here. I need to set it up. I'm calling Kubernetes. I'm calling OCM. Here's more Argo CD and Quay. So going back to what we showed in this deck here, which is where we'll start wrapping up. The portal is at the very top and it's calling back into APIs to provide all of that in-context information for your developers. Yes, I would be remiss if I didn't call this out in particular. It is not that easy to build and maintain a backstage portal yourself. If you're adding a plugin, you have to add in TypeScript and rebuild the container. We do have some great plugins. In fact, some of the ones that I was just showing are based on that. I should have called them out. Very shortly, I'm not sure exactly when, the next couple of weeks, I think, we're going to have a preview of this developer hub coming out, which is a productized version of backstage. One that Bersho this morning and it's in the deck too if you want to look is this one, the Janus IDP catalog, which again is similar to what I just showed, a bunch of calls into related things for this application. Okay. So I think we're about at the conclusion here. I wasn't sure if I could get through it all, but I guess we did. So summarizing, we talked about platforms and capabilities and how bringing those capabilities together in a consistent way to serve the needs of app development or ML ops or running third-party software or whatever your use case is, how that really lets us take advantage of cloud, really maximize our return on investment from cloud. We talked about how consistent APIs, consistent GUIs make your platform a lot more usable for your developers. Ideally, you're not just pulling together 10 SaaS APIs and asking your developers to figure out how to integrate that. We shifted into how Kubernetes is a great starting point for building a consistent set of interfaces, a consistent open platform for your platform. And then we wrapped by showing how you need a portal for your platform of some sort, you know, could just be, I guess, a document, but like you need some way for people to interact with it. And backstage could be a great or Red Hat developer hub when it's released, could be a great way to do that. Yeah. So I think I'm just going to open it for questions now. Yeah, if you guys have any questions, feel free to put it in the comments and Josh will take them. We'll give them a couple of minutes, Josh. If you don't see any questions, then we can go ahead and conclude it. But let's give them a couple of minutes. But before that, again, thank you so much for the great presentation, very insightful and, you know, useful. And a brief note to all of you that all the sessions, including the one that Josh just concluded, will be available on our Red Hat developers YouTube channel very soon, all the recording versions and hopefully links to the slides and the GitHub repositories. So in case you guys want to refer back or, you know, see certain points in the demo that you thought you missed, you can very well go back and check them out. All right. I don't see any questions here. So I guess we can call it a day. We can give them 10 minutes back of their time. And again, I would like to thank all of you for attending the Dev Nation day to day and hope you guys enjoyed all the talks. Thank you.