 Hey everybody, I'm Kaspar and today I'm going to talk about a step to step guide to platforming your delivery setup This is an incredibly Interesting topic at a time where the category of internal developer platforms and platform engineering in general is rapidly accelerating Really quickly about me. I have been doing platforming for the last 10 years. I Am working with and on the community's internal developer platform.org platform engineering.org I'm organizing platform engineering slack Platform engineering meetups with many other others. Obviously platform con the largest Conference in that space and I'm also working with the team at humanitech a platform orchestrator if you have any Things you want to talk about then please feel free to reach out I'm very much enjoying these direct outreaches ping me at Kaspar at humanitech.com or on my Twitter handle Kaspar official Now in this talk in these next couple of minutes I want to talk about what platforming actually is Why we do that and then I wanted to give you a step-by-step guide to nailing your platform journey This is something very new and Many of you are struggling where to actually start the benefits of this are pretty obvious But finding that starting point and designing your journey and setting yourself up to success is Non-trivial because there is not that much material out there And I want to make a small contribution to this and I hope I can help you on your path Now what's the actual problem statement? Let's frame this problem set a little better if you look at our situation today and you compare that to our situation 10 12 years ago Then the total numbers of services and dependent resources are architectures are vastly more complex than they were before We're using a lot more specialized tooling every Second week. There is another part of the two chain evolving Security tools and scanning things are getting shift left all the time. So we have a Larger complexity in our architectures and we have a lot more tools to somehow deal with and at the same time the pressure on Us as an industry and as the people in this industry is ever growing We have thousands hundred thousands of users. There is a pandemic that is increasing digitization even further And because of that complexity because of that pressure The average team is wasting 25% of their time just operating their app as this complexity increases at the same time what they actually want to do is focus on coding but a lot of the things get lost in the Communication in the team and the vast cognitive load of the two chain Now our response to that complexity is really manual work and scripts so if we have Microservice application running in the cloud. We're trying to shoo home stuff together and we're throwing Terraform files and when we're very fancy we throw cross-plane files and we are Trying to bake these things into Helm charts and Yummels and complex pipelines and Jenkins beasts and all of that but that makes developers brown in the complexity and Operations as well and everybody is waiting. Nobody's really Making any progress. Nobody's really satisfied. There is this constant tension between do I offload too much to my engineers? I shift a lot of things left or do I abstract them from stuff which wakes which takes away context. That's also and Dangerous, so how do you actually navigate in this uncertain environment? My answer is you build platforms you build internal developer platforms because these platforms help application developers to self-serve things without waiting While even reducing cognitive load There's no value in shifting things left when the person we're receiving end of that shift left is Drowning in complexity and cannot actually do the job that she's she's paid for and the same time again You want to do that without abstracting. It's very important I'm always comparing that to natural language processing if you hit NLP with 95% accuracy You still think and you still distrust zero Alexa You really want to be able to do everything, but you want to do that you don't want to have to Operate everything at once all the time We call that I call that abstracting but without actually taking context having golden paths You can rely on that's platforming that is the value for application developers and for the platform and SRE and DevOps teams or whatever Name you're using these days. It's about driving standardization by design It's about maybe trying to prevent 180 different ways of spinning up RDS But giving these five ways that are securely vetted and work well and setting starting points from which the teams Can actually expand and build on and it's about reducing ticket ops many of you are in a Situation where you're bombarded with Gira tickets. I need a new Environment here. I need a new database there. Can you help me debug that? Deployment that is not very productive. We've had that situation Throw over the fence operations if you want a decade two decades ago It is not something that we want to go back because you should actually be able to focus You should be able to focus on further automation on making sure our delivery approach is secure Let me use an analogy of the automotive industry an immature organization Would tell a team to build a car They would give them a credit card and then tell them you can find your raw materials in this store Then when these teams would struggle they would send in people to help them organize that and then they would call that DevOps Now a mature organization would tell teams to build a car and they would give them the credit card And they would tell them where to find the raw materials and then if teams struggle DevOps helps them organize and cloud operation teams helps them to find the right materials and then prep those for them and The next evolution you've guessed it Advanced organization tell teams to build a car and then the platform team prepares a platform and The developers build on top That is common practice in almost every industry and there is no reason to believe that this Shouldn't be a good approach in the software industry as well Now the result of what you platform the sum of all things is what we call an internal developer platform It is the sum of all things that form a golden path for developers one that developers can take But they don't have to they can deviate from that There are many tools these days that say We are an out-of-the-box IDP and what these tools actually are our platform as a service. Think of it like a Roku a Platform an internal developer platform is what you build for the specific needs of your organization if you're looking at this from a flow perspective, it And can passes your IDE where you develop this code that is then connected to your version control system where you merge your code It is connected to your CI pipelines where we build to your registries Then you might be using something like a CD controller or more modern platforms Maybe a platform orchestrator and then all the way to your infrastructure all of that is part of your platform And then there are many interfaces that your Platform might have there might be an API into parts of the controller or orchestrators It might be fully good ops-based. It might be a UI. It might be a CLI it Is definitely wired up with your observability suite. You might have something like a service catalog or portal such as backstage or Lina X or any of these tools So again a platform is the sum of all things is how you craft your different tools into something that works well for developers With all that with all of this new information thrown at you, where do you actually start and I want to give you a step-by-step guide that is a little more reduced than all of the flood of information That is usually thrown at you Let's actually start with what I would propose you do as a step number one you say And you communicate that to your team and management. We are going to test this approach But we are going to do all in or nothing Any time I personally have done something 80% and not a hundred where I've not actually pulled through and Bumper hole exercise I have failed. I really believe in all in all nothing And in order to reach all in you and all nothing you have to treat your platform as a product and that means you have to assign a product owner and if This product owner doesn't have enough for a full-time position. Maybe it can be half or a quarter a Platform can start very small. You don't have to start with a big bang So maybe you don't need a full-time position there But you want to have somebody who makes sure that there is a roadmap and then there are user interviews and You understand that you have users. These are your internal developers and A platform team has software engineers people that actually build stuff It is not enough to build a group of cultural practitioners and call it a platform team You want to have people that actually Build products. This is a product and it's getting better The more you realize that it actually is a product now then Step second Prioritize that is the most common fallacy that I see in platform engineering I wrote a long article around this the 10 fallacies of platform engineering that I Encourage you to have a look at as well Prioritization and what people often get wrong is that they think about the application life cycle and maybe the journey of the developer and Then say well, why don't we start at the start? Why don't we optimize how somebody spins up a new microservice or starts a new application or How somebody gets on board? all of these things sound fairly obvious, but Just because something is at the beginning Doesn't necessarily mean it's actually giving you the return on investment that would move the needle Which is actually what you want with a platform a platform only makes sense if you save time for your users now think about this example Optimizing how to spin up a microservice. What would you probably do? you would Set a baseline microservice that would already contain the way you want to have a Python flask service configured and Then you might want then you would might be built because you think that Looks more beautiful a nice UI where you would hit a button and it would clone the repository and maybe run a pipeline That will take you a good amount of time You'll throw together an Angular product like front-end whatever and it will feel not that complex for the start But it will you'll add this and you'll add this and you'll add this now afterwards developers are able to Click that button and it would do exactly the same thing as if they would go into github templates and just clone a template and You have a lot of effort just waste it for something that probably doesn't move the needle and is more nice to have So how do you make sure you do the things that matter and that move the needle now? I have an exercise that I'm using that might help you as well Gather your colleagues and say Think of a hundred deployments. We're deploying a hundred times How often do you do things that go beyond the static case of updating an image, right? I mean for updating an image. Everything is in place. You do your git push your CI pipelines runs and you push your images somewhere and you update your pop. That's probably the part you figured out but how often In Stabilized against 100 deployments. Do we do things that go beyond the simple update of an image things where we might introduce errors where We might need the help of others where having a golden path is actually great This could be things like you want to change Configurations you want to change the architecture you want to onboard a new colleague you want to refactor You maybe want to spin up a new microservice. You want to spin up in new environment You want to roll back any of these things how often do you do them? So here these numbers are an exercise that I made with a team a team That was fairly fast scaling and you can see that they're adding an environment variable every 20 deployments And then all of that and they need a new environment every 300 deployments all of that doesn't feel like a lot But then if these individual things happen, they eat a lot of time from development and a lot of time from operations teams Now if you add all of that up You'll come up with a pretty considerable amount of time that is wasted on just these things that go beyond the simple Update of an image. It's almost like a hockey stick function Everything is fine. Everything is fine And then if you do these things that go beyond the update of an image you actually produce a huge amount of overhead and cost Now do that exercise force rank be brutally honest with you that is where you find your ROI This is where you should actually get started now the next thing that Many teams get wrong is that they try to build platforms that and can pass everything and I Get where you're coming from because you maybe you might be working in in enterprise with a lot of legacy and I mean even in a scaling startup, whatever you'll have a lot of legacy and you try to Cater everything and you will fail if you do that because there is No team in the world and not no budget endowment that your management can give you that can cover everything That is a dream and nothing but a dream if you want to build something that works Well, you have to agree on the lowest common denominator with all of the people and in your team and you can say if you want to go off that beaten path you can do that but That means you're on your own. We don't support you. You're on pager duty and you have to deal with the consequences Now whatever you come up with stick to it. It's very likely that you're going to standardize on containers and cubanettis and One or two managed providers and a couple of databases But find that lowest common denominator and the smaller you make your text tag The better you will actually do as the platform team. You have a very high interest on keeping your text tag Small re number four identify a team of future evangelists One of the fallacies that I'm seeing is that people want to do this big bang. They want to do everything at once I call the everything at once fallacy Not a very good idea Identify this one team that is bursting from Joy of doing something innovative that really feel the pain that want to get better This team has to have an application That matches exactly your target lowest common denominator text set up Right. Let's stay in the cubanettis world They are building an application that is running one hundred percent on eks And they're using a couple of databases terraform, whatever, but it's what you've optimized against and you are focusing on this and they match exactly this material Take these people Make him make them your friends and focus on them with extreme dedication Arguably too much dedication, which brings us to step to the next step You have to make a decision on the general architecture, especially on configuration management, something that not enough people actually think about And you basically have two choices. You have dynamic or static configuration management Now, the more modern internal developer platforms that we're seeing are using what we call static config dynamic configuration management That means rather than having pre-baked YAML terraform combinations for every environment, you are building what we call a declarative application model Like a baking recipe on how your application should look like across all environments And they are then taking that declarative application model and execute this against a platform orchestrator Which reads this model and creates a dynamic, dynamically creates a representation of this configuration and actually deploys that as an application into your infrastructure That has a lot of advantages to this more modern approach because you can now standardize certain profiles on the workload, config and infra level Across the organization, your developers can stay on a higher level abstraction while still seeing all of the different components It enables you to really keep consistency and high maintainability across all of these things and it makes for a very good developer experience So my usual recommendation is try to apply dynamic configuration management But if that for some reason isn't possible, you can still stick with the current approach that most teams have historically been using That is a static configuration management and that means you have your workload and you have static YAML files per environment And then you have static infrastructure as code elements and you have a CD controller like an IWO CD that's just taking these files and syncing them with the infrastructure Now, as a next step, let's go off and actually start building And here the trick is to build something that serves your ROI calculation return on investment that we did at the beginning Like what is the priority? Where do you yield the best results? It has to fit to your team of evangelists, right? The folks that love you so much or are supposed to love you so much And it has to be on your lowest common denominator text tag And then you want to build an experience that is 10x better than anything that your team has seen before Many of these platforms fail because they promise a lot and what they deliver as the future platform is even has more edges and is more raw And is not actually making a difference for the individual contributor I call that the tragedy of the commons problem, right? It's like climate change If you build something that's great for the organization but it doesn't move the needle for the individual contributor, nobody's going to use it, right? You win nothing On this first project, I encourage you to spend way too much time, way too much time Overallocate too much time in getting this one thing to a degree where people look at this and say, wow, this is really nice That's 10x better than what we've been using before And then make sure your evangelist team loves it because only if they love it, they will do something that will make you long term successful They will go to all of their colleagues in the organization and say, hey, we're using this product now, we're using this platform We are already on the new flow and it's so much better You really have to try it Pull always works much better than push Last but not least, this will be a very long journey It's a long journey that never ends You have to iterate and iterate and iterate and iterate When you have your first project and that is 10x better Even if it's only doing this tiny little thing, getting you a new namespace better than what you had before Then you take the next approach and you again look at your ROI and you again do user interviews And you again treat your platform as a product And again, you're going into the details and you're figuring out what's the next best thing to work on And you continue building golden paths, you continue winning over evangelists that then create a pull factor That is the way how you make platforming and building an internal developer platform long term successful There's also a growing community of practitioners around platforming You're not alone with this, there are channels just for product owners of platforms There are even job boards just for platform engineers There's a very vivid conversation going on We have platform con coming up, thousands of fellow platform engineers Are people that are interested to doing that or becoming such Joining us on the I think 9th and 10th of June 2022 And I encourage you to take part in that as well There are platform engineering meetups, I'm sure there is one next to you Or you can start your own and there are learning materials on sites like platformengineering.org I encourage you to become part of this community to join me in taking this category and taking this way of working forward I am convinced that in five years almost every team has these platforms And I would also encourage you to get in touch with me and let's chat about these things Ask me questions, I'm always happy to help I'm personally working on Humanitech and with Humanitech And Humanitech is a platform orchestrator that is optimized for dynamic internal developer platforms It's a component that can help you build reliable platforms that developers laugh really fast And it's fairly widely used if there is anything I can show you around that Also feel free to reach out For now, thank you so much for listening to that talk And I hope to see you soon online or offline