 Welcome to cloud native live where we dive into the code behind cloud native. I'm your host today. I'm Whitney Lee. I'm a developer advocate at Tanzu by Broadcom. Every week we bring new presenters to showcase how to work with cloud native technologies. We build things, we break things, and we'll answer your questions. So today I'm here with more pause here to teach us about how to drive app sec and developer autonomy and the internal developer portal. So this is an official live stream of the CNCF and as such it's subject to the CNCF code of conduct. So please don't do anything that'll be in violation, which is basically don't do anything mean. Be respectful of your fellow folks in the chat. Be respectful of presenters and be respectful of your host, please. Folks who are joining us live, I love how this is a global community. Please do say hello in the chat and say where you're here from. I love it. And with that, oh, here's another thing I want to tell you. Today, if you have questions during the presentation, please do ask them while we're going. We're going to make this feel more like a discussion if you're here for it instead of a one-sided presentation. And with all of that information, finally, without further ado, I'm here to introduce more paths to kick it off today's presentation. Welcome more. Hi, Whitney. Thank you for that wonderful introduction. Thanks for being here. Yeah. So hello, everyone. Today we'll be talking about enhancing application security with an internal developer portal. The session should be around 30 minutes give or take. A lot of it will be a live coding session inside an actual developer portal. Let's get started. So first of all, a bit about myself. My name is Moore. I'm a lead architect at Port. I come from a software engineering background and we feel our experience as a DevOps engineer. In the past year, I've done several sessions for the CMCF, both live and on-demand ones, such as introduction to developer experience and abstracting Kubernetes with developer portals. I really love video games, bouldering and burgers. If you ever find yourself in the Tel Aviv area and you need a recommendation, feel free to hit me up. You can see my socials right here. And with that, let's see what we'll be talking about today. So we already went about who am I? So let's see what we'll be talking about. So we're going to cover the core pillars of a developer portal. We're going to talk about why developers love application security tools, why developers are sometimes overwhelmed by those tools, how developer pools enhance application security. We're going to have our live coding session inside an actual developer portal and see how those two worlds combine. And then we'll have a dedicated time for questions. But of course, as Whitney mentioned, if you have any questions during the session, feel free to type them out and we'll go. So first of all, the pillars of a developer portal. So we believe that a developer portal contains four core pillars. The first is the software catalog. The software catalog is where you bring all of your information from across all of your infrastructure into one place to leverage that additional context of having everything in one place and being able to expose it in convenient and tailored views that make sense for your developers. Because at the end of the day, the consumers or the customers of your developer portal are your developers. And so they need to have all the information that they require, but they also need to have it exposed in a way that makes sense. So that means bringing information from Kubernetes and Argo CD and your cloud provider and so on into one place, making sure that those views, those visualizations make sense. The second pillar is the solve service. So in the developer portal, we want to expose solve service actions to our developers, want to drive developer efficiency, and we want to drive developer autonomy. And we do that by exposing to them actions that today they usually have to resort to contacting their platform engineer, their DevX engineer, the DevOps engineer. For those very mundane tasks, oh, I need a new microservice, I need to take care of vulnerability. For example, we're talking about application security and so on. So all of these actions need to be exposed through the developer portal to make life easier, both for the developers who will have more autonomy, but both for the platform engineers and DevOps engineers who will have less mundane tickets and can actually focus on improving infrastructure for the developers. Then we have workflow automation, which ties very well with both solve service and software catalog. So by filling the catalog with a lot of high quality information and exposing that information through an API, we can leverage that for our automations. So for our CI CD, for our serverless functions and so on, and basically take advantage of the information inside the software catalog as part of our pipelines, as part of our scripts, as part of our configs and so on. And then we have scorecards. Scorecards are a way for organizations to measure how they stand up against their standards. So are they following the best practices? Are they using supported languages? Do their services have some number of vulnerabilities and nothing higher than that? Do they have critical vulnerabilities that need to be taken care of immediately and so on? So scorecards make it possible to track all these different metrics and also define for your organization what actual metrics you care about and measure them and continue to improve your engineering organization. And of course, all of this is made possible through a very strong role-based access control layer that makes sure that developers see only the information that they care about and only information that they should see. So for example, no sensitive secrets, no sensitive credentials and so on on the one hand, but then giving them the option to trigger the correct actions on the other hand. And of course, like we said, with all that high quality information flowing in real time from all of the systems, it makes a lot of sense to expose it with R&D insights and reports, dashboards, and visualizations, which we're going to see as part of the demo today. I have a question. I have a question. I haven't seen that term scorecard before. Is that always used in a security context or can it also be in like a cost optimization or performance context? Yeah. So perfect question. Scorecards are fully customizable and the idea is for you as an organization to track what you care about. So if you care about cost, for example, you can configure a scorecard for cost. If you want to focus on improving your security standing, you can create a scorecard for production readiness or security and track how many vulnerabilities you have. And for example, set some sort of rule that we only want services to have up to X critical vulnerabilities. And then the scorecards will enable you to see exactly which services are currently adhering that standard and which don't and might need dedicated work to take care of that. Is that a term that's like used across the industry or is it unique to your internal developer platform that you're demoing today? So that is a pretty common term in the world of developer portals. I do know that, for example, backstage, which is a CNCF developer platform also has a plugin which is supposed to expose something that is very similar to scorecard. I believe that plugin is called sound check, but I'm not 100% sure. And again, since backstage, for example, is open source and backed by the CNCF, I'm 100% sure that there are other plugins specifically for scorecards for backstage. But it is a pretty common term used by all developer portal tools at this point. Cool. Thank you. Okay. So we went over to the core pillars. Let's start talking a bit more about application security. So why do developers love application security tools? As you know, with the world of open source projects and very vibrant frameworks such as Python and Node.js and Go, we have a lot of the new packages coming out every day. We had a lot of packages getting updated all the time. And that means that these packages and these package versions have a lot of new vulnerabilities, which no one's at fault at for that. Obviously attackers will continue to detect new vulnerabilities and those need to get patched. But this means that keeping up with these vulnerabilities is an ongoing battle. So application security tools make it very easy to keep track of all of those new vulnerabilities and also take care of them. And again, this is what's great about application security tools. They help you understand what is the required fix, which is not always trivial because, for example, you might have some pure dependency or some parent dependency that needs to get patched. And it's not a direct dependency for your project. But having a tool give you that explanation and also show you the fix and even open a pull request for you with the fix makes it a lot easier. And it takes away from that cognitive load of keeping track and also taking care of the fix. And then having an automated scanning process really streamlines work and prevents mistakes. So all of these automated scanning provided by different application security tools help you make sure that whenever you're deploying to staging, to production, to anything that meets your customers, you can always have that automated check and you're always up to date on what vulnerabilities you have in your environment and take care of those. Now, all of this is great, but application security tools are unfortunately not perfect and they can be overwhelming. So why is that? So first of all, as we mentioned, the number of vulnerabilities is very, very high, even for simple projects. If you start a new blank Node.js project right now, just add a few very common dependencies to it. For example, the top packages in NPM and you wait two weeks, three weeks. I assure you that when you come back to it, even if you didn't change anything, you will have new vulnerabilities. They might not be critical, but they will be there. That means that that is something that needs to be taken care of. Of course, if the security risk is real and if it is something that is of high severity, then you will also need to take care of it very quickly. So that is one issue. And when we add to that the fact that application security tools usually don't actually know which vulnerabilities actually matter for you. So an application security tool usually sees, okay, this is a Git repository. It has this package JSON or requirements TXT file. And these are the packages that this repository and this microservice uses. And it sees all of the different vulnerabilities, but it's lacking the additional context of, hey, is this a microservice that's deployed in production? Is this a microservice that's actually mission critical? Is it meeting customers? Because for all we know, that service might be some internal documentation, which doesn't actually pose a security risk. So that is one place that application security tools don't yet have that context and we'll see how it will propose help with that. And another thing is that for companies just starting their application security journey, getting to a steady state seems like a very long and daunting process. So even for a company that's three or four months old, just have like one or two microservices up and running, the moment they start using some application security tool, and it doesn't matter which one, they will immediately start seeing tens or hundreds of vulnerabilities, depending on the packages that they use. And that means that they are immediately, they immediately have some work to do. And that might seem like an uphill battle that's very hard to fight. It's very hard to understand, okay, what should I focus on first? And that is something that we hope to solve by combining developer portal with application security. So let's talk about how developer portals actually help us with all of those things. So the virtual portals, as we mentioned with the pillars and with the software catalog, they are meant to be your single pane of glass for your complete infrastructure. So that means they hold the data from all the different points from your get provider and from your Kubernetes, your cloud provider, your application security tool, and all of that in one place. Now what that gives us is it places the virtual portals in the best place to store both software development lifecycle information and security metadata and actually make the connection between the two. So if you remember, in the previous slide, we talked about how application security tools lack the context of is this service actually experiencing a critical vulnerability that I need to take care of right now. And the application security tool doesn't have that information. But when we combine it with the additional information that we have inside the developer portal, all of a sudden we have an answer to that question and we'll see that in the live demo. And continuing on that, developer portals have additional context with a single tool on its own does not. So is the service running production? Is it mission critical? Is it customer facing? And so on is it deployed right now in a Kubernetes that's accessible from the internet or not? How viable is this attack vector and so on? All of this is information that we can gain by combining a developer portal with an application security tool. And following up on the additional pillars, when we talk about scorecards and self-service actions, developer portals unlock a deeper layer of visibility and functionality that is enabled under one convenient rooftop. Because we have all of that additional context, because we can create that single view that's telling us, okay, we want to adhere to these standards in the security scorecard. And so let's do some work in the coming month or quarter to take care of that. And once we have all that information in place, we can also leverage it for self-service actions. So this is, again, something that we'll see pretty soon inside the demo. And now it's actually time to start that demo. So let's go over what we're going to actually do. So first of all, we're going to start with a basic data model from our Git provider. Then we're going to extend it with information from application security tool. Then we're going to create new dashboards, both for developers and engineering managers. And finally, we're going to show how even when using self-service actions and providing developer autonomy and independence, we still manage to create guardrails to make sure that only secure services can be deployed. Okay. So what we have here is my developer portal. At the moment, it's pretty simple. It doesn't have that much information. If I go to the catalog, I can all the services they have. Will you make it bigger, please? Yeah, sure. Thank you. Great. Yeah. So in here, you can see all the different services that I have, and this is just information taken from a Git provider. So as I mentioned, we can already see here some additional information that the application security tool isn't able to provide us with. So for example, is it customer-facing, mission-critical? Is it some internal service? And so on. And so what I want to do now is I actually want to extend my developer portal and bring some more information in. So as you can see at the moment, we only have this service box, which we at Port call a blueprint, which is just a customizable data model for you to choose which assets you want to bring into your developer portal and what information you want to track for those. And so what I'm going to do now is I'm going to add a new data source. And in this instance, what I'm going to do is I'm going to add an integration with Sneak. So Sneak will be our application security tool of choice for today. And you can see here that the portal already gives me the installation command required. And I will mention that this integration is enabled by the Ocean Framework, which is an open source framework developed by Port. Whitney will have links in the chat for a repository link to Ocean. It will also have, she will also share a link to of the resources used inside this demo so you can replicate it yourself. And so what I'm going to do now is I'm actually going to go into my terminal and I'm going to use that installation command. So give me just a second because I need to paste that in. There we go. And so what's going to happen is it's actually going to create a new deployment in my Kubernetes with that integration. We can see that it's already running. So if we go back to our portal, we can already see that it picked it up and we can see the new integration here. And what you will notice when we go to the data model, but it has been extended a bit. So now we have more information brought to us directly from Sneak as part of the integration. So we have here the Sneak organization. We have Sneak vulnerabilities, which is something we'd like to focus on today since we're talking about application security. And we have Sneak projects, which are basically different points inside our repositories, which we'd like to take care of. So for example, your package JSON or your Docker file that might have an outdated base image. And we have a Sneak target and a Sneak target perfects a Git library. So let's just go for a second to the catalog show that. So you can see here of the different Sneak targets, which are the Sneak repositories that I have in my Git organization. And you can also see that we already have all of the vulnerability information coming in from Sneak. So what I want to do now is I want to actually make that connection. Remember that we talked about using the portal to extend and bring additional context, which is enabled by multiple sources. So do is I'm actually going to create a relation between my Sneak target and service. And remember a service is just a Git repository, which is why they perfectly match. So you can see that we've made this connection. And now we just need to let the integration know, hey, we made this additional mapping. Let's make an update. So it actually manages to tie that information together. So in order to do that, we'll just go to the Sneak integration. We can see here the config it's available directly from the portal, which is very convenient for these kinds of edits. And what I'm going to do is I'm just going to add one small line. So if you recall just a minute ago, we added this service relation to the Sneak target. And what we're going to do is we're going to take the information from Sneak. We're going to make a slight transformation on it to extract the repository name and use that as our mapping. And once I click on ReSync, what's happening in the background is that remember that deployment for the Sneak integration that I made, it just got a notification that it needs to re-sync the data according to the new mapping. And so now when we go to the catalog and we go to the targets, you will see here in just a second once it's that the Sneak target now has a service mapped to it. So let's give it just a second until it runs. In the meantime, there's one additional thing that I want to do. So Sneak and other application security tools are excellent at offering us an opening for us pull requests to fix vulnerabilities that they detect. And I'd like to bring that information into the portal because it makes it very simple for a developer to just go into the portal and see, hey, these are all the pull requests and related to security. And so that really makes it easy to understand, okay, what should I take care of next? And so for that, what I'm going to do is I'm going to add another blueprint, which is simply for GitHub pull requests. So excuse me for not using the UI editor. We just have the pull requests ready ahead of time. And this information is also, first of all, it's available in the URL that we shared, and it's also available in our documentation. So this is just a pull request blueprint. It includes some information about GitHub pull requests. So who's assigned to it, who's a reviewer, what's its status, and so on. And so in order to bring those pull requests in, we're going to make just another small mapping update. So what you will notice is that I added here another block that's just telling the integration with GitHub to bring pull request information and just send it to the pull request blueprint. Now I'm going to save and re-sync that. In the meantime, let's go back to our sneak targets. Yeah, perfect. So you can see here that the product service is now tied to the actual product repository. And that also allows us to view all of the information on the graph. So for example, we can see, okay, this service has quite a few vulnerabilities. So this might be something that we want to focus on to take care of those and start lowering that number. So I can only see that some pull request information is flowing from GitHub. And that gives us the option to create a very convenient view for our developers. So if I go to the homepage, I already made a few dashboards ahead of time. And some of those, such as this one, do you have a question? Yeah, in the other view that you were just in, will you kind of recap what all those different abstractions are and what they mean and how they relate to each other? So like a blueprint will help you make any kind of, it's just a code template basically, right, to help you make something. What's a target? Yeah. So a blueprint is sort of like a schema in a table or a class in your language. So it basically allows you to specify what data do you want to see for a given asset. Now when we talk about, yeah. And there are lots of different possible assets that when you do a blueprint, there's lots of different things you can make. Okay, yes, got it. Yeah, yeah, exactly. So for example, this is for the application security use case, but for example, if I bring over information from Kubernetes, for example, then I will probably have a blueprint for a cluster and for deployments. And maybe for services and namespaces and so on. And the idea that it's really customizable so you can choose the level that you dive into Kubernetes. Because for example, we want the developer portal to be for developers. And developers usually don't care about every single pod. Yeah. Usually care about their namespace, they care about their deployments and their health status and so on. But they don't want to go straight into the nitty-gritty. That's usually safe for the DevOps. Cool. And then what does a target represent? Yeah, so a target is SNCC's naming for repository, basically. Oh, so it's a SNCC-specific thing. Yeah, so it's a SNCC-specific thing. Got it. But what we did is we, yeah, and we tied that to the service blueprint because again, a service is actually a Git repository brought in from our GitHub. So those perfectly match and by combining them, we can perfectly see for a given repository all of its information, including its security information. Perfect. I understand now. Thank you. No worries. So, Center Builder, I'm going to make one final extension to our model. And then I'll go back to the homepage to show you what I want to show about pull requests. So what I want to do is I want to add some information directly to the service to make it easier and accessible. So I'm going to add critical vulnerabilities. And basically what I'm going to do is I'm going to take information from the SNCC target, which I made a connection to. And I'm just going to take the open critical vulnerabilities property. And in just a second, we'll be able to see the result of that on an actual service. So for a given repository, I will be able to see exactly the number of critical vulnerabilities. And I want to do the same thing for high vulnerabilities. And of course, everything that you see here, I'm doing it through DUI, but you can totally do it through an API. It's very common for a developer portal to have complete API access to make it very easy, both for users and their automations and for integrations to interact with the portal in a dynamic way to make sure that it's both configured very easily and also modified and updated very easily. So while this is updating information to the service, let's go back to the home page and take a look at our open security PRs view. So basically what this does, it just shows us all of the pull requests, but it's specifically filtered to pull requests open by SNCC. So these are all the pull requests related to the vulnerabilities and updates that we can or should or must do, depending on the different severity that those vulnerabilities have. And in addition, since we added that aggregation to bring the information of the number of vulnerabilities for every service, then we can also create a view for mission critical services with vulnerabilities. So for example, we can see these are mission critical services that I have, who have quite a few critical vulnerabilities. So it is a very good idea to start taking care of those right now. Now, another thing I want to show you is how we can actually leverage this information to create some more actual visual views. So for example, let's go to our security manager dashboard, which is probably something that your security people or your DevOps want to take a look at. And let's add here a pie chart showing us vulnerabilities by severity. And again, this is all leveraging information that we've brought into the portal. So the information already existed somewhere. In this case, it existed in SNCC. And we just brought it into the portal and we're exposing it to our users in a convenient and easy to access way. And so once I go ahead and save that, we can see that we have a pie chart. And let's just say that we want to create a different view for vulnerabilities by language. So it's the same drill. Just go ahead and this time we filter or break down by the language. Of course, the number will be the same, but the idea is that the data is different. And of course, as with every good developer portal, we can customize this and make this view a bit easier on the eyes, changing things around a bit to make the visualizations make more sense to those that are looking at them. Now we're almost at the end. What I want to show you is how we leverage scorecards and self-services to enhance the developer experience and make sure that we have some guardrails in place for security data. So in here, I have my production readiness scorecard. And right now it has one rule for every tier. So for bronze, it must have a read me defined for silver. It must use a support language for my organization and so on. What are those? Determines by the organization or are they part of the platform? So these are completely customizable, as we'll see right now, because as you can see, everything here is just a JSON definition. It's following JSON schema. So you can configure as many rules in whatever tiers that you want and whatever tiers that make sense for you. And so what I want to do now is I actually want to add some security information here since we brought all of that data into the portal. So I'm going to add two rules. The first is for no critical vulnerabilities. And this is bronze tier because again, a critical vulnerability is something that we have to take care of right away. And the rule is very simple. We want to make sure that we have less than one critical vulnerabilities. And we added another rule for high vulnerabilities. This one is at a silver tier because a high level vulnerability is still something we want to take care of quickly, but it's not super critical. It's just something we want to be minded of. And so it's the same rule, but a different tier. Once I go ahead and save that, we can go ahead and take a look at one of the services. And so for example, let's choose this service, which has a few both critical and high vulnerabilities. And we can see here that it does not pass those checks. And because we have all of that information provided by the developer portal and available as a scorecard, we can also leverage that in our sole service actions. So I have here an action for deploy service, which I can use to just deploy a service to a given environment. And again, this form might look the same for your company and or it might look completely different. And depending it might need more inputs. It might need less inputs and so on. So this is customizable. This is something that should be tailored to the experience that you want to expose to your developers. And so in this instance, I want to show two examples to examples. I want to show you what happens when we deploy a service that does have critical vulnerabilities and what happens when we deploy a service that doesn't have critical vulnerabilities. So let's assume that we're deploying to production and we want to deploy the product service. Let's go ahead and click on execute and the developer portal will trigger the action for us. And while we're waiting for that to run, I want to make the same thing again, but this time I want to choose the notification service. And so what's happening in the background is the developer portal is actually going ahead and triggering a GitHub workflow for us. And I'm going to show the workflow in just a minute, but I want to show you the result that we're actually getting. So we can only see that deploying the product service failed. And let's try and understand why. So we can see here a log of the action that ran. So we can see, okay, deploying service, product service, checking production readiness scorecard. Now, if you recall, we updated that scorecard just a minute or two ago and added those security or vulnerability rules. So we can see that it is not production ready because at this service, this product service is at a basic tier, which means it doesn't even pass bronze because it does have some critical vulnerabilities. Let's just give it a second to load. So you can see it does not pass the critical vulnerabilities check and its production readiness is at basic. So we don't want to deploy a service that's not production ready to production, which is why we failed that deployment. And if we look at the notification service, it did succeed because it did pass the check. So it's deployed and everything's fine. We can also go from the portal directly to the actual workflow that was triggered. We can see it's just the deployed workflow. We have some login here. We are getting the scorecard directly from the portal. Will you make that bigger, please? Yeah, yeah, sure. Sorry. So we can see that we're getting the scorecard information from the developer portal. And then we're just taking a look. We can see the score is bronze. So we're good to go and deploy in it. And we're just updating that we made the deployment. That's perfect. And that helps you understand how you can leverage your developer portal and a combination with your application security tool, how you can bring that information and allow your developers to deploy in a safe manner because you put in the guardrails in the deployment workflow and you have their back, making sure they won't deploy anything that has some critical vulnerabilities to production. Okay. So that was the live demo section. Thank you very much. If you have any questions. I have some, I have, I always have questions. I have some questions. So if you're totally starting, like one thing you said at the beginning is it's really hard to start your security journey from scratch. It's like overwhelming to get there. So what, if you're just starting, what would you, with this portal, like what would you recommend doing for your first actions? Or like, what types of application security data should you include in the portal? Yeah. So I fully believe that you should start with taking a look at the services that are most mission critical for you. They are the ones that are meeting your customers. They are the ones that probably see the most traffic and understand, okay, do these have any critical or high vulnerabilities and start tackling those first? And I would also probably extend that information and say, okay, do these, are these services actually open to an, to external network access? Do they have to be? Maybe that's something we need to close down. Maybe I need to tighten up a bit and so on. That's, and then also like, and as far as dimensions of security, do you think like looking for vulnerabilities is a great place to start to? Yeah. So I would say it's probably a good place to start. It's definitely something that gets overlooked, in my opinion, and it's usually the critical fixes are pretty easy to take care of and they really give you peace of mind because you know, okay, this attack vector, which I never really thought about, can be closed down pretty easily. It's going to give me some peace of mind and I can tackle those and start taking a look at some other things. Maybe I want to add some policies to my Kubernetes and add some guardrails using role-based access control and so on, start closing down those loop holes or those back doors, which might catch us off guard. Which persona do you see doing that, the developer or the DevOps person? So it's definitely a joined effort. When we're talking about vulnerabilities, this is something that the developers need to be minded of and they need to take care of. Basically, at the end of the day, they are the ones working with the code. They are the ones that understand the code. They understand the implication of, okay, this library went from version one to version two, and these are the breaking changes that I need to take care of in order for the upgrade to pass successfully. So that is the developer part. But of course, DevOps also has a role because DevOps needs to understand, okay, is the permissions given to this service too broad? Maybe I can limit that. Maybe I can make sure that the different service accounts that I have in my Kubernetes only have access to the resources that they actually need from the cluster and so on. So it's a joined effort. Are those two things, the limiting security accounts are making sure that something doesn't have network access when it shouldn't? Are those two things discoverable from within this developer platform? Yeah, so with the correct integration, so for example, let me just head back. So for example, if we go ahead and say, I want to bring information from a cloud provider, so I can bring information from any major cloud provider and I can actually bring that piece of information. So I can say, okay, I want to bring all of my load balancers and I want to understand, and I want to actually bring from the cloud provider into the portal dean piece of information. Is this load balancer internal or not? And if it's not internal, maybe it should be. Maybe it should not have external access and so on. Oh, that was actually a question I had from the very... When you first open up the portal, there are lots of lines. I actually asked you to zoom in and there was a column for tiers. And I was wondering, are those tiers... So I think, yeah, here, are those automatically populated by the software or is that something that you're configuring when you introduce the services? So this is something that you introduce, you fill in when you introduce the services. Of course, it can also be done directly through Github, for example, so you can just have a file committed to the repository saying what is the actual tier of the service. And that is a pretty static field. So you basically fill it out once. Every company already has an understanding of what is the actual tier of a service. Sometimes they just need to bring it in and type it somewhere and keep track of it. So a repository is a perfect place and that information just gets brought into the portal and it's available and it's given us that additional context which might be hard to keep track of in our head or in some spreadsheet. Yeah, absolutely. One thing I'm interested in is the developer experience in the self-service aspect of it. What are some of the self-service type actions and which ones do you think are especially cool? Yeah, so first of all, I have a few small examples here and I will tell you right away that the most common one and most popular one that we see is scaffolding a new service. This is a pretty mundane task. You need a new microservice. You want to develop some new feature that requires some additional infrastructure and needs to be deployed on its own. And so what you will usually do in a world without a developer portal is as a developer, you will open a ticket or talk to your DevOps and tell them, hey, I need a new repository. It needs to be deployed with these resources. It needs this database and so on. And so this is a pretty common ask which is why it makes perfect sense to expose it as a self-service action because you know how a service usually looks in your organization. You have some sort of standard. You have some sort of template or maybe you don't have a template but you want to leverage something that's open source, something for example, such as a Kuhi Cutter which is an open source templating project. And so you expose that as an action and then all of a sudden your developers are free to just go into the portal, click on scaffold, they give the service name, they get a repository, they're good to go, they can start working on it as part of the development process and once they're ready, they can circle back to DevOps, start the conversation of, okay, how do we deploy this or how do we provision the infrastructure to deploy this and then they are able to simply deploy on their own independently. Cool. What are a couple other ones real quick that like self-service type things that developers can do? Yeah, so some other common things that we see is things such as force merge in those rare cases where you need it to push a hot fix right away, for example, or reverting a version in case we had some bug that somehow got deployed and it's breaking something we want to roll back real quick. And sometimes even things that are more DevOps-oriented but we just want to use the developers a bit more freedom. So things such as changing the replica count of a Kubernetes deployment, for example. So these are all different examples. Cool. And then I think I'm just asking so many questions. I'm going to dig in a little more and then I'll set you free. I'm curious about scaffolding. I'm curious that a couple things. One is like from the DevOps side what kind of guardrails are you putting in in the scaffolding example in terms of like the self-service aspect? Yeah. So for guardrails, I would definitely say that a big part of the scaffolding issue is that if you would let developers just do it on their own directly in the Git provider and they might mess it up in some ways. They might use a name for a repository that doesn't follow your standards. They might specify some fields that you usually don't use or you have some specific convention that you use for those. So a developer portal and a static form that can, for example, force you to enter those fields or it can give you something such as a list to choose from to start whittling down those mistakes and make sure that you're actually adhering to your standards makes it very easy. It also really speeds up the process because instead of going back and forth about, hey, under DevOps, I need this and this information from you and you start filling it out in some email then you have the form right here and it already contains all the guardrails that you might require. So it really saves on the back and forth and the questions and the errors during triggering the action. Are there any scaffolding guardrails that you especially recommend an organization do if they're just getting started? Are there any best practices? I would definitely say choosing a convention for your naming. That is something that if it goes unchecked, you can suddenly have all sorts of microservices with different names and you can understand which one does what and you also don't understand their exact goal. So that is one. I also had another one in my mind and just slipped away. Oh, I know that feeling. Yeah. Oh, I got it. So I would definitely say either embrace and adopt a well-maintained template for the languages that you're using. So for example, you're using a lot of Python and you're using Flask as your API. So for example, Iver take a template for a Python project with Flask and use it as is or take it and start adapting it a bit to your standards and then start using that and continue developing it so that you have an up-to-date template that matches what you expect the service to contain in your organization. Cool. Do you have any other final words before we wrap up the stream? No. So thank you very much and thank you Whitney. If you have any other questions, feel free to send me an email and also if you want to see how a fully-fledged developer portal looks, I highly suggest checking demo.getport.io and thank you so much for joining us. Cool. Thank you so much. More paths. You're teaching. Thank you for sharing your time and your expertise with us and for teaching us about how to drive APSEC Developer Autonomy in the internal developer portal. Thanks also everyone in the chat saying where you're from. I see Turkey, UK, Austria, Netherlands, Chicago. It's so cool that you all can't even hung out with us today so thank you for that. Here at Cloud Native Live, we bring you the latest Cloud Native Code on Tuesdays and Wednesdays so we're going to be doing this again tomorrow and thanks to those who watched the recording too. I'll see you all tomorrow. Bye.