PurePerformance - An Inside Look into Platform Engineering for Architects with the authors Max, Hilliary & Andi

Episode Date: March 17, 2025

In the ever-changing IT world, it's hard to create content that stays relevant for long. One of the objectives of "Platform Engineering for Architects: Crafting Modern Platforms as a Product" was to stay timeless by providing practical examples of use cases that are not necessarily tied to current technology trends.The book focuses on the importance of building a platform with a purpose, making the impact measurable and making sure the platform continuous evolves by continuously including the end users (the engineering teams) in the evolution of the platform.Tune in to this episode and hear from Max Körbächer (Founder of Liquid Reply), Hilliary Lipsig (Senior Principal SRE at RedHat) and Andi Grabner (Co-Host of PurePerformance) on what made them write a book on Platform Engineering and get some personal insights into what gets the authors excited about their respective topics.If you have a chance meet Max, Hilliary and Andi at KubeCon in London. They will present at Platform Engineering Day and will also do a book signing at KubeCrawl!Links we discussed:Book on Amazon: https://www.amazon.com/Platform-Engineering-Architects-Crafting-platforms-ebook/dp/B0DH5DJFTHPlatform Engineering Day Session: https://colocatedeventseu2025.sched.com/event/1u5mX/platform-engineering-for-architects-crafting-platforms-as-a-product-max-korbacher-liquid-reply-hilliary-lipsig-red-hatHilliary Lipsig: https://www.linkedin.com/in/hilliary-lipsig-a5935245/Max Körbächer: https://www.linkedin.com/in/maxkoerbaecher/Andi Grabner: https://www.linkedin.com/in/grabnerandi/

It's time for Pure Performance! Get your stopwatches ready! It's time for Pure Performance with Andy Grabner and Brian Wilson. Hello everybody and welcome to another episode of Pure Performance. My name is Brian Wilson and today I have three very special guests. You might notice that I did not announce Andy as my co-host today because while he's still a co-host today, he's technically part of the guest setup and I'm sure he'll still be asking all the questions anyway as he always does because today Well, we're here to talk about a fantastic book that Andy and Max and Hillary who will be introducing soon Just wrote and why they didn't just write it like this morning

But you know while ago spent a lot of time on it. And as you can tell, I do a great job introducing people. So without further ado, Andy, how are you doing today? Mr. Guest and co-host, Two Hat Man. Well, thank you so much, Brian, for having us today. I know you are the superstar podcast, as you just told us. And congratulations to your tickets. That you are for tickets.

Oh, thank you. Yeah. Which show are you going to see? Neil Young. Neil Young. So congratulations. Thank you. You proved to the system that you tried to get into that you're not a robot.

Oh my gosh, yeah. Did you actually read our book? Yeah. Terrible. Did you actually read our book? Because I remember back in November, I gave you a copy. I skimmed through some pieces and I was reading some of the other bits. It's quite in-depth and yeah I'll just start making excuses. But I did, you know what, it's hard because I did have a goal. Like last week I was waiting for my daughter, she was in some tutoring thing and I was like,

you know what, I'm not going to have time to read the whole book, but let me at least read the summaries of each chapter. Because I'm like, that's probably what all these talk show hosts do at night, right? They'll someone read the summary and like, oh yeah, I read the book. And time got away for me, plus it's kind of really hard living in the United States right now and there's a lot of distractions. And so, I think I'm going to chalk it up to a little bit of laziness, some forgetfulness, but also a little bit of like, I just needed to spend free time not thinking. But I did look at some of it. I was reading, I read the first chapter and I'm really actually interested in, and I'm sure we'll cover it later, but I do, you know Andy, my obsession with platform engineering has been Cloud Foundry, right? as it went moved from Kubernetes and then more optional guardrails to Kubernetes and then platform engineering. I'm like, this all sounds very familiar. Like we've been down this road before. And there was an interesting piece in there. And maybe we talk about it and we have to introduce people, but I want to just set it up now. There was a really interesting piece about there

about adding another abstraction layer, which is again, what Cloud Foundry was doing. But then there was also some talk about opinionated versus not opinionated and all that, which always, you know, again, this is going back in time. So I am interested in diving into that part of it for sure. But I'm sure you have a lot you want to talk about with our guests, which maybe you should introduce now. Yeah, exactly. And I think the first chapter was actually written by the person

that actually came up with the idea and then pulled Hilary and myself in. Max, Max quickly, maybe a quick round of introduction before we then also let Hilary say who she is. But Max, you first. Hi, I'm Max. I'm the founder and managing director of Liquid Reply. of what we have seen in the last years more technical part and more and more traction and piece of paper and writing stuff and putting thoughts on wherever we can put black ink. Max, you are also leading the Cloud Native Munich chapter. You host Cloud Native Munich in, I think,

July, correct? July 21st and 22nd. It's the first time that we have the now called Cloud Native Summit. Formerly it was KCD. Also very hot planning phase right now, looking for more speakers, more sponsors to get the baby up and running. So folks, if you listen to this and you are in the central DACH region, so Munich surroundings, and you would like to present at the Cloud Native Summit in Munich. CFPs are open and also sponsorships are open.

Which now brings me to the best guest in the end, especially with the best background, the best setup, I think, that we ever had in our podcast. Hilary. Hi, thanks for joining. Thank you for having me. Well, thank you for having me back, I should say. Yeah, it's great to see you again.

Oh, yes. So good to see you again, Brian. Like it was yesterday. So, yeah, so I am Hilary, as Andy said. I am a Senior as Andy said. I am a senior principal site reliability engineer at Red Hat. And I also co-host the Red Hat livestream

get-offs guide to the galaxy, where we get to be professional nerds and learn things professionally. It's my joy. And, you know, when Andy reached out to me and said, hey, my colleague Max is talking about this book. We think that your skill set would make a good addition to our author group.

Are you interested? I was like, yes, please, Kate, thanks, bye. Could not have been more honored or more delighted to have been invited on. And it was, I thought a really great meaning of the minds. As Brian, like you mentioned, like platform engineering, haven't we done this before? Haven't we been here before, right? I think Andy, Max and I kind of all discussed that

during our planning phase that we had in Paris at KubeCon there. And so yeah, we definitely do reference it in the book. Like this seems like familiar waters a little bit. And it's definitely some stuff that I spent time on in past roles and it's things that I spend time on in current role. And for reference, in case people want to go back in history,

back in history sounds a little long, but back in history. Back in our podcast history, it was the episode that aired on May 16, 2022. And the episode, Hillary with you, was called, Why SREs are not your new SysAdmins. Ed Redhead had a lot of great lessons learned. And also maybe Brian, for you and myself, sometimes a good reminder of which episodes we have already done over the many, many years. Yeah.

I just want to comment really quickly, Hilary, on something you said about, like, oh, is this new ground or have we been here before? And I think we see that a lot in tech where new ideas come out and the world's not ready for them. And then what happens is, as we've seen with platform engineering, they incubate and when they re-emerge, kind of like the, we'll call platform engineering the cicadas of the world, when they re-emerge 17 years later, it's ready for prime time, right? The market's ready for it and technologists are ready for it. This is when it can really make a splash and that's what I think we're seeing at this time. I think although, yeah, people who are listening to this are going to think, this sounds familiar. Yeah, it does, but it's been fully thought out and really refined and it's ready for

it. We see a lot of people already doing this stuff, right? but it's been fully thought out and really refined and it's ready for and we see a lot of people already doing this stuff right it's not like only the unicorns are doing this now it's it's it's getting everywhere so and maybe that's actually good a good way to a promote a couple of things that the three of us will be doing in about two weeks after this airs so whoever is going to go to London KubeCon is coming up there will be some book in about two weeks after this airs. So whoever is going to go to London, KubeCon is coming up. There will be some book signings again at the KubeCrawl, I think it's called,

on Wednesday evening, I believe. So find us at the Dynatrace booth. Thanks Dynatrace for sponsoring a couple of books. We will make sure to prepare our hands in writing because we will sign the books. But more exciting is on the platform engineering day, which is on Tuesday at the co-located events, both Hillary and Max, you're going to talk about the book and lessons learned. Maybe that's a good way to actually pitch a little bit on why the book was written and what people are going to hear when they come to KubeCon in your session.

Absolutely. So, well, initially it was not the idea to call it platform engineering for architects. It was a beautiful subtitle, crafting modern platforms as a product. It was more like a collection of thoughts. The first thoughts about writing about the book was two and a half years old, not much experience. I'm a Kubernetes engineer, I do a lot of other stuff. And that's the same way how for me this topic emerged.

My team did in the past a lot of Kubernetes, and we were always like the Kubernetes people, but we did more than Kubernetes. understanding what developers need felt mature enough to really give some deeper meaning about it. And that has changed over the time. And we saw already a good amount of talks, a good amount of other books, blog posts around how to implement platforms, how to do the automation, how everything comes together. While we were working on the book and trying to shape a little bit more of the content,

we came up with, hey, it should be a little bit more timeless. The book is still good to take into your hand in two, three, four years. Maybe there are a few technical snippets in it that might be outdated, but the majority of the book is still readable and it's not that much outdated. And I think that was the underlying tone which we want to give to the book, that this is really like going through the time and can follow along with people. And while a lot of jobs and technologies are changing, for example, along with people. and come to the point of writing a book, problem. Yeah, it's cool that we got all this feedback and also thanks, I think we should also thank

PECT, our publisher, for also making this possible. And all our reviewers. And the reviewers, yeah, exactly. Yeah, the reviewers have been really awesome. I mean, during the writing process, we had the people who are credited in the book as volunteering as technical reviewers, specifically like getting early drafts. And those people were great. And they gave some really good constructive feedback. They caught little mistakes. You know, that definitely helped. And then, you know, the people who have since, you know, not only read the book, but taken the time to leave

us a review and tell us, you know, what they liked, what they didn't like, what they want to see in the next in the next go around. It really is very meaningful for people to take the time and let us know like what they thought and what they valued. It does. It really is kind of makes it worth it. Hillary, I remember in the in the early days of the book, in the early days again, such a strange thing to say. But when we were sitting down and we said, wow, how can we write so much content? But then you were the one that said, damn, I need so much more, so many more pages to

because I have so many thoughts that I have on the topic. I think you were specifically bringing in your focus on security, right? That was a big topic for you. And I guess you could probably write a whole book on that. Yeah. Yeah. Chapter seven was a struggle. So initially we were not going to have cybersecurity beyond a little hand wave towards it because it really is its own many

books worth of topics. And Pat was like, you guys have to have security in here. And we're like, okay. And I really struggled with that because, you know, there was kind of a page target that we needed to hit and it was like Okay, that's too many pages for a hand wave and too few pages for a deep dive because this is a really vast space and so I Ended up approaching it from what is the primer? I wish I had had coming into my role, right? What is the collection of information that would have made my life a little bit easier? And so that was what I did. And I forget how many pages that chapter ended up being, but the outline by itself was half

the page count. That outline was gargantuan. I was like still like trimming it down and tightening up thoughts. I was still really worried that I was going to go way over or that it was going to be too dry to get through. I was going to put people to sleep. That was very challenging. I spent the most time writing that chapter because it was very challenging to even approach it. I also think there was one important piece in the very beginning and I think we got some good feedback on that as well.

While platform engineering is obviously the topic that a lot of people talk about, not everybody must build a platform. I think Max, this is also something that you had in your early chapters, really making the decision, do we need to build our own platform? Yes or no? And could you maybe talk a little bit about this? Because I think essentially this decision in the very beginning is very critical to not walk down the wrong path. Absolutely. I mean, the thoughts around this comes already from even one step further where walk down the wrong path. Nowadays, everything is a platform. is not always the right way to spend your time, your effort, bring a team to the point

to understand how it needs to be done. Sometimes from like, hey, we are, for example, a young startup and we just want to get a product out there and we have a really, really hard time and budget cut. So maybe I don't need to spend more time for that. Or if you're a large enterprise and you're heavily fragmented in different IT areas that absolutely do not want to speak with each other, and I think that's more common than it should be, then it also doesn't make sense to maybe spend that much time at that point into building a platform increase transparency, visibility, stuff like that,

then it's maybe a good thing to start with. But overall, and we have covered a couple of pages in that, we really should ask tons of questions before we go into this direction to build a platform. I also had, I remember in the early days when we were sitting, I think Hilary you mentioned we started the whole thing at KubeCon in Paris about a year ago, I think it was March. And it's amazing how what has happened in a year. But we sat down and we talked about when we are building platforms, we want to first understand what is the real thing that the platform, what's the real problem that a platform should solve, right? When we are building platforms,

you want to first understand what's the real problem that a platform should solve. Does the platform make it easier for engineers to configure certain environments, to stand up new environments, to create new artifacts, to create new software that then gets deployed, that gets automatically security checked. So we try to really figure out what is the thing that the platform should do. And also, instead of boiling the ocean, trying to figure out when you start what is also the thinnest viable platform. And with this we borrowed a little bit the concept of the MVP, the Minimum Viable Product. For me, it was a big eye-opener that we talked a lot about

basic product management ideas and principles, right? Because in the end, we are building an internal platform which is basically just a software product to end users. And most of these end users, they will be internal, but in the end, we're building certain features. And in order to build the features, we need to figure out what features to our end users we need in order to solve the problems. And so first we need to understand which problems we actually need to solve.

And I thought that was a really interesting thought experiment, and I guess this also is why we also have the subline, the sub-take line of the book, crafting modern platforms as a product, because in the end we're building a product. And bring this awareness that the platform needs to serve a kind of purpose. So if there is no purpose for a platform, purpose. And you change the mindset of the team, you change the perspective of the team members that they are working on a product that is sustainable in a way, it sustains itself over a longer time period,

and it's not vanished or management will not take away people and budget after a certain amount of time. after a certain amount of time. Then this platform is a very good ground base to keep evolving and keep being modernized. But I think what's also important is that you do not overload it with features. I think that's a very typical behavior if you have a product that at some point in time you're feature rich in an organization. Yeah, and I think on that, when we discuss, part of that is meeting your users where they are. I think I gave the example,

like if you integrate a pipeline technology and people are not adopting it, because everything they're already needing is handled for them by GitHub workflows, then it's time to ditch the pipeline from the product. And instead of trying to force people to migrate, make that integrate with what the rest of the product does, or the rest of the platform does.

Product, same thing here, right? So meeting folks where they are was, I think, really one of the things that we wanted to make clear because it enables them to do things like self-service aspects of the platform. It enables them to have just less mental overload. It's one less thing, one less barrier between them and the adoption of the platform. And I think that that was what I think we kind of had the entire chapter six on that, right? I was that was really about that. But we talked about it in a few places,

because it's really key that a platform is built in service of the users, it's not seeking the shiniest thing, not seeking to emulate some perfect model that you heard about at some other company It needs to be for the people who actually have to use it It's a really interesting point. I was just gonna say because even in Whenever You know learning about different ideas in tech industry, right? Even if we go back to the idea of DevOps and then they had like, you know the the Toyota about different ideas in tech industry. And this point you made, I think is just an excellent point

no matter what you're doing. You know, I manage a team and there's all this, you know, paperwork and stuff around the team that they have to do. And I really love this idea, whether or not it's a platform, whether it's for anything of getting rid of the stuff that doesn't service their media goal and also removing the barriers. If it's something people don't want to use, don't find useful, like cut it out.

It's almost like getting rid of technical debt in your platform to make the platform successful. And I think constant looking, going back frequently and looking at and looking for those warnings is very important. But it's just the most important part. Oh, so you're at chapter nine then? Yes. No, it's interesting. And I was just flipping through here, and it is really interesting for people who obviously don't have the book yet, because they, you know, first edition sold out and now you're working on like the gold plate and second edition and now, didn't they launch this into space for other civilizations to

find? But the book really is, yes, the beginning it starts talking about concepts, but the book really is a blueprint for how to execute this and how to do this. It's not just a book talking about the benefits of platform engineering. And you could just, you know, someone stupid like me who's just glancing at the chapter titles, it's really heavy. It's really, really, really in depth on that side. So anyway, I sidetracked a little bit, but I did want to call out like how I think that is a really, really fascinating point,

just for everything in general, but especially for this kind of thing. Yeah, and I think we, I don't have to pick up my own book. I wrote chapter nine, you would think I would have it like cold, I don't. You called it choosing technical depth to unbreak platforms, and I wanted to actually make sure

that you can talk about this because this was a very big point for you that you wanted to make talking about the technical depth. And yeah, chapter nine. Yeah, chapter nine. I will say that Max came up with the title on this one. Yeah, read the whole thing. It's actually not that long of a chapter. But yeah, so I actually just kind of had, I quoted myself,

right? Because my sign off on my own podcast is choose your tech debt wisely, right? That's what I always tell people, choose your tech debt wisely. But so I just kind of give you like a little bit of like my, what I do when I'm assessing for technical debt, right? And it's just a couple of questions, right? What are you solving today? What problems do you not have yet? What will this cost us in time to build or adopt? What will this cost us to run? What is necessary to maintain it? What is our expected return? There's actually 11 questions. Can the team sustain it as is? That's really big because sometimes that answer is no, but they may be prepared to upskill

and they may have the time to upskill. That might be acceptable. And if part of that, sustaining it as is, is this as a piece of open source software? What does the community look like around that? Is it active? How does the team join that community? There's a couple aspects to as is that need to be taken into account.

What will it take for new team members to get up to speed? When will we know if it's time to scale? How will we scale? What are our deprecation criteria for this solution? And that last one is big because you do need to know when it's time to move on. Nothing's permanent in tech. So knowing what your deprecation criteria is, I think, is goes really hand in hand with understanding what your technical debt is. I've heard people say that technical debt

is from making the wrong decision, but I challenge that in this chapter because it's from making any decision, because nothing is perfect. It's the 80-20 rule. You're gonna maybe sacrifice that last 20% to get 80% of what you need. There's always going to be some trade-off

to what you've picked, and you're always gonna have things like critical vulnerabilities that need to be patched. And there's regular maintenance that needs to be done. So I challenge the notion that tech debt comes from choosing the wrong thing or what is the wrong thing in retrospect. Tech debt is a little bit of just the cost of doing business. So making it sustainable, it requires, it's like part of the software development lifecycle, right?

You continually need to evaluate, like take the data, make a decision. Talking about, because you just mentioned the word, make it sustainable, sustainable, sustainability, cost, max, chapter eight, I think is something very dear to your heart. sustainability, cost, max. Chapter eight, I think, is something very dear to your heart. The master transitions at work. Beautiful.

Well, I mean, if you unify the way how you manage your infrastructure again, very fragmented, very out of control. But no, it's just like usually you have like a history in crowing your environments and it gets costly over time. And also looking there again to a lot of enterprises, they are not there yet to really, really manage well their cloud infrastructure. So it's no wonder that you run out of costs. And I mean in this chapter, the idea is very, very simple. Just to give a few little tools on hand to early start thinking about the cost perspective. For example, with a simple tagging strategy, just prepare a little bit the future adjustments

which you can bring to your platform, to your environments. I recently talked with someone about the book who also has read this chapter. platform to your environments. the organization. if we are very precise, what we expect there, in the perspective of availability and stuff like that. But it's also sometimes very important to challenge how high available do you would like to have it? Sometimes maybe just a copy of a database is enough. don't need five read replicas distributed in 10 different countries and continents and whatsoever. Just because someone said we need it highly available, we might need to challenge that or

can achieve it in different ways. So also looking as an architect, for example, about changing also the architecture, which can have also cost impact in the end. We also discussed this during the writing process. And I think it came out more in the security chapter than the others. But challenging what data you're even storing, both from a security aspect but also from a cost aspect. Why are we storing this? What is the value of storing this? What is the value of storing it for What is the value of storing it for, you know,

the duration that we're storing it for? Why, you know, like kind of like really questioning, you know, that as an example, but really any piece. Like everything should be challenged at some point. But if you have just a ton of data being stored and you have no idea how to use it or what the use case is for it, you shouldn't have it. It's a liability. It's either a security liability or an expense

liability or both. But like, you know, that is a very easy thing. It's like, just, just I really do I really have only the data that I actually need and can use. And if you know, the answer to that is no, then that's an opportunity to save on cost and it reduces your surface, like your surface area for risk too. So yeah, that was one of the things that we discussed. That kind of was an idea that fit both is really why do we have the thing? Whether that thing is something you store, whether that thing is something you run, why do we have the thing? Can always thing is a question you can always ask. And that's actually also why we put in to have ADRs, right?

Architecture design records or reviews. I hear it both ways, by the way. So for our situation, we just went with records because that documents the why. And sometimes the why doesn't exist anymore, which means it's an okay thing to change Yeah, I think it's Just having a funny thought when you're talking about getting rid of all the stuff you don't need right? Have any of you ever tried going into your whatever email non-work email you use and just selecting a whole ton of your emails

that you've been holding onto for forever long and just hit delete. There's this intrinsic, and it's a great, I've done it one or two times maybe, and it's always scary because I'm like, I was saving that for something in case of the, it's like, no, I don't need it. All I would say is if you're scared about letting data go, go first to your Gmail account, Yahoo, whatever you're using, and select like 90% of your inbox and hit delete and see if anything bad happens. It's very freeing when you do it.

It's very freeing. But it's also like nothing happened. Like, oh, okay. Yeah. The world is not ending if you get rid of that. That receipt from 10 years ago. The world is not ending if you get rid of that. This also circles back to what we said earlier, letting go of things. When you build a platform and you're building capabilities into the platform, you want to

make sure that you only keep those things that are actually delivering value. I think Max, you had, we also talked, I think it was in chapter two, I have it in front of me. We talked about relevant KPIs to actually monitor the adoption of a platform because in the end, if your organization makes a strategic investment in letting a team build an internal platform, then you want to obviously make sure that you are investing this money and time wisely and that you can also sure that you are investing this money and time wisely and that you can also prove that you have an impact, but it also means you need to get rid of things that don't have an impact.

I think that was also, we covered this with KPIs and observing the platform and making it successful. Yeah. And also you have to do two different perspectives. So you can measure the acceptance of a platform and how efficient it becomes have to do two different perspectives. that are around it. That you have difficulties even maybe to measure and where you have to come freely up with it, because it also depends on different organizations. There's a couple of examples out there where I think on the one hand side you have Spotify, then you have Expedia and Toyota, which all talk about their success stories, the next company is completely just about money. And it's like, hey, we saved five million here,

and we saved 250,000 there. And the last company is more like, suddenly all of our developers frequently use the documentation and access it, but we also try to put into that chapter to say, look, there's a couple of standard frameworks around KPIs, but there's also that you have to define what makes sense for you. Not everything of it makes directly sense for your organization. Maybe you are already very cost-efficient because you have some cost management, aware of it. of people who would utilize a platform, including non-technical personas, right?

Lots of people use Git for their docs. And so you have docs writers who are doing everything in Markdown, right? And so you could have them as users as a platform, which means that they would have different KPIs, right? Different standard of what is successful with it and what is a good interaction. And they would have a different use case. They would have a different golden path, right? Different standard of what is successful with it and what is a good interaction. And they would have a different use case.

They would have a different golden path, right? They're not gonna hit as much of the platform or care about as much of the platform as maybe somebody else, like an application engineer would, right? So, we talked a little about that. I don't remember if we talked about, like, the way a platform can provide visibility into, like, the goings on in a way that, like, people like product managers and so forth can track. I think it was something

we kind of discussed when we were talking about writing. I don't remember that making it into the book. But transparency is another type of thing that a platform can add. Like, where is this released? Well, you can actually follow it through the platform, right? So when Max is like, you know, KPIs need to be about your company, it just needs to be about the who, right? Is it only one type of person or is it a couple different types of people? Yeah, we actually talked about that, the end-to-end traceability of artifacts through the lifecycle,

we call it the STLC observability. This is the whole chapter around where we introduced continuous integration delivery, where we talked about GitOps. Oh yes, we did put it in. Good job, us. Well done. And then one thing that I think was also a good decision in the end, in Chapter 3, in the very beginning, we introduced our fictitious company.

So we came up with a company where we explained what this company is, who they are, where they came from, and what they want to achieve. And we always try to relate everything we then explained in the book back to that company because most readers will probably be in an existing environment. They have to deal with an existing situation and therefore we try to give them a reference point on what would, in our case, it was called financial one, ECME, right? What would they do?

Because they have a certain legacy, they have a certain existing processes, they have certain roles in their organization. How would a platform benefit them? Yeah, that one was really important for me to keep my chapters on track. I was like, what am I grounding this to? And I ended up kind of coming up with it to help me with chapter six, which was the first one completed, ironically. So I had no idea writing chapter six, what the first five chapters were going to be. And

so that was something that I did for me. And then we decided to incorporate into the book. Chapter one to five appear out of magic dust. Hey Andy, what chapter did you write? Which chapters did I write? That's a good question. I think they allowed me to write two. I think it was chapter three and it was chapter five and I helped a little bit in two other chapters.

You helped in one of mine too. You went and added the crossplane example. Oh yeah, that's right. One of the chapters, I think it went up in chapter six. Or maybe it was chapter seven. One of those has a crossplane example about only deploying apps to North America. I don't remember which one, but Andy went and added the technical example there. And there was a few other places. Andy had his hand all over the place. He was our consultant. Of course. And Andy was, I bet you, can I make a wild guess and wonder if Andy wrote all the summaries for every chapter? Because Andy, if you all haven't noticed, Andy's a great summarizer,

at least on the podcast. He did not. Nope. He couldn't rely on the skill. Next book. If I had known, I would have made him write all of my summaries for me. You told me too late. Hey Andy, I have an odd question here. Go ahead. And we just had a feline join the podcast. Oh yeah, you guys can't see her.

Yeah, that was last time too I think. You guys can see her. By the way, I looked up the picture. I looked up the picture from the old one and you had Rogue One in the background and I totally remember that bit. I remember a conversation about Rogue One. Oh, that's right. I did have the big Rogue One poster hanging out here at that time. Anyway, that covers me. Andy, it's been a while since we talked about Captain, right? And I know Captain had quite a few things that he was trying to do. For our listeners who may have been back around, still with us, who every time you'd say, Captain, we had to take a drink, was Captain basically a platform or was it less than a

platform? Was it a little bit, I mean, at least the goal of it? Yeah, yeah. No, Captain brought in a couple of capabilities that you needed in a platform like this. And by the way, we obviously have Captain on page 69, 125, 184, 189, and three, or one. Is Captain still alive? Because you haven't mentioned it in a long time.

Of course he's Captain still alive. Okay, you haven't mentioned it in a long time, so. Yeah, yeah, no, no, but no, Captain provides some of these, what Hilary mentioned earlier, these observability aspects of artifacts that are being pushed through a platform. Captain was providing observability into deployments on Kubernetes and then we also had the quality gating with SLOs.

So these are some of the aspects that we also explain in the book. And we bring in some of the CNCF projects. Hilary mentioned crossplane earlier. So we talk about crossplane, we talk about Captain, we talk about backstage. that we also explain in the book. community that we see a lot out there being used in platforms that are built right now. So it's important that people understand too there's not a platform, engineering platform, that you go buy and download and use, right? It's an amalgamation of different components that build the whole. But I think that's obviously from what you're saying, Hilary, you were going to say something there.

I didn't want to lose that thought. Yeah. And it actually follows your thought very well because we tried to be non-prescriptive. So when we brought in these CNCF technologies, we used them as examples, but we may have mentioned multiple of a similar type throughout the book. And that was a very intentional choice of being non-prescriptive about how you solve X problem or which tool you use to solve Y problem. There goes my cat being annoying. Anyway, yeah, there was a deliberate decision to be non-prescriptive about what the tooling looked like, because, again, it was an attempt to be timeless. That was really important. So we mentioned a lot,

and we mentioned some that do similar things, all to show you, kind of showcase the options versus tell you what to do. Right. And it follows the same, right? It's like we have talked about a lot of perspectives and how you what to do. by having a kind of capability map, and loose ends. So I think the important thing to learn here is that for the people who go out and say, we're going to build everything on serverless because we want it all on serverless, and we know that's never a good thing to do, don't just pick tools like we've been saying over and over again. If you're going to be building a platform, as you all are hinting at here,

look into the different tools that you can plug into the platform to make sure it's going to fit what your outcome is that you want to be. Don't just grab what's there. Understand what you're going to pick, because otherwise you're going to make the mistakes that we see countless people who say, I'm going to take my monolithic applications and lift them, shift them to Kubernetes as is. Like, what are you doing? Right, it's not gonna work. So I could just beg people, please, please, please, look into what these things do and what the pros and cons

of each are before you use them. Because that's one of my pet peeves. We come across people like, yeah, we just want to be all serverless. Okay, why? Because it's cool. Okay. We're not one of those. Because we don't see admins. Yeah, but we don't want to bash on serverless because- No, I'm not bashing on serverless.

It's the reason. Serverless has very good use cases. Everything has great use cases. That's also what Max you said earlier. The book is heavily focused on CNCF and Kubernetes as a core platform. All the concepts we explain, they can be applied independently of the technology. You just need to pick the technology that makes sense for you, for the use cases and also for the technical skills you have in your organization. That's important.

Good. I would say, um, Q con coming back and remind remain reminding people if they are at, uh, if they come to London for Q con Tuesday is your talk around, uh, platform engineering for architects. Um, max, what's the, what's the, uh, the time I think it's in the afternoon, early afternoon, if I'm not mistaken. What bad timing. Yeah. We'll add the link to the description of the podcast. So folks, if you happen to be in London platform engineering day, that's a

co-located event on Tuesday, a great way to either give feedback in case you have read the book already, if you want to learn more. We're all going to be there, but Hilary and Max will be on stage. Wednesday afternoon or Wednesday evening at Cube Crawl, this is where the Expo area is open. I think there's like two hours of time in the Expo. We will all be at the Dino Trace booth to hand out books and signed books. And there might be even more book handouts, if I'm not mistaken, Max, potentially, right? We are working on it.

We're working on it, yeah. It looks like there's a couple of opportunities to get some signings and books, maybe already on Tuesday, maybe some on Thursday. So practically all the time when you meet us, we will throw a book at you. Very, very important distinction there. Throw a book at you, not the book at you. No, I would never throw a baby. Do we have a book cannon to shoot the books at people to imagine that? We're going to use a book cannon for the ox Oxford English Dictionary I think that's like this big or something It's a soft so it's okay doesn't leave roses I

Really want to say thank you not all max for giving I think both of us the opportunity to Help you with this book. I know it was a big dream from you for a very long, long time. I know your story when you, I think we're still a kid in the school and teachers were telling you that you will never be able to write a book. But then years later, you are an art book author and I'm very happy to be part of the journey. It was my revenge. I still didn't find out the address of my past teacher. Maybe I just will send a couple of books to the book library.

Also, I'm not sure what all the teenagers should do with this book, but maybe I can convince someone to join IT. I was telling my cousin who is in a related field, but most of the book doesn't apply to him. I told him, I said, honestly, just read chapter seven. Chapter seven is pretty much good information for literally anybody, kind of regardless of what you actually do as a job. A lot of the information there is pretty useful in a general sense.

It's a life coaching chapter. It really is a life coaching chapter, yeah. I think congrats to all of you, right? I mean, writing a book in general and getting thoughts, especially deep technical thoughts out in a consumable way is hard to do in the first place, but I imagine you all did this while still working your other jobs. So a lot of your free time, spare time, going back and forth, revisions and editing.

You know, I have this idea of some sort of vampire story I want to write that I can't even create a story from it yet. I have a bunch of ideas but even the idea of trying to even write that, even thinking about writing it is just daunting, right? And I probably never will do it, but you all did it and you should really be proud of what you accomplished here. And especially, you know, one of the themes we've seen in the IT world since forever is the idea of giving back to the community and sharing what we've learned, sharing ideas.

And you, the three of you contributed to that in a major way, especially on this really important topic that's coming up more and more. So just real round of applause to you all, and be really proud of what you've done there. Thank you very much. But it just makes fun if you have two fantastic co-authors. And then it goes very smooth. I mean, the writing process was actually quite fast. much. But it just makes fun if you have two fantastic co-authors.

And then it goes very smooth. The writing process I think went very smooth. The thing is when you have three authors, everyone starts their first chapter and then suddenly you have 120 pages or so. So your one third of the book was in like, that's the actual fantastic thing. But also I believe it become very complex in the end of writing because then you continuously like, have I written about it? Did Andy wrote about it? Did Hilary mention it? Or maybe Hilary should mention it? But Hillary mention it? Or maybe Hillary should mention it? And then it's become very complicated. So in the end, it's a very, very demanding job of jumping

back and forth and double check and triple check if you not maybe accidentally talk about it somewhere else. Yeah, we did have to consolidate duplicates or string things in that concepts that somebody introduced in one chapter that didn't really exist anywhere else, just so that it didn't come out of complete left field. There were a few of those, and yeah, that was the hard part, especially because first chapters, I mean, we didn't write them in order. I think that's really the important thing, you know, we did not write these in order. So it ended up being a cohesive book, and that was really the latter half of the writing adventure.

But I think we spent, we got the whole thing done in under a year, which really was just us being up awake talking to each other at really strange hours. Like it'd be 1 a.m. my time, and I'm firing messages back and forth, and then it's 1 a.m. Max's time, and he's firing messages back and forth and then it's 1 a.m. max's time and he's firing messages back and forth and there was a lot of that. Yeah. Yeah I think we even did it, I mean if you just look at the writing we did it in under six months right because we got together in March in Paris and we had the final drop of date in August. in March in Paris and we had the final drop of dates in August. I think even less because until May we didn't start or so. April, well I was like the second week of April, yeah.

Hey, let me ask you really the question here, right? Because obviously you're all making it sound a lot easier than it sounds in my mind, but we might have listeners who have ideas. I mean, I always get, I always panic before I start anything. Um, but if we have listeners who are thinking about writing a book, right? Obviously you can write a book, but you have to get somebody to publish it and get stuff like that done. So whoever got that ball rolling, can you just give a quick description?

Like if someone's curious, like what are some first steps they should do to reach out to see if it would be topics somebody want to publish or support or anything like that? Oh, that's all Max. Go for it. It's actually easier than you might think. So the publishers are continuously looking for topics they can support a book in its creation. We wrote it with PACT and PACT is continuously reaching out to people who they believe are subject meta experts. They also have, I believe it's a Discord channel or whatsoever where you can go in and they throw ideas into the room like, hey, we have done the research, what about topic XYZ?

This is one part of the story. If you're convinced that your idea is good, you can reach out to any publisher who might fit your field. You could do your research a little bit. I don't want to say fictional books, because there are books like The Phoenix Project and what so ever, which have great ideas in it, but it's not like 500 pages of code written down. is maybe the wrong publisher and you could go with something else. But also here it's very much depends on the field.

Yeah, just look at the books that are similar and see who the publishers are and reach out and there's a good chance they're looking for good topics and if you can bring something to them, you might. And if you want to be successful, find out which publisher has written already a book about it and who not. Yeah. And tackle the publisher who haven't. Perfect, perfect.

And I see it's even available on Amazon. I see five reviews. One's by Andy, the other one is by Andreas, another one by Chant now. It's all five star reviews though. I will have a link to the book, obviously, for listeners if you want to get a copy. Remind them again. I know we mentioned at the beginning of the show if you wanted to get a signed copy. Where will that be happening?

The signed copy will be given out at CubeCon. That's one opportunity in London. I'm pretty sure throughout the year there will be other conferences and other opportunities where the three of us will present or will be present and then there will be opportunities to get a copy or a signature on a purchase copy. Both ways are good. And Max and I, by the time this airs we will have just finished our little tour through the Dach region. We will be in Vienna and in Munich the next two weeks. Also giving out some books. So I had to drink about what? Five sampler beers to get my signed copy from Andy.

So it's a very pleasurable experience. The real trick is getting all three signatures and collecting those like Pokemon, right? Yeah. That's actually, I'm going to have to travel to London. So for the last KubeCon in North America, where Diana Trace also generously sponsored a book citing, I actually mailed Andy labels with my signature, one for every book. So you stick it in there?

So yeah, so he lovingly applied my little label on all of them, but he doesn't have a bunch of spare sitting around, so if you're not at a KubeCon, you're gonna have to find me in the wild, I guess. I'm going to have to bring a guitar pick guard and then I'll sell a guitar with your signatures on them. Any final thoughts before we wrap up here? I do have a cut off, but Andy, anybody? No, I'm just happy that this worked out and also thanks for taking the time to come on our podcast today. And yeah, look, I'm going to see you in a couple of weeks.

Looking forward to it. All right, really appreciate it and really appreciate everything you've done for the community. Thanks, everybody. Until next episode, ciao. Ciao. Ciao. Ciao.

Ciao. Ciao. Ciao. Ciao. Ciao. Ciao. Ciao!