Build Their Platform, Not Yours: Empowering Developers

body and thanks a lot for joining my talk which is about building internal developer platforms. Thank you. Yeah, hello again. Thanks a lot for joining my talk. It is about I said building internal developer platforms and how to build them so that they're actually built for developers instead of for the people building the platforms or what we as platform engineers might think is building. Um but before we jump into that topic let me quickly introduce myself. Um my name is Kati. I'm a platform engineer or actually by now developer advocate Dino trace and I'm also contributing a bit to the cloud native lens meetup and to cloud native Austria. Um but before I became a platform or devops engineer, I actually went for a completely different route. I started mobile computing and then I thought like hey I know how to write apps now but I would like to write how to find out how to write nicely and what I did is I started human centered computing and I did something where most of my colleagues would probably run away. We were sticking not around, writing them, clustering all day. And actually in the beginning it was pretty annoying for me. But what I found out that one is that you can get so much benefit with just talking to people really finding out their needs. And sometimes we had applications where we thought, yeah, it's really obvious that we going to implement it that way, right? But when actually talking to the end users, we found out, hey, that's what not what they need. If we implement this feature like that instead, it's much much better. And yeah, after that I became a mobile developer. And a classical happy day of mine would look like that. I would do some feature development, architecture, architecture discussions, maybe some UI discussions, um some performance improvements, security fixes, whatever. It was all so much fun to me. But those not so happy days were filled with CICD basically. Um you know where you have those mysterious build failures where a colleague just tells you, "Yeah, that's happening from time to time. just re-trigger it, right? It's so frustrating because you don't know what is going on. Um, slow pipelines, waiting 10 or 15 minutes until something tells you, hey, you have a limp problem, and then waiting the same time again for maybe a test issue or something like that. It's just wasting so much time. All these manual processes where, yeah, of course, if you wanted to publish an app to production, we had documentation available, but hey, this documentation was threaded into maybe a GitHub repository. I think it was confidence back then. for us it was somehow all without me that I don't know how this is works but we managed to do that um I always had to ask a colleague for that and worst of all the works on my machine syndrome where something worked on my machine didn't work on my colleague's machine the other way around and basically I decided or I thought I decided yeah I never want to work in that I never want to work in CI/CD in DevOps or anything like that I just don't want to touch it because it's so annoying well then I actually made a realization and what I realized is that DevOps or platform engineering is not about manual repetitive tasks. It's not about waiting for pipelines. It is all about empowering developers because with platform engineering we can build platforms that really help developers in their day-to-day lives to not face the frustration that I faced over there but we can really make their experience and yeah for me also their happy hours that they have work much much more. So today we want to take a look on very basically how to build such platforms and also how to abstract away components for the user. But before we do that what is platform engineering actually and to understand that I want you to travel back in time with me for a bit. But we're not going to travel to dinosaur era but we are going to travel to the time before was actually and a little disclaimer here. I'm pretty sure that many of you know much much more about HR than I do. Um I just highlighted a few things that are important for this presentation and yeah with that let me introduce you to Alex. Alex is at that time working in a development team and what they have done is they have implemented a feature and they want to publish it to production just like my mobile apps. Well, but in the time before our agile they cannot do that directly. They cannot just go ahead and say hey I want to push that to production. What they do is they are building their feature and actually they have to pass it on to the testing team. As soon as the testing team finds time to take a look at it um they will review it. They will probably find some bugs right we also have to engineers so we know the process hand it back with some feedback. Alex team will implement the fixes if necessary pass it on to the testing team again get it back and repeat until everything is fine. Next step, we need to pass it over to operations who might then publish it to productions. In really, really large companies, there might also be a build team in between. And I'm pretty happy that I didn't have to work in that time because um if you take a look at it, there are so many processes involved and it's just taking so long until to get something into production, until to get some get some feedback from customers and do fixes and stuff like that. So people were annoyed and they implemented agile which is pretty cool because what happened at that time is people said hey why don't we have external testers why don't we move the tester into the development team and test our features right away also test-driven development and stuff like that and actually say corporations you build it you run it is really big nowadays right so you own your application really from writing the first line of code until running it production and this is pretty cool because by now at least In theory, um, Alex team can implement the feature, publish it to production and be happy. Well, most companies still have an operations team for provisioning infrastructure, actually making sure the production is running nicely and so on. Um, but at least the workflow has improved by a lot. But let's take a look at this at a bigger scale. Let's say we have not only one team living by the principle, you build it, you run it, but we have four teams living by the principle. You build it, you run it. And every team is responsible for writing their code, for testing it, for um linting it, making sure format is nicely, for deploying it, for observing it in production, for fixing bugs and so on. And you might reckon all of those teams, maybe some of them work together, but there are going to be many different solutions for the same problems, right? At least for me, I have had that situation talking to colleagues and then finding out, hey, we're actually working on the same thing. We're doing it completely different. Why don't we team up? Why don't we make something really nice together and yeah in addition to this we still have operations who is working with all teams probably but not that much important in that scope but why don't we make all these repetitive tasks like let's take something really simple like depend not that simple but that seems really simple like dependency updates so probably there are three solutions in that scenario already on how to do dependency updates and they might differ a bit if somebody needs to help out or fix something in another team it could be a problem right or at least it could be a bit harder so why don't we take one platform ah sorry why don't we move to platform engineering and there take one platform the internal developer platform or in short IDP and take it into the middle of those teams and abstract away things like dependency updates as just mentioned or deployments or how to build pipelines and stuff like that and this is pretty cool because like that we can also get rid of the operations team again And actually they are probably the ones who are now platform engineers and building our platform. And by that the platform engineers can already provide lots of solutions to the platform that can be consumed by teams but at the same time those teams can contribute to the platforms if you're doing it in an inner source manner. So if a team comes up with something where the other teams might benefit from they can simply contribute it back and everybody will um will have the benefit of that. Well, but still you might ask um we are adding a lot of complexity in the middle of all teams, right? And also kind of a single point of failure. So why are we taking that risk? Why do we want to add a platform like that? Well, first of all, it's much less cognitive load as said if a team is living by the principle you build it, you're running, they have to take care of a lot of things from writing code, testing until production, observing, doing hot fixes and so on. And while this is of course possible for software engineers to know and there are some pretty clever people that are really good at all of that, it is putting a lot of cognitive load on people and at the same time many developers probably like I did want to focus on writing code because that's usually what life most and therefore the best. So if we can take away a bit of this complexity that developers are facing and abstract it behind the platform, we can make their day-to-day life much much easier and there is much less that they need to take take care of at least in standard situations. Next thing autonomy right now in many companies if you want to get a database something as simple as a database of course there are bigger things like when discussers whatever as well but you probably need to go to operations wait until the database is provisioned get your credentials right and then you can work with it and if it's a really fast process it might take one or two days if you have bad luck you might have to wait until the next sprint until the story is plant that you created and so on and with an internal development platform you could simply do this in a self-service manner. You can provision your database yourself um with a blueprint created by operations platform engineers, however you want to call it, and you will be much much faster and autonomous in your working, which is always nice in my opinion. Next point, you will have more unified solutions. I already talked about the problem having four teams all solving the same problems. Um with a platform in the middle, those solutions are most probably going to align at least most of them. If a team has very special needs, you need to adjust to that of course. But it's much much easier to unify the solutions and also to work across teams if you build a platform like that. Next, standardized workflows. Actually, if there's a new development team or if there's somebody like me trying to push an app to production, it's sometimes pretty hard to do that with platform. You can really create standards that people can follow to do certain tasks like provisioning a database, pushing something to production, whatever. And you need to be careful about that one. You don't want to cage people in with your platform. But you can create really really nice paths that people can follow and that will make their lives a lot easier. And last but not least, you can offer a nice service for your company. Um for me it is when I join new companies, it was always like that. Hey, I want to build a new service, a new application. How do you do that? Yeah, maybe you can take this application as blueprint. It's the latest one we created. But there's some documentation over there as well. that something is documented in the read me and something is there and maybe ask this colleague because they know best and it was always so hard for me to find out hey who is actually owning something who has created this one and where do you find documentation that is up to date and with a service catalog like that can be offered by a platform you can simply add all components into one catalog you can find out who's owning it and so on and it will be much much easier for new colleagues to do on boarding but at the same time if you're experienced developer and you touch a service you never touched, you will have a nice starting point that you can take a look at. Okay, so I think we can summarize all of that um with a sentence from the thoughtworks podcast really nicely. It says that platforms are a means of centralizing expertise whilst decentralizing innovation to the customer or user. Um our customer or user in this case are the developers in our company. And so what we are doing is we're actually decentralizing innovation to them. We we're allowing them to focus on innovation and on feature development also fixes much much more while we are standardizing all the expertise around CI/CD and so on behind the platform so that people can consume it in a self-service manner. So basically a self-service for developers but when building such a self-service platform for developers we need to be aware of that now we are offering a user interface because also in my platform engineering team that I worked in we were basically before we were the operations team and suddenly we were building a platform something we were not used to because before we would get a lot of tickets and actually we work on them solve them of course create some kind of such service manner but we never built a big product like that that actually offer the real user interface and no matter if that's a command line interface if it's an HTTP API if it's G repository um a developer portal like backstage something that you have written on your own or something completely different a combination of all those it doesn't matter everything you provide to the user the user is interacting with is a user interface and I'm sorry in my opinion this applies to command line interfaces as well so really make sure that you're aware that by building a platform you're building a user interface. And if you get this part right, of course there's many, many more things to get right. But if you get this right, it might be very nice for developers to actually use your platform. But if you ignore their needs and ignore that you are building a self-service platform for them, you might end up like this poor guided or this poor folks on Reddit who said, "Hey, we've spent months building this platform. Our developers hate me and hate it. Please help me understand why." And I've read a bit through the comments. There's also been a post like that in another thread. And what I believe they did is they sat in their room and they said, "Hey, we going to build a platform. It's going to be really cool. It's going to be have this feature, this feature, this feature, and so on." But they never actually talked to the developers that in the end should actually use this platform. And so what they did is they built the platform in isolation. When they were done, they kind of threw it over the wall and said, "Hey, here developers, we've built something awesome for you. Please use it." And the developers were like, "Yeah, but that's not solving the problems we have." And by that adoption was very low. And yeah, so how can we avoid this situation? How can we actually build a platform that people like to use? Well, first of all, you need to find your very own needs. As mentioned already, it is really important to understand your company to understand the programs developers have in your company. And of course this is different for every company because otherwise we would have one standardized platform that would work for all of them. And there are also some platforms like that which work really nicely for startups for small companies that don't have that much processes yet. But if you're a big company, this might not work. And you really need to before implementing anything take a look on what do the developers in my a company actually need and how can I make their lives easier. Next thing relates very nice to this one. It is heavily a mission really find out which problems you want to solve and how to solve them. And of course you cannot go ahead and solve all problems at once when starting with platform engineering. Um you really need to go ahead and say hey this is probably the biggest point pain point or this is a very low hanging fruit that we can fix first and then you can go ahead fix it get feedback of developers and improve your platform from there. Next thing is design for a good user experience. And with that, I'm not talking about designing pretty UIs. I mean, of course, it's great to have those. But what I'm talking about here is really making sure that the developer using your platform has a good experience. And this is for example for um guiding people through your platform by setting UI constraints or design constraints. You don't need to have UI for that. Um really making sure that they can use the platform without reading tons of documentation first. There is a term which is called RTFM. So read the effing manual driven design and actually that's what we want to avoid. You don't want people to spend hours of reading documentation before they can do some deployment in your platform. So really make sure that you add um design constraints and so on to your platform to make developers to make the usage of your platform easy. Next, start small. Software engineers have done software development for years now, right? And platform engineering is still a pretty new space. But why don't we learn from software engineers. So what they have what they came up with is the MVP the minimum viable product. I'm pretty sure you all know it. Basically you start with the smallest set of features possible. You give it out to the customer fast. You get feedback fast and you iterate and improve from there. So why don't we do the same with platform engineering? Why don't we start with a very small thing in the even in the smallest scope possible? It could even be a conference page with a step-by-step instruction on how to do things. And why don't we start with that? Get feedback from the developers in our company and then iterate from there. Improve the platform. Add features where we see the need for them and then continue. And the last point, I might be biased on that one. I'm actually working at Dra and observability company. But make your platform observable. In my opinion, this is really important because as we headed in the beginning, a platform is a huge thing in the middle of all your teams. that is actually used for deployments, used for getting fixes out if there are problems in production, used for all the infrastructure your applications are running on and are used. And so people need to be able to trust your platform. And also you yourself need to be able to trust your platform if there have problems coming up. And so by making everything transparent, adding observability, you will know if there's problem happening. And let's face it, there are probably going to be a lot of airing problems, especially in the beginning. So we want to be aware of them as the first ones we want to fix them and so on. And the second point there are two kind of scopes in your platform. There's on the one hand the platform but on the other hand also the applications deployed to your platform. So how do you now know if an error is caused by the platform itself or by an application run and observability helps a lot with that run. And also you want to know if people are actually using your platform. In my opinion, um if you're forcing development teams to use a platform, it's probably not going to be that successful or people are going to um not going to adopt it that fast or at least not with that much yeah, let's call it joy. Um because they're used to their workflows and it will take time for people to actually um adopt to the workflow that you are offering with the platform. And so if you make it observable and if you see, hey, we have lots of returning users, that's great. But if you see, hey, we have lots of users that are coming to the platform once and then never again because they didn't like it or they always fail at this that it will be a great help for you to actually find out where you have problems and where you need to do improvements. Okay, so those five points um finding your very own needs, having a mission, designing for a good user experience, starting small and making it observable can all sum up to one sentence which is treating your developer platform as a product. And this is pretty important to me because actually you're building something that is just for internal needs. So it's really easy to run into the trap to yeah, we're going to just build it and it's all good. But I think it's really important to have a product mindset when building a platform and yeah so having this in mind is definitely helpful. But how could now the experience look for a developer that is interacting with your platform. Um to do that I want you to go on a little for journey with me and we will actually imagine we're going to a restaurant and they have a delicious burger on the menu and so we're ordering it. But what we get instead of a burger is we actually get some bread, we get h lettuce, we get meat, we get some tomato or some cheese and some tomatoes and then we have to cook it ourselves on the table. It's okayish, right? We get all the ingredients we need. We can um build it ourselves and that's good. But at least for me, it's like I know when I'm going to a restaurant, there are chefs there that know how to cook much much better than me. At least hopefully. Um, and my dish don't stay composed the burger and when I'm ordering it, I get a fullyfledged burger with maybe a nice side dish. Um, all the ingredients like fit together really nicely. All the taste I get is good. And this is actually exactly the experience I want to offer um with a platform because if you give people their ingredients, that's like the situation we have now. Everybody can get what they need. um they can deploy it but it's a lot of manual work a lot of cognitive load included compared to getting this full burger where that can do for example a deployment really really easily or Greg Hook who has put it much much nicer than me said however the value of a platform doesn't just derive from its scope but also from how well these pieces come together to form a meaningful hope meaningful hope sorry so basically what it says is like the scope of its platform of a platform is all the features, all the components it supports and so on. And this is of course important for the value of the platform. But it also is defined by how well those components are connected and actually presented by the user to be used in a nice way. And for the following part of the situation uh of the presentation, I'm assuming that we are building a platform based in Kubernetes because I'm very active in the cloud native space and that's also just how all platforms I know actually are built. And I want to show you how this abstraction could be done in a platform. And we are going to focus on two tools which are crossplane and backstage. Um crossplane actually has two superpowers. On the one hand it does infrastructure as code and on the other hand it does resource or orchestration which we'll get back later and backstage is a developer portal which I will show you. And of course there are lots of alternatives available that solve kind of the same problems or at least a set of the problems that cross pin and backstage are solving. But yeah those are just the tools that I use most. I like using them a lot especially crossplane is awesome in my opinion. Um so I'm going to show you how they're working. Okay so I told you crossplane it has two superpowers on the one hand with infra infrastructure code on the other hand with resource orchestration. So let's take it infrastructure as code first. So what you do is you install crossplane to your Kubernetes cluster and then you can install various providers to that one. So for example you could install a Google cloud provider, an Asia one, one for AWS um one that is communicating with GitHub even or many many more providers. There are tons of them out there and if there's no provider for your needs that exists um you can also write your own pretty easily which is what we have done. And those providers are done then actually talking to the target platforms and provisioning infrastructure there. So if I want to say let's keep up with the database example. Hey I want to provision a database in Asia. I can install crossplane the Asia provider and then simply in uh apply a kubernetes manifest to my kubernetes cluster and crossplane will take care of creating that database in Asia which is pretty cool and I'm going to show you exactly that now. And I'm really sorry. I know we at Global Asia Austria and my exampibility with Google Cloud. Um the reason for that is I'm just using it for my side projects at home and I know it best. So yeah, let's continue with Google. Sorry for that. Okay, let's say we want to create a database on Google. We have our Kubernetes cluster running. We have um cross installed. We have Google Cloud. We have the Google Cloud provider installed. And then we can apply two. The first one is we need to create a database instance. And if we take a closer look at the at this manifest um we can see that we're applying something of the API version which is something GCP.appbound io. So this is actually a custom resource definition that is coming from the Google cloud provider that I installed and we're creating something of kind database instance because that's what we want to create. Okay, we give it a name. Let's call it CNF sample instance and we give it some parameters like hey we want to create a post uh database. it should be in the US region and so on. And that's basically all we need. Of course, a few more configuration settings, but like that we can create the database instance by only applying a manifest to our Kubernetes cluster. And then we need a database, right? So we go ahead and do the same thing with a database. So we apply something of the same API version because it's a cod a custom resource definition that's given to us by the same provider but this time we have the kind database we give it a name again and we configure it with the instance we just created over there and that's it by applying all of that crossplane will take care and talk to Google cloud for us and actually create the database over there and this is pretty cool right but we need much much more than just database for our for our application that we want to deploy to production, we actually need the database instance, the database. We had that, but we also need a deployment, a service, an ingress, and a DNS configuration. And this is still very, very simple. I doubt that anybody is running an app as simple as that in production. But still, it's a lot to know about Ketus. You need to know how deployments work. Why do I actually need this weird service there if I have an ingress as well? and also how do I configure DNS correctly and how can I get the credentials of the database for my application to actually talk to all of them and so there is probably with only this small configuration already 100 lines or hundreds of lines of YAML that you need to write and if you're a software developer you most probably don't want to care about this at least I didn't want to care about that as a software developer so why don't we go ahead and make all of that easier for the user why don't we summarize this whole into one application that the user then can apply and which actually in the background populates our database instance database environment service in DS config and whatever else we might need and this is now the second superpower of crossplane which is resource orchestration because with crossplane we can now go ahead and create a custom resource definition and add it to kubernetes and actually what the user can then apply is something like that you can see we have API version which is demo.cloudnativelinds.github.io. So something very custom to us because we have created it. It's called application. Probably not a name you should use in your company to be honest. It's very generic and not very descriptive but I think it's good enough for the demo here. We give it a name which is my fancy app. And then we say hey we want it to be running at the domain my fancy app.cloud native link github.io. Please give me a database and please give me a disc size of 20 gigs. I know it's a very simple example as said but you can add as many parameters as you want to that one. You can also add parameters with default values so that developers don't have to fill it but can fill them if you want. And then if somebody goes ahead and actually deploys this to a Kubernetes cluster it will populate in the background all the resources you see in the left and like that it makes it much much easier for developers to deploy something to Kubernetes especially if you have GitOps as well. They don't even need to inact with the cluster but they can simply push this manifest to a Git repository and get all the nice components flavored in a way um that works for the company in the background but still the developer needs to interact with Kubernetes right so they already need to be aware of how to use cubectl or how GitHubs is working if you're going the Githops path which you hopefully do um and so it's still a bit of cognitive load Right. So to solve that, let me actually introduce you to backstage because there are many nice features about backstage but one very nice feature of backstage are software templates. Um here you can go ahead and actually create templates for users to use and they can click choose over there and then they will get a nice input mask where they can enter all the parameters that we just entered in the cosplay man or actually in the manifest which is then applied by cross. And you can see that we have the same things here. We have yet the database. We have the name. We have the disk size of the database. And in addition there is something like owner and the section channel and repository URL which we didn't need before right. And actually they wouldn't be really necessary but there is a second very nice feature of backstage which is a service catalog. So the thing I told you before where you can have centralized information about all the services, all the applications you're using and by creating a template like that, backstage can add it automatically to your by um using a template like that, backstage can add the application you created automatically um to the service catalog and all the information about ownership and stuff like that is okay. But we are with templates. So we have filled all the information we need. We click create and we can see that backstage is doing some magic in the background. First of all, it is generating files. So it's basically populating all the manifests for the database, database instance, deployment, you know it. Um, it is generating docs. So a very simple documentation template that you can build later. Um, it is publishing it which means it is pushing those manifests to GitHub because in this scenario we have a githubs tool like a speed or uh flux which is then deploying it. And last it's registering it to the catalog so that we immediately see in backstage is done. And the steps you see here are completely defined by me. So it's not something the backstage is giving us. It's basically just templating engine where you tell it hey if somebody's doing using this template please do step A first then step B step C and so on and you can have many more than those steps. Okay pretty cool. We even have a UI where you can search for different types of deployments, infrastructure you want to provision and so on. But still if I'm a developer and I want to edit the things later which I probably want to do right um there is a lot I need to know again I need to know how Kubernetes works working how deployments are working and so the things we just mentioned before. So why don't we go ahead and actually combine those from backstage which I really really like to do. So in this scenario now back the backstage template will not populate all the files for deployment service ingress but it will just create this one little manifest of crossplane that we have seen earlier which is of kind cloud native lens and named application will push it to git and then it's actually done already. So the developer can now go ahead search for components to use to deploy whatever in backstage use template to fill in variables easily. But if they want to edit something, they still have a nice manifest that's easy to read, that's easy to understand, and they can deploy it. Okay, pretty cool, right? And also sounds pretty simple. And technology wise, this thing is also not hard to do. But the thing about making things simple is making things simpler isn't always simple because you need to choose like um what do you want to abstract actually what do you want to show to the user because if you abstract too much it might be dangerous that you fall into the problem of creating um illusions because if deployment is for example so easy that you just click button and the developer is not aware that their application is actually running across regions it can be pretty dangerous for performance So also for products. So you still need to make sure that the developer is understanding the most important things about your platform and about especially how their apps are running after deploying them. Um while at the same time making this as simple as possible for them. And the four first thing about this I think that's the whole point of my presentation. I'm sorry for repeating it so often but I think it's really important. Focus on the user recruiting instructions. Focus on the applications they want to deploy. focus on what is important for your company and how you can actually um provide an abstraction that reassem uh that resembles that um while still having a nice user experience. The next point is understand your domain. Same pretty similar to the first one. Understand when you're working in which problems you want to solve, how you want to do that and so on. Next, provide opinions not restrictions. Um it's very um it would be very easy to write a platform and say hey that's the way you have to go with my platform. If not you're not using it bad luck. But that's probably something that's really bad for adoption. And also we have so many teams in the company working um or having different solutions for different problems and just applying a one-sizefits all solution to all of the problem doesn't work. Especially not in the beginning where people are adopting your platform. So what you can do is you can provide opinions. You can say hey if you follow that that standardized path that we have defined your experience is going to be best but if you have a problem or if you need to diverge from that path somewhere you can still use the platform. We can still support you but the experience is probably going to be not as good as if you follow our path. So you might want to migrate in the future or something like that. And by that you keep your platform very open. Um you keep it easy to use for developers but at the same time you're helping them a lot with standardized workflows and so on. Next thing be transparent. We already had this with observability. Um people you need people to trust your platform to actually trust you with their applications. So be transparent about what is going on. What is going on if I deploy an application there? Um what is happening in the background? where are all the things coming from that I will get actually because at least if I'm a developer I want to at least be aware of what's going on especially if there are problems I want to be able to fix them also have decision records why something was built in a certain way there are definitely people going to doubt what we did and you can say hey take a look we considered this but we made it this way because of and so on and last point show the right information at the right time especially when somebody's new to your platform, you don't want to overwhelm them with all the information I just said in transparency, but it should be easy to find it for users. And at the same time, if there's an error, failure doesn't respect abstraction. So, if there happens an error somewhere in your abstract component, the failure will just show up and it might be very confusing for the user where this one is coming from. So, really make sure to show information when it is needed and where it is needed to actually purpose. And I know it sounds so easy when I talk about it, but actually these are pretty hard problems to do, but still I think it's pretty important to consider them. So how in the end do you now build a successful platform and unfortunately I have to tell you the alltime classic. It depends. It really depends on your company, on your needs, on the developers you have, um how many resources you have and so on. But there are a few very important things like focusing on your user, focusing on the domain, starting small, iterating from there. Um, making sure that you really help people and not restrict them into a certain path they don't want to follow and so on. And if you're interested in that topic, um, I'm happy to take questions right after the presentation or I'm not sure how long will be around, but we can chat later or there are some really really nice books that probably know much more than I do. Um on the first one there's platform strategy from Griger hope. This is probably my biggest recommendation on this page. Um it's about how to do abstractions and compositions and how to do all of that and it's pretty fun to read for a textbook actually. I didn't know that textbooks could be that fun to read. Um there is also team topologies where the concept of the TVP so the final platform is run. All fantastic domain driven design. I really enjoy watching the DevOps Toolkit YouTube channel which also gives you like introduces you to to a lot of cloud native tools and how to add them to your platform where which tools make might might make sense. Um there also very nice opinions on works blog and podcast and last but not least probably the most important things a lot of the things in here come from interesting and conversations with people like you. So let's keep it up and with that thanks a lot. Um, if you uh want to talk about something, I'm not around anymore. Feel free to connect on LinkedIn. If you want to have the slides, they're over there. And thank you for listening. If there are any questions, feel free to ask. [Applause] Good. If there are no questions, yeah, just one. Thank you for the explanation. And I'm just wondering about the health chart. Can we use it as an alternative for the backstage or together with that or because I saw something like kind application. Can you please just clarify how can I come into play? Yes, of course. Um, so basically backstage and helm are solving two different problems because backstage is more like the UI in front of your platform. Um, but where help can help is like the resource or orchestration that crossplane is doing. So you remember we had those this slide. Let's see if I can go. Yeah, here it is. So we had this slide where all of those components are summarized into like one application which is the resource orchestration part of crossplane. And this is something where you could use helm. Um there are a few differences on that one. So especially if you use Helm, you're always going to do the Helm template on the client side or your GitHub tool is actually going to do it and then applying the Kubernetes manifests to uh to the Kubernetes cluster. Yes. Um but what crossplane is actually doing is it is running inside your cluster. You apply really the small application manifest to the cross uh to the cluster and then crossplane in the background will populate it. So there is a bit of difference of how those tools are working and for me I prefer the crossplane approach because it's also it's kind of the same as a deployment. If you deploy a deployment to Kubernetes it then creates a replica set for you and creates ports for you and it does all the autoscaling without anything I need to do on the client side. Whereas if I'm using Helm I always need to generate my templates on the client and then apply it to the cluster. Um but basically yes and I also have a value right. um you can use helm instead and also many companies are using helm so probably it's a very viable um alternative to crossplane and you can then in the end combine it in the same way as I combine crossplane and backstage you can combine helm and backstage but you need to take care of infrastructure somehow are there any other questions actually yeah uh I mean the entire idea is to increase department right on the developer. But if if you do that then they know less about the system. That's right. So aren't they then restricted more because they can't really go to the system and change something because they haven't learned about it because the system abracts it from them. Right. Yeah. That's completely right. And that's also always a trade-off you have to do with platform engineering. So basically every platform you build is going to be opinionated because otherwise you you can just keep it the way it is. I guess sorry I get that big problem with that. For me sounds like the system kind of is then frozen in time. It can't really evolve much from that point because you have decided what you want and from that point on the team isn't figuring out actively what their needs are. Right. Um, I hope that they still are because you could have the same argument about an application that you implement once and then it goes out to customers. Um, you could still improve it, especially if you're following AI development. And in my opinion, it's the same for platforms. So, you build it, but you're not like, hey, I'm done. I'm stepping back now because there is so much boring, especially in cloud native world, right? And also in companies, as you say, with needs are changing and so on. So for me it's really important to follow HR development and product mindset with a platform so that you stay up to date on that because it's a um huge risk what we mentioned um and at the same time if you want to go that path you can also kind of open source in your company or actually in a source it so that people can contribute and the platform can grow from there and improve a lot but you're right what you said is like pretty dangerous to not fall into thank Okay. What's the best approach for already an application which is really divorcing configuration and I kind of want to standardize it. What's like the best way to not break the application and uh make it the easiest way? Yeah, I feel you. That's like a problem we were facing a lot as well. And to be honest, we haven't found the perfect solution for that one. Probably doesn't exist. Um, but what we can do is like really I don't know if you have like one application or if you have like many applications like that. Um, but with crossplane or any other templating tool, it doesn't matter. Um, really try to provide same defaults but give developers a lot of configuration options and also maybe if they if you're deploying to Kubernetes, I don't know. Okay. But I actually it applies to everything. Um, Maybe you can also solve parts of the application deployment for example with the platform and then you see hey this is working this is nicely but the developers would prefer the workflow a bit like that you can adjust to that one and then you can again grow from there and but it's a very hard thing to do and it requires a lot of failure as well to be honest but with lot of iteration and yeah finding needs of developers by talking to them by doing surveys by doing observability and finding how using your platform, you might hopefully get there. Thank you. Yeah, if there are no other questions, um, thanks a lot for listening. As said, please reach out to me if anything comes up to your mind later on. And have a great day. Thank you for being here.