Platform Engineering's Inferno

Imagine yourself as Dante, lost in a Deep Dark Forest.

You are not alone, I will be your Virgil, your guide through the Engineering Hell.
This Platform Engineering dream can, and will, be turned into a nightmare if tools and practices are adopted without a rationale and no focus on culture.
Following an oneiric path, inspired by the Divine Comedy, we will travel through each Hell ring, examining all the different ways to fall into the flame pit of Engineering Hell, all the demons you can encounter on the way to reach the peaks of your well deserved Platform Engineering Eden.

Transcript

1. Platform Engineering’s Inferno 1
2. Agenda Introduction This journey will start with an introduction of your Virgil Circles & Demons The major mistakes that can be made The kind of people you will encounter during your journey How to deal with (some of) the difficulties Heaven? What you can do to finally reach Heaven 2
3. Matteo Bianchi Cloud Native Consultant & Contributor • Advocating for Cloud Native tech • Organizing Cloud Native events in the Netherlands • Kubernetes v1.31 release team member Former startup CTO Former Lead DevOps/SRE Former Software Engineer Fun facts about me • I used to live in Ravenna • I’m a metal singer • I deeply hated literature until reading the Divine Comedy @mbianchidev 3
4. Disclaimer Some references to the Divine Comedy could be inaccurate for the purpose of better comparison with Platform Engineering. — “Lasciate ogne speranza, voi ch'intrate” — “All hope abandon ye who enter here” 4
5. Disclaimer II Whenever I say “users” or “customers” I mean developers. 5
6. Disclaimer III Which is actually just a big TLDR; You already have a platform. You just don’t treat it like one, yet. 6
7. You, a DevOps Platform Engineering Developer Experience Security Compliance 7
8. What is this Platform? 8
9. An Internal Developer Platform (IDP) is composed of many different techs and tools, integrated. Its aim is lowering cognitive load on developers and enabling self service, without giving up control, security and compliance. - It’s an internal product, built and maintained for the developers, with the developers. — Ideally speaking, source: internaldeveloperplatform.org “ 9
11. Inferno Each circle represents a different sin, adding a layer of agony and despair for both Developers and DevOps people. We will venture through poorly designed platforms, chaotic labyrinth of configurations, operational bottlenecks and vulnerabilities. Trapped in a nightmare of misaligned priorities between business requirements and developer needs. Are you ready to count your sins? 11 we are here we don’t want to end up here
12. I - Limbo This place is inhabited by legacy developers whom we can’t blame for missing out on Platform Engineering. At the same time we have an eternal discussion going on between the other guests of this circle. Build vs Buy (vs Adopt vs Integrate) Developers discussing this dilemma are doomed. Here to stay, until the dice reads 5 or 8. Buy Build Adopt Integrate 12
13. I - Limbo What if I told you that this is a false choice? There’s no such dichotomy. The purpose of a platform is not to be a greenfield amusement park for you developers A platform enables your team to focus on your core business, increase the output and decrease time lost on undifferentiated and repetitive tasks. Ask your developer what they need, observe where they spend most of their time and act. Business Requirements Platform Engineer A dev ignoring them 13
14. II - Lust Excessive focus on extravagant and advanced features at the expense of core functionality. A vortex of cutting-edge tools, elaborate architectures and over complicated components, difficult and costly to maintain and scale. Particularly true when building more than buying because bought features are immediately expensive, while building them comes up with the bill much later. Every single tool ever You 14
15. II - Lust The goal of a platform is to be simple, reliable and efficient. In order to achieve these, a platform has to start with the Thinnest Viable Platform (TVP) “the smallest set of APIs, documentation, and tools needed to accelerate the teams developing modern software services and systems.” [1]; In short, a platform is whatever your team needs to go fast(er). [1] github.com/TeamTopologies/Thinnest-Viable-Platform A simple platform Developers 15
16. III - Gluttony There is an insatiable appetite for integrating the largest amount of tools and services, without a rationale. Leaving developers (your customers) with an overwhelming array of options to choose from. This leads to an excessive amount of time, budget and resources spent for both building such integrations and creating any standard. 16
17. III - Gluttony To avoid tool sprawling a Platform Engineer should act like Cerberus, actively gatekeeping developers from having too many options. This helps to create a platform where performance, usability, and DevEx are satisfying. Finding a trade-off with your developers, when evaluating both legacy and new tools is key. A literal gatekeeper 17
18. IV - Greed Filled with an insatiable desire for control and dominance over the platform, Platform Engineers end up moving around maintenance burdens over and over, reinventing the wheel with each iteration. Here we also find the turn-key dreamers that bought a platform thinking it would magically solve their team topology issues. Duplicated efforts, increased complexity and lack of control, compromising the platform effectiveness and long term sustainability. Platform Engineers RBAC Auth Identity SSL 18
19. IV - Greed To avoid such mistakes we need to define golden paths or the fastest way for a developer’s code to reach production. Golden paths include templates for various components, starting from repositories to infrastructure pipelines and anything in between. The key is to eliminate unnecessary choices* and diminish the complexity budget. *That can still be treated as edge cases if needed 19 Developer choosing GitOps tooling Platform implementing ArgoCD only
20. V - Wrath Internal friction and competition will be devastating for the platform, dooming its destiny. Building it while trying to get adoption, avoiding competing implementations, migrating from A to B, lack of support after adoption, poor onboarding and no enabling team, scarce to no documentation, missing API interfaces, zero ownership, lack of product definition and no roadmap. In a word: platform decay [2]. [2] Syntasso’s blog on platform decay *yes, I know that’s not a POV. 20 *POV: pipeline migration
21. V - Wrath To minimize friction we can follow these steps: • start with small and value-driven steps - what is the most time consuming activity for my dev team? Who is my pilot team/product? • avoid all-in-one automagic and big bang releases - what is the minimal set of features to increase my platform value for the next version? • survey users after each (major) iteration • keep day-2 in mind to drive adoption • define simple and future-proof API interfaces 21
22. VI - Heresy Platform Engineering is seen as heretic by management and rightfully so. In this wicked place there is little to no mention to ROI (Return on Investment) nor any metric to measure the impact of the platform. Budget spending is unjustified in the eye of the finance or FinOps team. 22 CFO Sales CRO CEO Vice Presidents & directors Platform Engineer
23. VI - Heresy As we experienced before, communication is key and so is aligning the platform goals with business objectives (OKR). Measuring against some form benchmark is a fundamental step to understand the entity of performance improvements brought by the platform. We could leverage the DORA metrics and survey the developers’ satisfaction periodically. 23 Metrics
24. VII - Violence Developers against your platform are equally dangerous. This circles are filled with “but we've always done it this way” developers and “won’t that platform steal my job?” DevOps. You have to fight resistance within your teams and convince them that this platform is only going to be good if they buy (and help build) it! 24 Developers Platform Engineers DevOps
25. VII - Fraud Don’t we all know this schema? Don’t we use it all the time to define SDLC or even DevOps processes? Whoever ended up here kept lying about how developing software works and now, after having experienced it, we finally know it. Let’s see what reality looks like. 25
27. VII - Treachery Here developers trust has been betrayed, they were promised a working platform but instead they got a labyrinth of tools, not integrated, unused, slowly decaying. Here lie all the ones who failed to find the Platform Market Fit and their entire platform teams are doomed. There is a way out of this maze. 27
30. TLDR; • It’s all about company culture and people, you cannot enforce Platform Engineering top-down; • Buy if your platform need is already well solved, try different platforms but remember that agnostic and open-source diminishes lock-in; • Build if you can afford the time, effort and long-term maintenance opportunity cost; • Always measure your platform effectiveness against metrics tailored on business objectives; • Start small, solve a problem for your developers that shows the business value of your Platform; • Platforms have to find their own market fit, in a market (your company) that requires a way different GTM strategy involving users to shape, define and contribute to the product they need. Your development teams are key to the PMF; 30
31. Resources • A Platform Engineering manifesto - https://github.com/mbianchidev/platform-engineering-manifesto • A work in progress Platform Engineering roadmap - https://github.com/mbianchidev/platform-engineering-roadmap • An illuminating post by Martin Fowler about platforms - https://martinfowler.com/articles/platform-prerequisites.html • This slide deck is public at https://speakerdeck.com/mbianchidev/platform-engineerings-inferno 31
32. This presentation was built with: Big thanks to: Jason, L, aura and William and William for reviewing the slides <3 Organizing team for having me on stage You, for attending this talk! for the presentation template for the photos CREDITS Pexels, Pixabay 32
33. Q&A time! @mbianchidev 33
35. This presentation template uses the following free fonts: You can find these fonts online too. TITLES: GERMANIA ONE HEADERS: GERMANIA ONE BODY COPY: GERMANIA ONE #C28549 #E0CABB #E5D5BC #303023 Use these design resources in your Canva Presentation. DON'T FORGET TO DELETE THIS PAGE BEFORE PRESENTING. RESOURCE PAGE Fonts Design Elements Colors 35