Cloud Native Theater | Cloud Native University: Platform Engineering - About Tools... Max Körbächer

This talk focuses on the essential elements of platform engineering, emphasizing the importance of people, culture, and processes over specific technologies. The speaker highlights the concept of cognitive load, which describes how overwhelming tools and processes can hinder productivity. They introduce the idea of 'golden paths' in platform development, allowing flexibility while providing structure. The discussion touches on cloud-native practices, the importance of treating platform engineering as a continuous product rather than a one-time project, and the necessity of self-service capabilities. Additionally, the speaker stresses the need for effective feedback loops, user research, and advocacy within teams to create a collaborative environment that fosters improvement and innovation. Ultimately, the talk argues that successful platform engineering depends on a mindset shift that prioritizes outcomes over outputs.

Thank you very much Simon. Hi, I'm Max. Running normally to earn the cat food consulting company. But besides that I'm usually spend my time in the open source community as a being part of the CNCF governing board or as a CNCF ambassador or also part of the Linux Foundation Europe advisory board. So do my things in my best I can do here to steer a little bit

and influence a little bit on open source. And um I also wrote a book about platform engineering. I guess that's why I'm here. And um I'm pretty much focused more on like the stuff in between. So I do not want to give you like a very precise YAML file how to do something. I really would like to talk more about like the people, the culture and the

processes because most platform engineering practices, most platform engineering projects are going to fail because one of these three things but almost never about the pure technology. Except you take a very very horrible decision here. So why does it matter? Why does platform engineering matter? Um Daniel Bryant once make there a very interesting term which he put out which is called cognitive load. And cognitive load is this

one beautiful thing where you are completely overwhelmed with what you are doing because you have too many tools, too many processes, too many things that you have to follow that all are impacting your work and that are all causing that you continuously have shift back and forth between your actual practice and your actual feature creation. Right? So platform engineering should help you through let's call it automation,

through simplicity, through putting you yet another abstraction layer maybe um a way more smoother process of creating value. This value can be anything. It can be software, it can be implementation of a of a new feature, um just being some some backend system just all like this. And then we have the golden pass. Who of you have heard about golden passes? Just a few. All right. So,

golden passes are practically like the uh really opinionated approach of giving you a track you have to follow. The secret for making a golden pass successful is that you don't strictly have to follow it, but you always have the possibility to take an escape hatch. Right? It's like hiking in the mountains. The sections which are dangerous, you should stick to the route which someone has predefined for

you. But if you're running over a green field and you have possibilities to go left and right and discover a valley and whatsoever, feel free to do so. So, if you're doing a platform engineering practice and you're introducing that, take care that you always give somehow the escape hatches and let engineers discover the green field in the nice valleys you're usually into. And then, last but not

least, we have to talk about cloud native at scale. The most cloud native projects tend to be very complicated at some point in time. Because you have a lot of options. We have for every problem one, two, three, four, five, maybe 10 ways to solve it. Most of them are overlapping. Most of them are overlapping with the solution for other problem-solving tools. And so, it's the nature

of a platform engineer to well, continuously work, find a better option how to do it, find something that helps the engineers to use the platform and so on and so forth. So, this is a continuous cycle, a continuously um ongoing process and that causes that usually platforms are scaling with some time. And that's okay. Because on the other hand side, successful platforms give you the possibility to

also reduce the uh time you need in operations. One of our biggest system which we are helping to to build and run is since 4 5 years with the same size team. Doesn't matter that it has starts spinning globally. Doesn't matter that it runs thousands of millions of nodes and end point devices against it. It just get more efficient. And this is the power of platform engineering

of building a platform that it become at some point so efficient that you can scale more or less infinitely without necessarily to grow the team or to have the work growing behind it. I just will talk very shortly about tools because as I said for platform tools is often just a variable. You will always find tools to solve some problems. But normally if you do platform engineering

you will not fail because of the tool. We have all of our good old standards here for orchestration. Obviously Kubernetes. You have containers. Always like to say we have OCI compliant containers, not Docker containers. Also Docker did a great job to make containers the the number one running environment for for software. We talk about GitOps, right? Infrastructure as code with Open Tofu, fantastic approach to do so.

Observability is important. Security is The thing is we don't need to go too much into detail of this one because you have like all the project pavilions up there. You have hundreds of other talks around which every of these goes very deep into each of those tools to help you to understand for which use case, for which problem you are up here for solving it. But most

of these talks do not take a look into like how we are doing actually it. So how do we get into practice with our platform engineering? And one crucial point here is thinking about the introduction of platforms and running platform engineering not as a project but to change a little bit your mindset and think about it as a product. What is the difference? If you do a

project and it hits a deadline usually it's dead. Right? Money goes away, people goes away, time goes away. So suddenly everything you have implemented somehow feels wasted because it gets into a maintenance mode. And then what? But if you come frequently to KubeCon or whether it's the first time, you will hear that there is continuously something new. Something is shifting, something is changing. The last 2-3 years

are these defined by AI. Um it's same same but it's somehow also different. It changed what we have to implement on it. So thinking in a platform as a product means that I continuously adapt and uh try to find the the best solution for my use case. And there's also no one good reference architecture itself. You have to identify the way how to implement the by your

by your organization. What is my demand as an organization? I just I cannot just copy-paste I don't know, GitHub, Spotify, whatsoever. It will not work directly in your org. Self-service and automation is one of the most crucial things and the most helpful things. I do not know how about you but I hate to take a service request. I don't like to open somewhere in a weird web

portal and then requesting I need somewhere some access or an API key for something. You have to wait, approval, blah blah blah. So self-service in the platform engineering doesn't mean that you maybe get infinite access of everything but to every tool that you need to orchestrate your work, to manage and implement the first development environments. This is a crucial part. And this should be done by yourself.

Right? You should be able to do it. You don't need to wait for something else. I think that's always a little bit the management perspective. Someone don't trust in you. That's for me always the key argument. Why I'm not allowed to just generate for me an an API key to access, I don't know, XYZ cloud provider. You don't trust me? Am I not skilled enough? So, it's

a good argumentation for your management maybe to reconsider it. Something that you will hear quite often is like this shift left. Be careful that you don't shift left. Shift left means you throw actually everything down the pipe. But when you think back about developer and their cognitive load, it doesn't help me that I have automated everything. But still I tell someone here's like 20 tools that you

all need to interact with. This is not the helpful part because then still someone needs to think about like, okay, when I use this one, when I have to do that one. So, the actual relevant part is that everything is like again in a golden path already linked together is guiding you from one step to the other without that you have to break this flow. And last

but not least, you should measure your developer experience. Actually talking later today also about the developer experience and why it matters for platform engineering. The part about developer experience and the measurement of it is you should measure before you start implementing something. Because you else do not know how have your how is your platform or your practices impacting the way you're implementing the platform. We see a

lot of projects starting with platform engineering practices, introducing IDPs and so on. And then after 1 2 years of project time, they start implementing something to measure the successfulness of it. But the problem is you have nothing to compare for the beginning. So, this is why you need to start measure today. Start with your platform engineering practice. Start implementing IDP and measure it along the way. Only

then you can see how it is changing, how it is improving, how it is move forward. So, for me the best platform teams do do think like a platform think like a product team. Not like an infrastructure team. And that's what we also quite often see that we just shift up infrastructure team to do now platform. But there's more behind it. For example, that we talk about

like the user Yeah? Who of you is used to do one-on-ones for user research? How often you have you asked your developer what they need? I see like maybe 10 hands. That's quite too less. Where do you know from what someone of the development team needs? Where do you know from what the engineering team needs? Are you the expert of implementing, I don't know, an AI platform,

uh e-commerce store, a database? You maybe know it, but you maybe do not know what is needed. So, do excessive user research, um engage for collaboration, work with the people, talk to them, yeah, co-create, open up open up your platform and call for contribution. That's some part of the empowerment also. Yeah? And last but not least you need to implement also very short, very fast feedback loops.

Feedback loops not only in the platform, but also for the people who are using the platform, so that you get in a safe and open manner very fast feedback if someone loves a feature or someone hates a feature. If someone is getting lost on the track while using a platform, or someone really feels empowered and engaged and like to actually be in maybe your internal ambassador for

your And this brings us to the last part, the culture. So, we talked about the tools, we talked about processes, we talked about the people. And this all comes together in the end for culture. You need to enable and train people. You need to give them time to play around. There's nothing more horrible for an organization if you have zero time to learn and train something new.

Because else you do not know if there's maybe something better, something more helpful, something more valuable for your teams. And for this you can build communities. We call that inner source. So, we not just bring people together, making town hall meetings, make sessions like this today, but also to engage with them, open up for them that they have the possibility to contribute code and bring their own

improvement. Because sometimes it's just little small things that needs to be changed to make a good service great, to automate a very specific step in your whole developer flow entirely through. And this helps for every other engineer to utilize your platform more and being more efficient and actually more happier in the end to really use And last but not least, that's the most hardest thing for the

most engineers, advocacy marketing, internal marketing as an engineer. But um telling what you're doing good and what your platform is helping someone for, where they should know it from? From the other people who like to use it but never talk about it? So, this is a very crucial element that you be bold and brave and loud. If you have a successful platform, to also communicate it to

everyone else. And don't be afraid of negative feedback or that people come to you and tell you like, "Ah, I do not like this platform. It doesn't fulfill my use case." Sure, no problem. Then tell me how I can fulfill your use case because it's open. You can contribute to solving your problem. I can help you to show your best practice. And you can make it that

everyone else is can using it. in the end, the little North Star which you need to put up when we're talking about platform engineering and implementing IDPs, is that the mindset shift is like one of the most crucial driver. It helps you with the processes, with the culture, uh with the people to go from infrastructure to product thinking. To help you from get away and get rid

of tickets and think more about self-service. Not in the service now echo space, but you go into one single portal where you can drive by yourself the creation of a new key, for example. Get rid of top-down mandates. It's helpful if someone dictates you the direction and give you a vision where you want to be, but you also need people that helps you to drive that. And

that's usually your developers. And look to the outcomes, not for the output. Outcome means you want to know if someone is happy with your platform and successful, and not just like how many features someone has released. Because features I can fake. That's quite easy. Right? I just cut user stories in smaller one and suddenly I have two features released instead of one. So, in the end, about

platform engineering, it's everything about people, culture, and processes. And what you need to learn about the tools you will find today on the project Pavel Larson all the other talks here on the conference. Thank you very much.