Platform Engineering: Asking 'Why?' with Evelyn Osman
Today, we had some long conversations about AWK, Bash, and the future of scripting, as well as platforms and the rise and fall of Kubernetes.
David:The fall of Kubernetes? I'll have Claude write a new one.
Laura:Of course, you will. I'm sure you were in the middle of telling Claude to do that during the recording, actually. Our guest, Evelyn Osmond, spoke recently at Cloud Native Munich about all kinds of good stuff, including whether everyone needs platforms and asking why. She also got into a long conversation with David on Blue Sky about AWK.
David:We decided that you need to be this old to know what AWK is. So if you're as old as us, you pass the test.
Laura:We also discussed why, like the question. Asking why is the most important skill you should have.
David:Like, are we using Kubernetes? Why are we paying for the cloud? And why are you listening to this?
Laura:That last one, maybe I don't have a good answer for. Enjoy the episode.
David:Welcome back to Cloud Native Compass. Today, we're joined by Evelyn. Evelyn is the head of platform, Lakeshawk, which is why we're here. I'll get into that more in a moment. But before we talk about fun command line shenanigans, platforms, operations, and anything else that grabs our interest throughout the session, could you please take a moment just to say hello to our audience and introduce yourself?
Evelyn:Yes. Thank you, David. Yeah. So as I said, I'm the head of platform, energy trade startup in Munich, Germany, called Anmac. So I've been there since last end of last year, working on variety of topics and like building up the internal platform, you know, basically platform engineering stuff, but I do a platform as a product.
Evelyn:So that is like, you know, everything we build has like users, functions, use cases that we support. I also kind the whole thing of like, we should be honest. And actually, some point, look back and beside that, actually, this is bad idea. We should do it over again, you know, always be honest, avoid that the graveyard as much as possible, so to speak. Yeah, and I guess, maybe some things I'm working on recently, I guess.
Evelyn:So I guess I'm diving more into like, sort of like release management is is one thing. Another one is sort of like, you know, like data architectures, how to improve those make them more reliable, but that's sort of more like, you know, bringing in best practices. Yeah, and I guess the other thing, I've been working really high for a very long time. So I'm actually thankfully finally getting back to actually writing code, which I'm very happy about. Avoiding Vibe coding as much as I can.
Evelyn:Sorry if I brought it up, but I I don't I don't use it. I just don't.
Laura:As David looks off screen at his coding Yeah. Agent Very nice. Well, good.
David:Alright. Now let's not start the podcast by dating you, but we we started talking, and this podcast came together because I was talking about Auck and how powerful it is. And I feel like in today's day and age, and I said, like, an old manual in that cloud already. Right? Not a lot of people are really playing with ARC and SED and even Regex to some degree.
David:It seems to be people that have been doing this for a while that are familiar with these tools because at one point, that's pretty much all we had. So I'm assuming you've been doing this a while. You've used ARC. You like ARC. You're probably a tanker and a scriptwriter.
David:So maybe you can give us a bit more history on you with regards to these tools and what you've up to over the however many years you've been doing this.
Evelyn:Yeah, so I actually started working in tech in like 02/1977, when I need to pay the bills, you know, at least like, you know, like good old American, you know, college, you got to work your way through it to pay tuition. And so I just was like, you know, basically worked a lot of different jobs, like desktop support, help desk, actually at one point I was running, I was managing a data center, like a lot of different things. And so as a result, you know, I was doing a lot of, know, like basically sitting in a console a lot of the time. And with with octave psyche, actually, at the time I was working for a company that did a lot of like, you know, data streaming, get it data analytics. And so we had just these like, I think at the time it was it was Cloudera, or an important works.
Evelyn:So it's both of those, you know, like Hadoop clusters. And we were like basically working in a demo. And one of the things was basically like, okay, we actually want to just basically like consume, you know, all the access logs from Wikipedia every day, and we're gonna do some manipulation on it, some transformation. And then we're just going to dump it into Hadoop and do some analytics for some nice, for some pretty dashboards with heat maps and NLP and all that crap. And I ended up writing everything in Ock.
Evelyn:I don't even know why I just why I did it. It was at first was like, okay, I need to start parsing things. Okay, now I did parse. Okay, I got to iterate through it. And I like, can I do this on Ock?
Evelyn:And the next thing I know, I have like a 200 line script.
Laura:I love it.
David:I mean, there's gonna be people listening that just think, what? You can write Auck scripts. It's not just print dollar 1, etcetera, or, you know, field separators or something. But yeah, it's it's so powerful.
Evelyn:Yeah. Like, I do a lot of conditionals usually when I'm using Auck and stuff for like yeah. And and it's it's something interesting because I I kinda saw he kind of mentioned, like, you know, angry man yelling at cloud and stuff. But I kind of observed this, like, the years, it's like, you know, cloud became a thing. I always say like, I was like, when my company for my team, like three people sat down, she used AWS.
Evelyn:And I was like, No, we should not has all these IO performance issues, super inconsistent. We do like data analytics, it's a terrible decision. Two years later, I was designing like an architecture for one of our platforms. So you kind of saw how that went. But I kind of started seeing like people like like learning, like understanding less and less about what was happening behind the scenes.
Evelyn:And first it was like, you know, like, architecture infrastructure, you know, okay, I'm creating a VPC with subnet. I'm like, okay, how do you do subnetting? So like, I don't know what that is. Okay, tell me about TCP UDP. They don't know what that is.
Evelyn:And now it's kind of like, gotten to the point where I see a lot of people don't know how to write a script. No. And, and they're, and I'm just I'm like, I'm like, okay, but I'm just writing little scripts. Like, actually, coincidentally, last night, I was talking to my wife about the top native summit that I was and I spoke at yesterday, in Munich, and I was just kind of like, you know, very high energy came back for, you know, the conference talk high. And I started chatting with all these things.
Evelyn:And I started explaining, you know, like, oh, Python scripting, and I do object oriented. And she's like, what is that? And I just whipped up my laptop. Oh, boy. And I just started writing her hello worlds and like, fashion and Python and showing her the difference.
Evelyn:And she is not a technical person.
Laura:I mean, when you're on that conference talk high though, it doesn't matter. You're gonna show whether anybody gets it or not.
Evelyn:Yeah. And I get like, love it. Bless her heart. She was like really focused and listening. Yes.
Evelyn:Yeah. And like, she's, she's amazing. I'm just gonna say it right, right up front. Yeah, but like, I mean, like, I'm, looking, you know, back into like, where I work, and like, where I previously worked as, like, guess, you know, in this day and age, lot of like managed services, everything's in the cloud, we're kind of pushing people more towards like, can you do programming, you know, that's kind of pushing people towards like, Python, TypeScript and everything. And it kind of leaves behind Bash, which kind of has like, a negative reputation or stereotype, in some cases, very well justified.
Evelyn:Like, I have seen a script that was basically piping echo to cat, to grep, into said, and then finally into awk. And I think they're just grabbing things from like Stack Overflow or something. Okay.
David:Stack Overflow. Yeah. I
Laura:mean, like, where's the difference now between, like, these AI generated code things and just copying from Stack Overflow. Right? Maybe? Maybe? Maybe?
Evelyn:I'm I wanna say
Laura:controlling David a little bit.
Evelyn:But yeah. I'm I'm gonna say, like, one of them is, like, very enthusiastic. I've seen, like, yes. This is correct. And the other one is like, I don't really know why this works, but it works.
Evelyn:And other people are like, yeah, it's weird, but it works. Right. Yeah.
Laura:I love those answers on Stack Overflow, the ones where it's like, so if you do this and you shake this bell over here near the computer on this side, somehow magically it works, but you'd have to press this Konami code into your terminal, and it just magically works. Don't ask me why. Just use that. And everybody's like, yes. Plus one.
Laura:This works. This fixed everything. I love those answers because it just never makes sense.
Evelyn:One time I found, like, an undocumented, like, flag for Tomcat through a Stack Overflow. It fixed my issues.
Laura:I love it.
David:I mean, Stack Overflow used to be fantastic, and there was a lot of knowledge on there. I'm not surprised that AI models are now I I assume they've been trained on the majority of Stack Overflow. But while there is a lot of not there's a lot, but it's a small percentage of the content on Stack Overflow, it's good. I can also imagine that it has a very net negative effect on the AI model training because there's a lot of outdated garbage on there too. I mean, I haven't been on Stack Overflow for probably ten years.
David:And every time I look at my profile because sometimes I still have my own answers, which is really annoying. It still says I'm in the top 2% of people that answer questions, and I haven't been on it for a decade. So
Evelyn:Yeah. That's that's true. I I still occasionally just get badges from Stack Overflow. I haven't questioned so long.
David:Your prized possession, but you have to print them out and put them on your wall. So
Laura:There you go.
David:I think what I enjoy so far about your, you know, your history and your context and where you are today, right, is that you quite clearly are like a T shaped individual, a curious individual. I I prefer to say I know T shaped is probably a very low term these days. But, you know, you like to learn lots and lots of things, and I'm sure you go deep on certain aspects as well. But I also think that that's a dying breed in this day and age, even more so with AI because people don't really need to learn anything. I mean, there was that new warp terminal announcement last week, whereas they just push tab and tell the AI what you want to do.
David:And, like, people use it to run LS. At least one of the demos was list of files in this directory. And I'm like, that took four seconds.
Laura:Are you kidding me?
Evelyn:Yeah. I'm like, have they not heard of Once again, there's so many tools that do this for you.
David:Well, I am very much on board with AI augmented programming. I do it every single day. I am having it do the things that I don't want to do, but I'm not having it do the things that I'm quite clearly capable of doing immediately, like running at least. So, yeah, I think the way that developers and I don't know. I'm way off track now, but I'm gonna bring it back.
David:It's like, I think it's very interesting to see the developers now that are junior developers and, you know, mid tier developers there haven't went completely, you know, tree shaped and being curious and learned a thousand different technologies because I think that by learning the wrong technologies, you understand and appreciate why the right technologies work. Is that when they just go to AI and see how do I how do I build that data lake. Right? Hopefully, that's something we can have a conversation on. Not that I'm fully good with this stuff.
David:They just get an answer. They take it as gospel. That is the one. And they haven't learned a thousand other ways that it doesn't work and why they got to this one. And I'm very worried about that aspect of how AI is gonna change.
David:And we can loop it into platform engineering too. Right? I'm sure there's a lot of people out there today that just go, I want to build a self-service platform for my developers. And it's like, hey. You need Backstage with Kubernetes and microservices.
David:And then they just go and push have a manifesto, email it to all the execs, get buy in, get a $100,000 bonus, and then job done. Like, this I this is this has the whole world of being potentially bad. I don't know. There's not even a question in there, but, you know, let's
Evelyn:Yeah. No. I absolutely agree. So so, like, so, like, in this talk, I I do, you know, like I have someone I put together last year for a meetup and I've managed to give it at two conferences. I don't know why they said yes.
Evelyn:For people listening, like I have this talk, I say, you know, bridging on platforms where every organization eventually builds a platform without really intending to, or wanting to. Because basically, some point, they need to have some commonalities in what they're doing. What they're known, and that kind of also kind of talk about, you know, how you actually make succeed and what are your common like dead ends in it. And one of the things that I really kind of hammer, when I'm talking about, you know, you eventually end up with it because organizations are kind of like, you know, they're chasing that revenue, you know, dream of like, I'm gonna, we're gonna make so much money if we deliver this really fast. And they kind of forget that there's also people working there.
Evelyn:And so like, we're gonna do agile and people like, okay, like, we still want rigid timelines. And we want to have a focused framework for planning everything out like that's not agile. And eventually, we're gonna do Spotify model, because it helps you be autonomous. But we're gonna do lots of check ins with every single guild and chapter to make sure they're doing the right work autonomous. And then we're doing human topology because it makes things better fixes all the all the issues you had with a with a Spotify model.
Evelyn:But we're gonna do all these things. I'm like, you're still kind of breaking it. I can go on forever about this. Yeah. But and it's and so, and it's only when they kind of realized like, oh, we should actually be empowering them to actually make things, make independent decisions, but also make decisions that follow what we want, that golden path that we all talk about.
Evelyn:So one of the things I always kind of hammer is like, think about the people, but also think about like the why, or the motivation. Like I always I always talk about the golden circle from Simon Sinek. We always like this. It's easy to define like the what. Like what are you doing?
Evelyn:We're building a platform. How are we gonna do it? We're gonna do Kubernetes with Backstage. Now we're gonna use Datadog for some metrics. And you click a button, you got everything running with all your metrics and SLOs.
Evelyn:And why are you gonna do that? Oftentimes, just don't. And I think that's like also kind of important thing we're kind of looking at like, like people relying heavily on AI and like, know, there's not really that I think there still is a curious side of it. But the curious side of it tends to get reinforced by AI saying like, this is a great solution for you. This one, like, my god, thank you.
Evelyn:You just saved me so much time. And then five minutes later, it's not working. But like, okay, alright, AI, what else should I do? Like, you should do this instead. And like, thank you so much.
Evelyn:You've made my job so much easier. And so and I think it's like, I kind of like, when I say like your platform as a product, because I was trying to try to break things into like, doing some like discovery, you know, doing some tinkering. Like I do the whole diverge converge, I figure like, we build a hypothesis, what we think might work. And then we just like, explore what solutions might work for that hypothesis. And then we just try them all out.
Evelyn:And then we eventually figure out like one or two that actually makes sense. And then we just kind of go with those. Or we pick one of the two and go forward with it. And I think that's the thing that's gonna think that I'm kinda seeing missing is because people they rely so heavily on just getting an answer that they forget that there actually are multiple answers that they should actually consider.
Laura:Yeah.
David:All right. I've got two points on that because that was fantastic. Right? And the first one is thank you for mentioning Simon Sinek because I don't think we've ever mentioned why or Simon on this podcast before. Is that right, Laura?
David:And I will single handedly say, like, it's probably the most important book I've ever read in my life because it touches every aspect of my life, and I'll give more context on that in a second. It's like when you read that book, you can apply it in your home life, your family life, even my period in life, my work life, everything. Because just asking that one simple question of why are we doing this is really important. And the reason I think it's important in this specific conversation with with platforms and and engineering culture in general is because all of the things, all the trenches no. That's not the right word.
David:All the waves we've seen, right, over the last twenty years, whether it be agile, DevOps, platform engineering, observability, SRE, get ops. I mean, I could list them all, but we'd be here for a while, it wouldn't be very entertaining. Well, I mean, hopefully. I could make it entertaining.
Laura:It might be entertaining with you. I know.
David:I could, like, bring it in a costume. But, no, like, all of these different I don't wanna call them movements, patterns, themes, whatever. Right? They were all to some degree bottom up and that the people doing the work understood the why and they were very successful, but then they crossed some sort of chasm and then they become this top down thing across organizations. And I think we've seen that with especially team topologies.
David:Right? I don't think it had a lot of bottom up movement, but agile that DevOps that Kubernetes that cloud native microservices that and it gets to a certain point where it gets so popular that the reason and the why is lost and it's just pressure from C suite pushing down. We need to be agile for capitalism and oh, we need to be microservices, cloud native build capitalism. And when the why is capitalism, everything falls apart and it doesn't work. But these bottom up movements, when people like yourself understand why we need to do this and they are pushing for agile and they're pushing for platform and all the constraints and the motivations are right, teams are gonna be much more successful.
David:That was a part run and part context.
Laura:Yeah. Go ahead.
Evelyn:I knew I was gonna that for a second. No, I totally agree. It's because it's always like a, like oftentimes, you know, when I'm pushing back, it's funny, like, kind of like built this reputation, where I am right now, like, Oh, Evelyn loves structure. No, no, no, I just want to know, like, make sure we understand the why we're doing this and what and how we're going to accomplish it. It meets I want to I want to make sure it meets.
Evelyn:Because oftentimes, it's like, oh, we need to like, we need to react to this. We got to tackle this thing. I'm like, okay, but can we actually like walk through that and really kind of consider the options a bit? And it's interesting, because like, oftentimes when when you're somebody who's like, okay, let's actually understand the why and like really discuss this and figure it out, you know, as like, you know, let's sit down, like spend an hour just like charting out, like, what are the opportunities here? And why do those matter to us?
Evelyn:And then we kind of fit in that by the end of it, we kind like develop, know, that hypothesis or value proposition that kind of helps find the motivation within everything. And oftentimes, like people think that's like, I don't wanna say convoluted, but it kind of slows us down, you know, kind of becomes a crisis very complex process, but really it's sort of like, you know, like, do we actually understand our users and what our users want?
Laura:Well, I mean, the thing is is that so full disclosure, I currently live with an engineer. He's a computer engineer, software engineer. And so I have a very different perspective, I think, than a lot of people who came maybe out of a CS degree. There is a lot of engineering that goes into doing engineering right. And what I mean by that is that it's not supposed to be fast.
Laura:If you're going that fast, you're not thinking through everything. The point is of engineering is going through those whys. It is thinking through your architecture. It's thinking through what you're building. Are there alternatives?
Laura:Why are we doing why are we picking this one? Can you give an answer to that question? And I've seen not only him, but then some of my mentors back when I first was getting into tech were straight up engineers. And I'm talking, like, they're from Canada, and they have the engineering ring. And they get really, really picky about you using the term software engineer when you're not actually an engineer.
Laura:They're those people. Oh, yeah. I love them to people. But my point is is, like, they're really into it, and they would always be like, hey. Wait a second.
Laura:We need to think this through. And it's amazing how when you have somebody like that doing this and you're talking about all of those whys and all of those things, suddenly, magically, everything usually comes out and works. It might have some bugs, but it actually works. Instead of this move fast and break things mentality where we just kind of throw it together and say, does it work? Shove it out the door.
Laura:Oh, look. It broke. It's not like that. It's more you're thinking it through. And so, I don't know, I lean more towards that engineering side because to me, it's more like the scientific method.
Laura:You're going through, you're testing your hypothesis, you're trying this, saying, okay, it kinda works. Let's build it. Let's see if that works. Okay. Here's another option.
Laura:Here's another option. Here's another option. Let's go through and pick the best one, not the one that chat GPT told us to use yesterday. So, I mean, to me, it's it's engineering. That is what engineering is, is going through and thinking all of that through and trying all the options before you build something.
David:Yeah. I mean, to to I don't know. Triple down on that. Right? Evelyn said something.
Evelyn:I'm like, I kinda wanna dissent.
David:We're all we're all
Laura:in agreement. Dissent? I know.
David:We're all in agreement. You've now double clicked on that, and I'm never gonna say that again. I may even edit that one out. David. I know.
David:Let's zoom in on this. But
Evelyn:Well
David:No. What I mean is, like, I completely agree with why Evelyn is saying this because you need an Evelyn on your team. Right? We need to understand why it's so important. Otherwise, what we end up with is, and we've seen this many times.
David:I'm sure we've all seen this. Right? It's where Google releases something because they do something internally and then a whole bunch of engineering organizations who want to aspire to be more like Google adopt it without understanding why they actually go down that road. And then that's when the problems come down. And that's the same re the same thing with platform engineering.
David:Evelyn made the right decision to ask the questions of why do we need a platform. What really happens in a whole bunch of other organizations where people aren't asking these basic questions really. Right? Everyone should understand why they're doing what they're doing. They end up with the same copy paste nonsense platform because they've been told that by the people selling the platforms.
David:Right? It's like, I wouldn't name any companies, but they come along and go, hey. You can have self-service, this, this, and this. Oh, okay. Let's just install that.
David:Okay. Did we need self-service, or did we need something else? Did we need a platform because we want to be able to spin up new microservices and we're just boilerplate? Should we be handling code generation and templating separately? Or is it because we need better sequence management, or is it because we need a single plane of gas and then observability across disparate clusters and disparate regions and disparate clouds?
David:But oh, no. No. You've you've now got Backstage, and it's got a little box where you can just, you know, deploy it in your application. Like, the needs and dependencies and the constraints of every organization are different. I'm not saying they're snowflakes, but they are different.
David:I mean, you have to understand the motivations if you want to not just make your developers happier because they understand why they're building what they're building, but because your end users are also gonna be happier because you're solving real problems that they have and not just giving them more cognitive overload of, now I need to learn a new thing and I didn't have to do this before. Sorry. I keep ranting today. It just
Laura:You're good. But but hold on. Evelyn, you said that you wanted to dissent. I'm actually No. Come on.
Laura:This is the one part. Right?
Evelyn:Yeah. Yeah. So I wanna hear it. So like, people heard things like, this is super cool for engineered. And then so and so like, agree, like engineers, they're generally very methodical about how they're building something.
Evelyn:But the risk, I mean, is always, got, I can tell you so many stories about ridiculously to say, where it's like, we need leaders to help with this problem. So but it's really that like, I'm when an engineer starts tackling a problem, oftentimes they just have the requirements and they start running forward with requirements. And it will build you an elegant solution for those requirements. But there's no point where it was like, okay, well, why are these necessary? Or they want to be like, or they'll design to make it future proof, you know, like, okay, we're going to go, you know, full on adapter focus.
Evelyn:So we can like swap all the different components. We're gonna do like platform agnostic, we're not gonna adopt anything directly. Okay, we're gonna use like the latest, you know, no, tech stack that are done. And so that's where it's like, you know, they're very methodical about planning it out. But they can oftentimes just kind of get very distracted.
Evelyn:Yeah, by hop up by the right by what's the right way to do it. And that's why I always say like, having that why about, okay, well, why do wanna make these tech choices? Because I remember like a couple years ago, I had an engineer, I was like, okay, I want you to use fluent d to basically do some log shipping over to Kinesis streams, we can basically publish our logs into New Relic. And then like two weeks later, he came back to me and he's like, here's a solution like where's fluent D? And he's like, Oh, well, I wanted to use this library because I can do all these other things.
Evelyn:We're never gonna need to do any of those other things. And now we have like this divergence from a standard and how we actually do telemetry and log shipping.
Laura:Yeah, I guess to me though, that's a sign of a more junior engineer.
Evelyn:Oh, this was a senior engineer, actually.
Laura:I no. I know. But I'm I'm saying to me that's a sign of somebody who's more junior because they're not understanding that, one, if someone tells you the exact tech stack they wanna use and you didn't question it when they gave that to you, You didn't ask why then. It's not your job to then go just decide to go try something new and shiny. That's not how the job works.
Laura:But it is your job when you first are assigned those requirements to go through and say, hi. Where did these requirements come from? Let's have a conversation. Let's understand why these requirements are there because a lot of times there are cases, and I've been hearing a lot about some of them from some of my friends recently at one company that I talked to. They are getting requirements from product, but it's literally the requirements that the customer is giving them.
Laura:But the customer doesn't know what they want. They say they want this, but then the engineer's job is to question and say, so why are we doing that? Why are we building this that way? Otherwise, you're reinventing the wheel or you're not considering this solution or you're not considering this possibility. And that's the conversation that should be had at the very beginning.
Evelyn:I agree. And I've actually wondered what we oftentimes see, like, you know, engineers are so exhausted with product because product they're like, we want you do this. Like, this is ridiculous. Doesn't make any sense. And the customer asked for something that's like unachievable.
Evelyn:So I think it's like, I just was like, everybody should be asking this question, like, why? So when the customer goes a product or a product talks, and they're like, I want to have be able to do this. And like, okay, well, like, what would this actually make easier for you? Yeah. And this is why I'm always talking like jobs and functions, you know, it's like, what job are you trying to perform?
Evelyn:What functions does that job satisfy?
Laura:Right.
Evelyn:And oftentimes, when I'm sitting there talking about jobs, you know, like, okay, what jobs is QA person trying to solve? And I'm like, well, the QA persons are just wanting to have to solve like, no, no, the jobs are actually much more human. At the end of the day, you know, like one job we want to perform is to go home happy.
Laura:Yeah.
Evelyn:And people kind of tend to forget that aspect. That's why I was saying, like, I'm like, you know, I go think thinking about the why from like, all across is really helpful. But it's always like, when engineer has requirements, they're gonna be thinking about why these specific requirements, well, often teams would it be and so that's why said, can I kind of call like the holistic view of like, you know, kind of like jumping across, like, whole spectrum, like what actually makes sense to build for us at this time? That's why with a platform engineering, we always say, you know, we wanna build things, the right way at the right time with the right people. Mhmm.
Evelyn:This is one of those things. Yeah. And I think it's it's kinda like that's why I was kinda dissenting when you're like, but engineers are so great and methodical and figuring things out. Like, go a bit sideways.
Laura:That's that's that's fair. Like, guess maybe I just have a very, very rosy view of engineers because the engineers that I engage with usually are, like, staff plus, and they spend a lot of time having those conversations that you're talking about. Not I'm gonna go chase the new shiny thing because it's fun, and I get to go build the thing and I'm gonna go future proof it to the nth degree and all that. No. They're usually much more down to earth and thinking things through.
David:Not me.
Laura:Who knows? Well, yeah, but you'd we've already established that you don't have an engineering degree. So wait a second here.
David:I mean, I almost canceled the stream to go play with a new shiny technology. So
Laura:I know. I know. I know how you do things.
Evelyn:I would have had, like, much forever.
David:In my defense, I'm the only person responsible for my production infrastructure. So it's it's my sleep that I compromise every time I play with something shiny. So and that's allowed.
Laura:There you go. Yeah. Yeah. As long as you're not, you know, giving somebody else the two AM pager.
David:Yeah. Could you imagine that if someone hired me to help them build their Kubernetes platform and I was like, here's all these alpha softwares. Good luck. I'll see you later. I actually did that.
David:I mean, I've done that a few times. I'm not as bad as that. I was a big fan of Vector when it came out as an open source Rust based collector project. I thought it was super cool. And then the big purple dog bought it and swallowed it up, and now I feel bad for any company I've left them with that.
David:I mean, it's still open source, it's still maintained, and I'm sure it's still good, but you know?
Evelyn:Yeah. I remember last week, we actually implemented vector, and that was also was one of the things, actually, it's kind of a bit limited now, but it still works really well.
David:Yeah. Very cool software.
Evelyn:But because I do I I have a I a question for you, actually. Because one of the things I always see in the cloud in this space is people really drinking the Kubernetes Kool Aid. Yes, like, it's very much like, people are going so hard on Kubernetes. And I oftentimes I look at it, I'm like, okay, I understand the benefits here and how it helps us. I don't find it as like the one size fits all solution.
Evelyn:I'm not saying we should go back, you know, to like, you know, running, like virtual machines or instances and stuff like, you know, like, truly in, like, this running container on that. But I'm kinda curious what what which which what's your opinion is on, like, where where do you think, like, Kubernetes is not a good fit?
David:This isn't how this podcast works, Evelyn.
Evelyn:I'm turning the tables. I mean
David:So, I mean, I mean, I have been drinking the Kubernetes kool Aid now for for ten years, and I have everywhere I went, I brought it. And I used to try and not do that, but the need to always be there. And I always had really good story for when not to use it. So I'm gonna answer subjectively from that regard, but I think and this is, my disclaimer. Objectively in 2025, every company should be on Kubernetes because you're losing out on too much now because everything is now leaning towards Kubernetes native, and all the examples are on Kubernetes.
David:So even if you've just got a Java monolithic application, no. You should probably still run that in system d. But whatever. Like, if you go by Kubernetes, you do get log collection for for free. Right?
David:And you guess you can have get ops for free, and you can have observability pipelines using Prometheus service monitors for all all this is for free because it's free to learn how to do it, and the examples are all there, but there's still the tax. Right? You still pay a Kubernetes tax. But there are so it's hard for me to say don't use Kubernetes because I really do think it's like you lose out in too much now because that is the de facto. But Java does not work well in containers.
David:It's getting better. I think if you're on Java 21 or whatever, the the latest and greatest is where it actually respects Linux secrets. You may have a good time, but prior to that, it was hell on earth. And the JVM just wasn't built to run that way. It does hop hop code path optimizations over weeks and months.
David:Container based workloads don't run for sometimes even days, never mind weeks or months. So, like, you'd lose a lot of the JVM performance tweaks by just not by by doing Kubernetes. So I say Java is usually a good one not to put in containers. Now with regards to not using Kubernetes again, I'm struggling because I put everything in Kubernetes. Even if I've got single node clusters, I put stuff in Kubernetes just because I like the fact that it's a supervisor more than anything else, and it handles configuration and secrets even though I don't do a lot of you know, most I don't really even have that many five node clusters because I just run single node clusters everywhere.
David:It's just so powerful. I'm the worst person to ask this question to. I'm
Laura:really flattered.
Evelyn:I mean Yeah. I I really wanna kinda like like twist the needle a bit and see how you react.
Laura:I mean, like, the fact is is so I'm the probably the one who's a little more skeptical about Kubernetes being the solution for everything out of the two of us, mostly because I don't like the idea that something is becoming such a de facto standard that is really a terrible way to host a static site, as an example. Like, I don't need that much overhead. I'd rather not. I'd rather not have things that go and break all the time that I had like, there's all this complexity that Kubernetes brings in my mind that isn't always useful. It really depends on what you're building and why and why it's important that that's being built that way.
Laura:I don't see anything wrong with having a VM for something that is gonna be long running, that is going to be doing something that needs to be basically functioning like a single bare metal machine. To me, that's really where, like, you're kind of trying to decide, do you want microservices? Yes. Most cases right now are microservice based. But do you need it?
Laura:Is it always gonna be that way? There's some things that are just not gonna work that way. One of the really classic examples I always think about are banks. The mainframes that they run for a lot of their heavy transactions really just do better to be left alone as more of a mainframe, whether that's a true mainframe, like a more modern mainframe, or you're running on virtualization on hardware. To me, that is probably one of the bigger use cases that you don't need Kubernetes to be doing all of that.
Laura:You don't need Kubernetes to be running all of those transactions all the time because you need it to be up and running. And why go through the whole process of trying to move everything to Kubernetes? Because that's what everyone else does or because it's the everything is easy to plug in. Are we getting back to the same question of, oh, well, this is what everybody else does. I'm going to just plug it in because I don't know how to do it any differently.
Laura:Whether that's the
Evelyn:Yeah, I agree. And then
David:this is
Evelyn:sort of like, we're like, I was like, because I'm almost like, why do we need Kubernetes? You know? And like, or even like, why do we need to go all the way into the microservices? Like, should we actually use instead of more towards like, you know, intent driven, you know, development of services, you know, multiple, we don't really need to do, we don't really call them microservices at the end of the day. Now, so one of the reasons I, you know, I've kind of been thinking about this, I'm like, oh, crap, Kubernetes is everywhere.
Evelyn:So I mentioned early on that, release management is one of things I'm actually dealing with the moment. And the biggest pain point isn't the how do we do release management is how do we decouple CI from CD. A lot of the time I see everything is basically like a recent heavily integrated, you know, we use the entire use CI systems to do all of our deployments. And we call things GitOps that are really being GitOps at the end of the day. And that's actually where I see a lot of issues.
Evelyn:We basically like, we tightly coupled the definition of infrastructure with actually the application being deployed. And so one of the things I discovered when I like, I like, look at the landscape, like, what are the options, know, for purely CD solutions, and like, 99% of them were all just like built around helm, for example, or Argo CD derivative. And like, and then like, I stumbled upon like Helmless, which is using Google run, I believe behind the scenes. And I'm actually like, very motivated to just like develop my own integration for AWS. And then just basically upsetting current cloud native spectrum just because they decided to do something that wasn't community related.
Evelyn:And so that's kind of like one of things where I'm like, I feel that, yes, everything is going towards Kubernetes, but not every use case actually makes sense for it. And we're actually, but we still want to be container based. And that's where I kind of see like this, like this, this chasm, perhaps, or this disconnect of us, you know, how do we actually do like, know, container driven solutions without immediately jumping straight into Kubernetes at the same
Laura:time? I mean, like right now I've been playing a bit with Podman and looking at that and they're like, Podman can do minor orchestration, I guess I can say. Like, it's it's you can run multiple containers without necessarily thinking about adding an entire Kubernetes cluster underneath it, which is kind of fun to poke at. I don't know a ton about it in production. So, you know
David:And also that's cordless. Then Which allows you to generate system d unit bales for Podman containers, which is also a really nice approach as well as long as you're happy to stay on that kind of single node concept, which again, for most people is actually it's fine. It's a good way of doing it, but then you have to learn all that stuff yourself. Like, it's like, you know, USB C is everywhere. If you need to charge your phone, someone has a USB C cable.
David:Right? And that's that's Kubernetes in 2025. But the minute you say, oh, well, I just want to run a Quadlet that does MongoDB and I want to set up automatic backups and I want to do geo replication and stuff, you're off the beaten path at that point. And that's why I generally think that most people should be looking at Kubernetes for most use cases, even though it's not the best approach. It's gonna be the easiest in the longer run.
Laura:Well, this is where I argue with you though,
Evelyn:No. I'm serious. Have opened the can of worms.
Laura:Know, but I guess my point is I'm coming back to where we started this whole conversation of how much are you willing to outsource to other people? How much are you willing to outsource to ChatGPT or to the experts at AWS or to wherever versus understanding how your system works and hosting your own stuff. There's lines. And what are you willing to what's the trade off here? I know, David, you're looking at it as trade off is Kubernetes.
Laura:Everybody has everything everywhere. There's all these integrations. It's easy to plug and play. Just go. I'm looking at, well, if I'm willing to hire the people who can figure this out, depends on the size of the company, depends on the size of the business, depends on what they're trying to do, depends on, like, specific use cases.
Laura:Maybe you'd rather hire an expert to be able to do those things and not outsource that expertise outside of your organization. Again, do you want to hire or do you want to spend money? Do you want to buy Backstage or do you want to hire to build your own platform that works the best for what you're doing? I think it needs to be an informed choice. And that's kind of where I look at this is David, our classic argument of Lara looks at the business side of it, and David looks at the
David:tech I I may have brought this back to CapEx versus OpEx discussion. Come on.
Laura:No, CapEx. I wish. No. I'm just kidding. Hey.
Laura:I mean, you're the one who brought up rust earlier anyway.
Evelyn:I
Laura:think I think yes. You did. You mentioned a rust collector. That was your fault.
David:Open telemetry collector. I never said rust. I haven't said rust today.
Evelyn:Yes, did. Think rust.
Laura:Heard the fact that it is a rust based system with vector.
Evelyn:Anyway, so
Laura:getting back to the point though, I think to me, that's really the question that you need to think about is if you're looking at, I have the money to spend and I can just outsource all of this to Kubernetes, to whoever, to whoever has it, to whoever can run it for me, etcetera, fine. But if you're willing to take the time to invest in it, maybe it's a better choice for your platform. And that's kind of where I get back to it.
Evelyn:Yeah. No. And then I think that I think it's totally fair because at the end of the day, you know, people who are wanna run containers, they don't actually care whether it's Kubernetes or something else. The one who cares about is one's contract, oh, and maintain it. And it's a question of, know, how much you wanna offload to another vendor to take care of it for you.
Evelyn:Because I think there's there's so many there are so many, many vendors that literally all they do, they just like, we just run Kubernetes for you.
Laura:Yep.
Evelyn:Yeah. And I think that's, that's, that's actually really honestly, the other side of it. And that's kind of where I have been kind of looking at it like, okay, like, this Kubernetes right fit, what and actually, and then this even like, kind of like turn the question back on myself, you know, I should also be asking myself the why of like, why am I so hesitant to go towards Kubernetes? And it might just be because I've gotten so used to this high level of abstraction or everything's managed, that now what I'm saying like, okay, I need to decouple CI from CD, okay, we actually use defining application releases infrastructures code, that means we'd be more dynamic and have a system or actually dynamically pick up what the current artifact is to deploy. I'm I'm already spelling out Kubernetes to specify.
Laura:Yeah. You never know.
David:Alright. It needs to schedule a follow-up in three months and see if your Kubernetes in production yet.
Laura:Anyway, but I was gonna say, you know, I'm watching the time and unfortunately, think we are very close to time.
David:Yeah. Again, we're not very good at keeping to that twenty minute mark. We're over 40 now. Yeah. But I mean, it's been fun.
David:It's been so much fun, Jess.
Evelyn:I mean, my commute is one hour, so this is perfect for me.
Laura:There you go. There you go. See? We're okay.
David:Alright. Anything else we wanna discuss before we wrap this up?
Evelyn:I I mean, I don't I don't have any sales pitches, unfortunately.
Laura:That's okay. It's all good.
David:Alright. Well, I mean, thank you so much for taking time out of your day, to come and talk about op and platforming and, you know, the rise and fall of Kubernetes. You know, even though I've sat here and and said that everyone should really adopt it in 2025, that doesn't mean I'm not keeping my eye over here going, oh, what's next? Like because I don't think Kubernetes will be the thing that we are still running in five or ten years' time. Maybe it'll just be Cloud Code agents doing containers.
David:Who knows? But
Laura:David. Sorry.
David:I'll see myself out.
Laura:You should. But thank you for coming. This was a really good episode. I had a lot of fun.
Evelyn:Yeah. Thank you for thank you for having me. Yeah. And and I'm gonna continue to be your ply gal in blue sky, just, respond to everything you post.
Laura:Yay. Woo hoo. Thanks for joining us.
David:If you wanna keep up with us, consider subscribing to the podcast on your favorite podcasting app or even go to cloudnativecompass.fm.
Laura:And if you want us to talk with someone specific or cover a specific topic, reach out to us on any social media platform.
David:Until next time when exploring the cloud native landscape on 3.
Laura:On 3.
David:+1, 23. Don't forget your compass.
Laura:Forget your compass.
Creators and Guests
