10 things we hate about platform engineering | Emma Dahl Jeppesen and Dan Grøndahl

Thank you for having us. Yeah, catchy title, right? 10 Things, Almost 10 Things We Hate About Platform Engineering. We thought that it was the best way for us to express our pet peeves, our continuous ranting, the hard-learned experience that we have learned in terms of the platform engineering world. And now, we often have to deal with short deadlines, right? And deadlines are important. So, sometimes we need to de-scope a bit to retain value. And that is what we did here - with the silent blessing from you, which is why it's called - Almost 10 Things That We Hate About Platform Engineering. I recently started at Velux - in a role as the platform owner for a lot of Kubernetes platforms. As Mark mentioned, I've previously been with Eficode as well. So, yeah, in that role, we try to build platforms for our colleagues, our developers, and that's kind of it. [Emma Jeppesen:] Yeah, so my name is Emma, and I'm the platform advocate for Velux. And what I do is that I drive adoption for the platform, and I do that by championing insights and discovery efforts on our platforms. So, kind of like an advocate and a product person in one, you might say. And yeah, this is our purpose at Velux. If you don't know, we make rooftop windows, probably the best in the world. That's at least what we say. But yeah, we transform spaces using daylight and fresh air. And then, when we started at Velux, we had a similar question. [Dan:] Yes. So, Windows needs Kubernetes. [audience chuckles] Of course, we know all that Kubernetes definitely does not need Windows, but that's for a different talk, right? But when we joined, it was like, do we run clusters inside our Windows? What is that? But the reason is, of course, because we are providing a platform, a Kubernetes platform, several of them, to the factories where we actually produce Windows and stuff like that. And we actually have a platform team on top of us that runs an industrial IoT platform. And then, we also provide the platform for, as I mentioned, our developers in order for them to build web shops, to help the installers of the rooftop windows to make that happen. And just to get us on the same page, what is a platform? I love this quote from Evan Bottcher from Thoughtworks. He mentioned that there are some keywords here - that it's actually self-service. That is something where the developers can do whatever they need without us as a platform team interacting with it. We have product as a main term here. We actually need to have product thinking in terms of what we do as a platform. And it's optional for developers to use. We don't mandate that our developers use the platform that we provide. So, golden path instead of golden cages. And we actually also strive for making reduced coordination - that we don't necessarily need to be involved in whatever that we do in terms of this. [Emma:] Yeah, and so just to get everyone on the same page, because I think a lot of us come from the DevOps world. That's at least what I did before. And so, this new thing called platform engineering, what is it really, right? I like to look at this white paper, is what they call it, from the Platforms Working Group at the Cloud Native Computing Foundation. They've been really nice doing this work of defining it for us so we all know what it is. And the thing is, we all know these capabilities, right? We've worked with these for a long time doing DevOps. But the new thing here is the platform interfaces that you see on top. This is what the product and application teams kind of engage with. And it's what kind of hides the complexity that sometimes is within these capabilities that you see underneath. And so, we try to make things more user-friendly. And maybe you've been working in a DevOps team before, and maybe you're now a platform engineer. Maybe you've been rebranded because some visionary leader came and said, 'Hmm, platform engineering is the new shit, right?' So, of engineers with all kinds of different needs, it's just not viable, in my opinion, at least. You need to know what's your value stream. Who are you serving? And also, similarly, who are you not serving? I've had these before. I know a lot of you had these. The snowflake developers, right? The ones that have that really, really, really specific need that no one else has. And you're struggling, struggling to get them onto the Kubernetes path. And that's why I kind of see them as the hobbits. You know, the hobbits there in the Shire, content in their own world, resisting the journey into cloud native territory. But just as the hobbits didn't seek out the wars of Middle-earth by themselves, right, you don't need to force these snowflake developers onto your platform as if you're Gandalf. After all, not every team is meant to be part of the epic quest for cloud native perfection. Let them remain in their comfort zone. Let them remain in the Shire, right? And either at some point they'll venture out on their own, or the business will send another fellowship to address their very unique needs. So, that's it for the movie references. And so, I think we need to finish up with something here then. We love platform engineering. Of course we do. We think it's the best way forward. We think it's way better than what we've been doing before. If you do it right and listen, it's like really new. We're all doing the same mistakes. We're all doing the pitfalls. And that's why we've been ranting about them here on stage. So, hopefully, you can see yourself in some of them and maybe not do the same as we've done. So, really come speak to us in the hall afterwards if you want to talk more about these common pitfalls or maybe if you just recognise some of the things that we've been talking about here on stage. And I think what's left to say now, Dan, is - thank you all for listening. - [Dan:] Thank you so much for coming.