 Hey everybody, welcome to this online event with CNCF. We are going to speak about the 10 fallacies in platform engineering. I'm Kasper, I'm the CEO of Humanitech. Humanitech is a platform orchestrator that helps many teams across the world build their internal developer platform orchestrating application and infrastructure for configurations. I encourage you to get in touch with me. I love debating all things cloud-native and platform engineering. My Twitter is Kasper official and my email is Kasper at Humanitech.com. So I'm looking forward to hearing from you. In today's talk we are going to briefly cover what we actually mean if we speak about platforming, about platform engineering and about internal developer platforms in particular. And we are going to cover the top 10 fallacies that we are observing in platform engineering. I've been active in that space for 10 years now. I've seen many, many, many teams across larger enterprises and scale-ups building these platforms very successfully and stumbling into the ever repeating patterns of fallacies along the way. And I want to share these insights with you today to help you prevent these fallacies and build successful platforms that enable self-service with low cognitive load, establish golden paths and ultimately lead to happy and productive developers. Let's actually start by understanding what the underlying problem is. If you compare the applications that we're building today with the applications that we built 10 years ago, then you can see that the average application has 25 times more components, services, resources than an application had in 2010. We have five times the amount of specialized tools. The digital factory, if you want, is much more diverse, much more tailored to specific use cases than the factory floor that we were confronted with 10 years ago. And the ever-evolving global environment really drives demand and complexity. Today we're shipping applications across the globe with vast amounts of users across different time zones with huge amount of traffic. Because of that, teams waste 25% of their time operating applications as the complexity increases. Our current approach to trying to control this chaos is manual work and scripts. What you can see very often is that you have operation teams that get bombarded with repetitive requests on JIRA or ServiceNow or Slack or Microsoft Teams. And that means developers wait, operations drown in these repetitive tasks. And the better way, if you want, is to make it simpler for developers to actually solve the underlying problem themselves. And this is why we have platform engineering. The application developers, it's really about reducing cognitive load, but without actually being abstracted away and without breaking the workflow, but in a way that drives self-service, though they are less dependent on others to debug their deployment, help them with Terraform or whatever the current pain point is. And second, the second persona that we are speaking about here is the platform team or the SRE slash dev ops slash ops team, whomever you'd be, whatever name your organization is currently using. Now, they are concerned with driving standardization by design, reducing ticket ops and ultimately focusing on improving the status quo rather than reacting to repetitive requests from their engineering team. And these platform engineers, they built internal developer platforms. An internal developer platform is the sum of many components that form golden paths for developers to enable self-service with low cognitive load. There isn't the internal developer platform. And that is frustrating for many people that ask me, hey, what's an internal developer platform? The platform at a global bank will look very different to the platform at a scale up in San Francisco. And that means we much rather have to look at what are the building blocks that we see platforms used and put together today. The modern dynamic internal developer platform from a flow perspective could be an IDE to code, version control to merge, NECI to build. In many organizations, we have many different components than a platform orchestrator to actually orchestrate the infrastructure and application configurations. And you have different interfaces into these platforms. They could be an API, GitOps, ClickOps, CLI, observability, service catalogs, portals, the lean IX campus backstage of this world. That's platform engineering that is internal developer platforms. I'll give you a couple of links about this ever-growing community around platform engineering later. So as we're now actually starting to platform the digital world, we are seeing these, we are seeing more and more consistent fallacies that teams run into and fall for. And I now actually want to guide you through the most common ones that I see. Number one is the prioritization fallacy. You're starting your platforming journey. You are convinced that, hey, that's exactly, we have to take control of our platform. Otherwise, the platform will build itself. And we want to now actually build our first golden path, reduce cognitive load for our developers. Now, how do we choose where to start? There are so many elements. We could look at configuration management. We could look at the onboarding experience of a developer. We could look for the, we can optimize for the creation of a new service. The first recommendation that I have here, don't do that and don't come up with that prioritization out of thin air. If you are creating 10 microservices a year, you really have to ask yourself, is the creation and the scaffolding of a new service what we should optimize for? Can't we just take GitHub templates? Do we really need a complex portal? If you are onboarding two, three engineers a month, is that really what you have to optimize for? So the first thing to actually mitigate the prioritization of fallacy is to not only follow your instinct, but come up or generate numbers to actually back up your assumption. We're always tempted to start with the things that feel like they're the first things to occur in the lifecycle of either a developer or a service, but that might not actually yield the largest results. I always recommend the following exercise as you're looking to prioritize. Take a blank piece of paper. Now, go ahead and ask yourself, what are the things that developers do on a daily basis that go beyond the simple update of an image? Just list those things that could be adding an environment variable, adding services or dependencies, refactoring, changing resources, waiting due to blocked environments, spinning up environments, onboarding developers, scaffolding new microservices, all of these things. Once that is done, list how often you do that and standardize this against 100 deployments. So 100 deployments, how often do you do things like adding a new environment variable? Then list the developer time, so the time developer spend per individual action and the time that operation spends per individual action. And once this is done, actually compute the numbers against your total numbers of deployment and you have your prioritization. Follow that prioritization because it will actually ultimately give you a feeling for what your return on investment on your platforming endeavor will be. Second, the visualization fallacy. My friend Lee, who built several very large internal developer platforms, wrote a great article on platformengineering.org that was called if you put a pane of glass on a pile of shit, all you see is a pile of shit. And that's provocative, but pretty accurate. We have a tendency, especially if the platform endeavor is management driven, to build beautiful fancy dashboards, to stream things from different places and visualize them a little nicer. But again, the question is, are you really driving ROI? Has ClickOps been really successful? Are you making a material difference for the lives of your developers? If the answer is yes, and it might be, then you should totally do that. But be aware of the visualization fallacy. The most obvious thing to do that's nice to look at might not actually, again, yield the largest results. Now, the third fallacy is the wars you cannot win fallacy. One of the impulses that I observe with platform engineers is that they look at the current landscape and they say, this tool or this tool is not good or we can do better or it's not even about judging the tool, but more about we want to bring all the developers into one tool and that means we will move from Jenkins into Azure DevOps and from GitHub actions into Azure DevOps just to solidify this. Now, again, it comes down to prioritization. If a team is working in Jenkins pipelines and they do the job and all of their tests, all of their things, all of their scripts are in Jenkins pipelines and it works well or even okay, is the biggest impact you can do actually standardizing and taking things away from teams that they're used to, maybe and maybe not. If you think you will meet resistance from the engineering team and from the developers and you think, hey, this will be a little bit of a war to actually fight this through, ask yourself whether that's worth it. The job is to make life simpler for the developers and if you look at these things and you think, well, this will be a tough conversation, go back to the drawing board, ask yourself what are the actual things that drive return on investment. The fourth thing is the everything and everybody at once fallacy. I'm often seeing platform engineers at the start of their journey and they have these crazy ideas and dreams of what the platform could do and they're sitting in planning meetings and they are coming up with this creature that can solve all problems and deal with all technologies. In German we say eine eier liegende Wolchmilchsaum, so that means a sheep that is also a pig but it can also lay eggs and it will also provide milk. That's obviously a creature that doesn't exist. A fallacy that is really, we really have to be aware of is the everything and everybody at once fallacy and you mitigate that by again, obviously prioritizing but also by starting with small units. Small units means small unit means you are looking at a lighthouse application and the application developers in that lighthouse application and you are just focusing on that subgroup. That subgroup is hopefully on the what I would refer to as the lowest common denominator of your technology and especially of your future technology stack. So if you're saying in the future we are going to standardize on and I'm just making something up containers and Kubernetes and that subset of databases you want that initial application unit to be representative of that lowest common denominator. You want to focus on a specific set of technologies on a specific type of future proof application design and on an application team that you can turn into evangelists and then you want to prioritize and you want to look at the smallest little thing that you can do for them that has a large impact and then you want to iterate and iterate and iterate. There is this quote from Paul Graham that I really enjoy that means that says do small things that don't scale for to start with and that's exactly what you need to do right here. What are the small things you can do they don't have to scale yet but that really will make this team fall in love with your platform one with your general approach of platform engineering because these people will be your evangelists and they will be your advocates. The next fallacy is the new setup isn't better fallacy and that's it ties into the previous fallacy. If you are you know again you're sitting in a room and you're building something really complex and then you're coming out into the world with a big bang and you're really proud of what you've achieved and it's just not better than what's already there and what people are already used to then you will not find any adoption which is why it's so important that you start small and that you iterate and that you continuously actually treat this product treat this platform as a product a product that has a product manager and a g-ra board and users and interviews you do to really come up with something that is better and better doesn't mean larger it doesn't mean has more functionality it means that small things you start with small things you optimize are definitely better than the the approach or the situation that the developers were confronted before the platforming world. The sixth one one that is very dear to my heart is the abstraction fallacy especially in the 2010s many teams built platforms that abstracted developers away from from something from underlying systems or that took away context that is something that you cannot do it cannot happen it is very important that developers at every point in time can actually understand the underlying systems can dive deep can gain all context down to the terraform level if you want so if you give them a cli that just gives them an s3 bucket and they don't know how it's configured or how it was specifically set up you're probably not really helping them and even if what you've provided for some reason is the right thing they will still mistrust and that will ultimately limit adoption and you will not be successful I like to compare that to natural language processing if your zeery for instance or or Alexa would be working in 95% of cases but fail you in 5% of cases you as a human would be discontent and the same holds true for abstraction if your abstraction works in even 95% of cases and it's very hard to reach that accuracy but they fail the developers in 5% it's human nature that they will distrust the system the seventh is the loudest voice fallacy I already hinted at that I dearly recommend treating your platform as a product Manuel paiz team topologies they said it over and over again but it's so important and if you treat your platform as a product you will need to make to do user research and more and more platform engineers are actually doing this and if you are doing research be aware of the loudest voice fallacy if you have your annual hackathon and you're sitting in a room with all your engineers there are the linux kernel hackers in there there is the junior there is the mid-level developer and you ask them hey how do you want to have this platform designed who is the person you think that is actually going to drive that user research well it will probably be the linux kernel hacker because they are the most self-confident and they will want to go low level and you will they will always work on driving the platform to be maybe a little bit too complex so the recommendation is to make sure that you design the platform for the weakest link and you're aware of the loudest voice fallacy you can mitigate that by actually speaking to users individually conduct 10 converse interviews with juniors 10 interviews with mid-level make sure you get qa front and back and healthy mix obviously also speak with the kernel hackers to make sure they can leave the golden path at any point in time and actually get what they need and establish a communication that is respectful of all different abilities or frankly the focus that different engineers have on a daily basis the next one is the freedom fallacy and that is slightly contradicting what i told you before the it is very important that the developers can go under the hood and they can leave the golden path and they're not abstracted away but that doesn't mean that we need to end up with a stack that has 700 different flavors on how to create an rds instance there is value in standardization standardization not at the risk of abstraction standardization not in a way that we slow anybody down but if you let everything you allow everything to happen every cloud every product every convention then this will significantly slow you down and so i encourage you to have a conversation with the team about the value of a certain level of standardization a certain lowest common tech denominator does that mean you cannot use the fancy lambda function no obviously you can but the question is how is everybody conscious of balancing the complexity that we're driving versus the actual outcome that we want to reach the google facebook netflix fallacy is an obvious one that i dearly love but it's one that we all run into all the time all of the hr teams at these companies have the mandate to explain how amazing their engineering organization really is and that means the engineers at these companies they go out and they speak about the practices and how netflix is doing things and how great everything is and how much resources they have if you listen to them too much you will probably not become very happy because neither you nor me actually have the resources the money or the headcount to pull off what these companies can pull off and if you follow this too thoroughly and you get blended too much by their frankly hr content you might actually make very costly decisions that will hurt your productivity and last but not least the compete with amazon web services fallacy if there is something that you can get from a like from an from an amazon really that they have 50 developers focused on for three years don't compete with them the job of a platform engineer is to bind the different tools in a consistent experience that means our focus is much rather the glue between these systems and not actually competing with those tools themselves we really always have to ask ourselves is the you know the the time and the innovation capacity we're putting in there that that is actually keeping us away from doing other things that helps help the business is that actually going to pay off all right and with that thank you very much for listening to this conversation i hope you took something away i encouraged you to check out the platform engineering community that is platform engineering dot all the platform engineering slack group platform engineering meet up groups in many cities in north america europe and the pacific region platform con a conference this is a very fast growing healthy community if you have any questions reach out to me i'm very much looking forward to debating this topic that's very dear to my heart