Transcript

[00:00:00.410] Ned: I was really I was distracted, sir, by the by the lack of a cow in the top level domains that I don’t know why that sticks in.

[00:00:11.030] Chris: My Craw dot crawl.

[00:00:14.690] Ned: Also not a top level domain, but AA gets a top level domain because they paid enough money or they did it early enough when that was a thing. I don’t know.

[00:00:27.240] Chris: One, they have a really high rating.

[00:00:30.970] Ned: That’s true. Very credit worthy. That old AA. I’ve been AA member since, like, 2006, and I think I’ve called yeah, mine’s fairly embarrassing, too. And I think I’ve called them twice, maybe three times.

[00:00:46.110] Chris: I’m trying to remember. I’ve definitely used them, but yeah, certainly not every year.

[00:00:53.250] Ned: No, I think every time it’s been because of a dead battery with my.

[00:00:59.350] Chris: Old car, I ran out of gas once, and the reason for that was that the gas meter stopped working, which is apparently a thing that can happen.

[00:01:08.550] Ned: Yeah, I have not had that happen to me. But I guess if your car is old enough or crappy enough, then, yeah, the gas gauge can just go, I’m done, I’m tired.

[00:01:21.150] Chris: Floating.

[00:01:22.970] Ned: Maybe the float just got stuck or disintegrated.

[00:01:29.630] Chris: Maybe it was stolen.

[00:01:31.330] Ned: Someone went in your gas tank and stole your float.

[00:01:34.210] Chris: Just the float.

[00:01:35.140] Ned: That’s a very determined thief.

[00:01:38.350] Chris: You need what you need. I’m not here to judge. Except for the stealing part.

[00:01:43.570] Ned: Getting very judgy about stealing.

[00:01:45.870] Chris: How dare you, sir and or madam. Potentially.

[00:01:50.360] Ned: It could have been a team. Could have been a team of people all robbing your gas tank of its float. Would they be called float? Hello, alleged human, and welcome to the Chaos Lover podcast. My name is Ned, and I’m definitely not a robot. I have collected mathematical proofs from Chat GPT to verify my authenticity, and I can pick out traffic lights and pictures with alarming accuracy. And alacrity, yes, a true human through and through. With me is Chris, who is also here. Hi, Chris.

[00:02:26.970] Chris: You know what’s fun?

[00:02:28.380] Ned: What’s fun?

[00:02:29.520] Chris: Computers.

[00:02:30.920] Ned: No, inaccurate.

[00:02:33.590] Chris: First of all, you are obviously aware of the whole chapter. T getting worse and worse at math.

[00:02:40.060] Ned: Oh, it’s getting worse now?

[00:02:41.780] Chris: Yes.

[00:02:42.260] Ned: That’s the wrong direction.

[00:02:43.640] Chris: Chat CBT Four is apparently getting worse and worse at math as time goes on and nobody knows why. Super cool.

[00:02:49.560] Ned: Maybe people are feeding garbage into it to make it worse.

[00:02:52.780] Chris: Well, here’s another potential reason. What’s 0.1 plus zero? Two.

[00:03:00.330] Ned: I feel like this is a trick question, but I’m going to go with 0.3.

[00:03:05.290] Chris: If you do that as a float actually, it might have been multiplication, one or the other. If you do it as float in any programming language that basically exists, the answer you get is 03004.

[00:03:25.890] Ned: Yeah, I’m familiar with that. I’ve encountered that in multiple programming languages, which is why you always kind of round off exactly two or three decimal places.

[00:03:34.880] Chris: Digit. Usually it’s six or seven. Yeah, but the actual math, because it’s not divisible by two in a computer is impossible, to be precise. And yet we landed people on the moon, allegedly.

[00:03:53.290] Ned: Well, it depends on your desired level of precision, right?

[00:03:57.370] Chris: Usually land on the moon or die in space. That’s the level of precision I think we were going for in the 60s.

[00:04:03.630] Ned: Yeah, I get it. But what I’m saying is, like, if you can compute it out, reliably to six decimal places, that’s probably good enough for landing on the moon. Seven seems unnecessary.

[00:04:18.690] Chris: Seven is bad luck in some country, sure.

[00:04:21.350] Ned: No, just seven in general. Totally unnecessary. It now goes six. Eight, done.

[00:04:27.940] Chris: That’s fair.

[00:04:28.890] Ned: Okay, well, now that we’ve established that words are meaningless, let’s talk about math is broken and math is broken. Let’s talk about meaningless math and words.

[00:04:45.370] Chris: No, wait, we can’t use seven.

[00:04:46.880] Ned: There is no seven. You’re going to have to give me a six or eight out of ten.

[00:04:50.700] Chris: I’m going to have to give you a six, then.

[00:04:53.150] Ned: Well, I did say we have to round.

[00:04:55.630] Chris: Okay, but anyway, let’s get back to our often visited topic, buzzword Bingo software Development Edition. Let’s learn about platform engineering. You’ve heard of this?

[00:05:14.490] Ned: I have.

[00:05:15.560] Chris: It’s basically what you use to build a treehouse. You start with, wait, now that’s all wrong. This is computer stuff, so it’s way less fun than that. But platform engineering is absolutely a thing, and has been for at least two years, give or take. And it’s one of those, even in the industry, it’s one of those vaguely understood topics of the type that sounds good, but you really need to pay some significant attention to it in order to make it into a successful solution for your company. In a way, talking about platform engineering is kind of like talking about zero trust. The term makes sense. You can use a few words to explain it, but it takes a lot of time and effort to really suss out the details of what needs to be installed, what are the problems that it’s solving, how do we prove that it works, et cetera. As the kids say, it takes a minute to learn in a lifetime to master. All right, so with that in mind, its relative newness and the, shall we say, haziness of the definition in the zeitgeist around the term platform engineering, let’s try to get a little more sense out of it.

[00:06:36.300] Ned: Okay?

[00:06:37.710] Chris: Now, with something this big, what you’re going to find on the Internet are approximately an infinite number of different definitions, right? And in platform engineering, this is absolutely the case. And one thing I’m going to do here is throw a few of them in here and there as we go, just so you can get a little taste of what the Internet thinks.

[00:07:00.870] Ned: I found that platform engineering, the definitions tend to align with the person who’s defining them. Like if you’re a vendor trying to sell a platform engineering solution?

[00:07:12.930] Chris: Perhaps.

[00:07:15.850] Ned: Perhaps.

[00:07:17.470] Chris: So let’s start with this one quote platform engineering is the practice of building and maintaining a platform for application teams to use to develop and deploy their apps consistently and reliably.

[00:07:34.370] Ned: That sounds familiar.

[00:07:35.670] Chris: Okay, I’m not going to tell you where they’re from. When in doubt, if you like them, it was me. But that’s the idea. A platform engineering team builds a platform, then the software development team utilizes that platform to build applications.

[00:08:00.330] Ned: Okay, makes sense so far.

[00:08:03.710] Chris: The important thing here is it’s a concept. It’s a way of working just like Zero Trust. It’s not a product. You can’t just go to Walmart and buy platform engineering. First of all, you would definitely have to at least go to Caldor. Platform engineering is a philosophy. It’s an end state or desired working environment that can be composed of any number of the infinite tools and services that exist in the software development and infrastructure world.

[00:08:37.860] Ned: And boy, are there a lot of them. Have you seen the CNCF landscape? Yaoza?

[00:08:45.130] Chris: I tried to buy that poster and it turned out that it was actually.

[00:08:48.090] Ned: Wallpaper or a billboard.

[00:08:53.770] Chris: Anyway, one thing to note right off the top is platform engineering is not just another way to say DevOps. It’s not just another way to say internal developer portal, and it’s not just another way of saying self service.

[00:09:14.290] Ned: All this sounds very familiar. Once again, I learned it from one.

[00:09:18.400] Chris: Of the worst YouTube channels I’ve ever seen. That’s fair link in the show notes.

[00:09:22.800] Ned: If people like wasting their time, I love you too.

[00:09:31.830] Chris: And the one good way to figure this out and to sort of suss out the details here, is look at the difference between the roles and definitions of a DevOps engineer and a platform engineer. Now, there are definitely commonalities. First of all, they both end with engineer. That’s a giveaway, but they are not the same thing. The Ven diagram is not a circle. The goal of DevOps is explicitly to do programming better. How do you do that? How do you write? How do you approve stress test, deploy, and possibly roll back in as painless a methodology as possible that’s DevOps? Platform engineering supports DevOps by building the environment in which that kind of nimble development is possible. And then at the end result, a finalized production environment can be hosted. And yet, to make this insufferably parenthetical, you can in fact use DevOps practices to develop your platform engineering platform naturally. But the point is, they’re two different things, right?

[00:10:50.610] Ned: I tend to think of DevOps as being like a philosophy, a true philosophy that can span multiple teams and the processes that govern an entire organization, whereas platform engineering is a little more centered. It’s more on a specific team and the practices of that team building the platform for everyone else, right?

[00:11:13.590] Chris: And in both cases, centralization and standardization of the process is important. And we’ll really figure out why as we go through this. But the idea is, as you have a larger and larger company, you might have individual developers or teams of developers that are isolated to one specific silo, doing things in one specific way. This is not ideal, especially if you want to have your products interoperate. It makes a lot of sense to work from a common set of standards. Right?

[00:11:46.130] Ned: Right.

[00:11:47.650] Chris: And that’s one thing that happens is a developer might just decide, I need to work on Project X, I need a system right now, I’m going to go out and build one right now and I’m going to install the software that I am aware of right now. And then you end up with this unique and beautiful snowflake inside of your environment that is going to exist forever. Because nobody ever upgrades anything that infrastructure. In that case, since it’s a developer’s problem, they solve that problem as fast as possible and then get to the problems they actually care about. Like programming. Platform engineering helps get to a place where the developer doesn’t have to care about that underlying infrastructure. They log into a system of some kind, they pick what they need from self service menu and the infrastructure is created for them to work from. The way that this is helpful to the developers is that the platform engineering team has to treat the developers like their own customer.

[00:12:51.670] Ned: Right.

[00:12:52.200] Chris: That self service menu only works if the options that are available are the ones that developers want and need.

[00:13:01.450] Ned: Yeah. Otherwise they’re just going to go around the platform and build their own thing and we’re back to shadow it.

[00:13:08.120] Chris: Exactly. And we’ve wasted several million dollars on platform engineering and everybody’s mad.

[00:13:12.770] Ned: Yes.

[00:13:15.470] Chris: So if you look at it from the platform engineering end state perspective, what happens is the end user, in this case the developer, has one place to go. They log in to some type of a front end, they select the application, the environment. And in a very simple case, if this is just Iad, how big of an instance do you want? Click a button, everything is spun up in the background utilizing hyper automation. Told you it was buzword.

[00:13:49.920] Ned: Bingo, yay.

[00:13:52.330] Chris: The software that is necessary is installed. I mean, this could be databases, middleware, what have you. All licenses are activated, whether this is free or paid or whatever, all monitoring is enabled and all managers are notified. Think of all the problems that this type of automation and limitation, and I’m putting limitation in air quotes here because in platform engineering terms, this limitation is a benefit.

[00:14:18.870] Ned: Right.

[00:14:19.830] Chris: Only a small subset of software gets deployed. The software, if it is commercial, gets properly licensed, meaning your company doesn’t get dinged on some type of audit based true up hashtag Oracle. All the infrastructure is enabled with monitoring, so you don’t have security holes if and when somebody forgets about an IAS that’s been running for 18 months and hasn’t been upgraded. And all the managers, both the dev team, infrastructure team, whoever, are aware that there is new things running, jobs are in process, and finance teams are aware that Bill is going to get a little bit more expensive.

[00:14:59.870] Ned: Right? And hopefully through that self service process, a justification is there for why that environment exists. And perhaps you can even set a TTL for that environment and say after six months this thing destroys itself, or after 6 hours this thing destroys itself. Because I’m just using it for testing, right?

[00:15:19.420] Chris: Yeah, I mean, you could have it set up. If you run a micro instance, you can run it for, like you said, 24 hours or 72 hours without any approvals at all.

[00:15:28.840] Ned: Right.

[00:15:29.530] Chris: Do your little very small, isolated test and then delete the instance. And if you forget, the system will do it for you. Anything larger than that requires approvals. Some would call that robotic process automation.

[00:15:46.190] Ned: Yeah, maybe we could throw that in. It is buzword bingo after all. I’ve got four spots down on my card. One more and I win.

[00:15:55.570] Chris: So here’s a non computer way to think about it from the developer’s perspective. How do you buy a car? No, I’m seriously asking. I haven’t done anything of the sort since 2005, so I don’t really remember anything about the process except for all the crime.

[00:16:11.950] Ned: Yeah, that sounds familiar.

[00:16:16.890] Chris: When you buy a car, though, you have a lot of options, but your options are not unlimited. In effect, you have a menu. Everything is standardized. You go to a dealership, you want a mid sized car? Great. Here’s your trim options. And usually they have category names. The Le model, the SLE, the XLE, the Rstle, whatever. Spin the wheel, pick a color inside and outside. Obviously, they had better match. Don’t be a heathen. You pick your transmission, and it had best be manual, you coward. And boom, you get an email saying, congratulations, Ned. Come pick up your brand new pink Miata on Tuesday.

[00:17:05.110] Ned: Yeah, I mean, it’s more of a fuchsia, but still. Point taken.

[00:17:09.770] Chris: That is the world we want developers in. They can select from a menu of available options. Now, that menu can include a lot of options, but it’s still limited to the menu, which means that developers and anybody else really can’t create things ad hoc. And this is what you were kind of alluding to earlier, that platform engineering done right, is a way to vastly decrease the potential or even the need for shadow it in development environments. Everything that’s created, we know about. There’s a justification and an approval, a time to live, et cetera. Because if devs are able to create literally whatever they want, what you’re going to end up with is a whole bunch of cars that have five wheels, something special and unique that supports usually one and only one workload. And that shit does not scale no, it does not. All the things that are good to do in it become harder. It’s hard to support, it’s hard to update, it’s hard to upgrade, and it’s usually undocumented. And then when the developer inevitably leaves for a higher paying job, no one knows what to do with it or even what it does.

[00:18:24.930] Ned: I think another similar analogy would be like building a laptop on Dell.com. They have a lot of different models. You can customize them up to a point, but you are limited in the different kinds of motherboards that are available, the different types of Ram that’s available, graphics cards, all of that. So there’s a lot of options and you can build a fairly customized rig. But if you want to go deep into customization, you’re going to have to buy and build yourself.

[00:18:54.330] Chris: Right.

[00:18:54.920] Ned: And as you build, it’s also telling you the cost of that system, which a good platform should be able to tell you the predicted cost of the environment that you’re building as you build it.

[00:19:06.430] Chris: Yeah, and just like Float based mathematics, trying to figure out the exact cost of cloud environment, let’s just call it.

[00:19:18.080] Ned: We try to get close enough, it’s imprecise.

[00:19:22.610] Chris: But I mean, the end results here are powerful for an organization. We talked about all the ones already in terms of the benefits, eliminating shadow it and getting rid of environments that are no longer needed. Platform engineering, providing those curated sets of tools and capabilities, also means that every developer uses the same stuff. Increasing interoperability between projects, increasing the amount of modularity, ideally simplifying the develop delivery pipeline simply because there are less options. You don’t have infinity to work with, you have the tools that have been provided and that’s it. This helps developers work faster because they don’t have to work on something that is so unique and faster. Developer is cheaper developer, less time spent typing, more time spent collecting that sweet, sweet app revenue.

[00:20:18.530] Ned: Right.

[00:20:21.110] Chris: And since everything is composable, like I said, developers from one silo can benefit from the work of another. And they can also submit requests to the platform team to get the platform changed in a way that will benefit everybody. But it’s not just, we’re going to run postgres 7.6.2 on this one specific application where everybody else is running 8.4 because.

[00:20:48.750] Ned: Right. The idea is that the platform engineering team will listen to the developers and as they bring up new possible additions to the platform, that’s a conversation that needs to happen and then you need to figure out how that’s going to be integrated into the existing offerings, whether it’s worth doing. But it’s a conversation that you need to have. It’s not just, we built the platform once and now this is the platform.

[00:21:14.230] Chris: Yeah, exactly. In a lot of ways it’s like vulnerability scanning. You don’t just scan one time and be like, we’re good.

[00:21:25.400] Ned: Yes.

[00:21:26.410] Chris: It’s a continuous process and from the platform engineering team’s perspective. They need to look at this as a continuous process. Development environments change, applications get updated, and the templates that support what we’re working from have to be updated too. So that’s why platform engineer is a job, because somebody has to keep that stuff up to date.

[00:21:51.570] Ned: Yeah.

[00:21:53.430] Chris: So the next obvious question, if platform engineering is so great, why isn’t everybody doing it? Well, the main reason is it’s freaking hard.

[00:22:05.690] Ned: Oh, you mean this isn’t simple as just buying something or pushing a button?

[00:22:10.810] Chris: No, not even at costco. To do it right. That is to see a proper return on your investment and also not a mass exodus of your developers. It has to be done organization wide, which basically means from the top down, this can be difficult because, as we’ve talked about, just about every organization on Earth is at least a little bit siloed. Each group does their own thing in their own way, using their own team of developers and their own version of the software. And this happened because software development is also hard. And the prevailing wisdom for many years was essentially, well, they’re developing apps and the apps work best not to bother them. That again. And this is becoming the theme of the episode also doesn’t scale right, and it becomes very hard to manage. So we won’t get into all of them. But rest assured, there are a lot of steps to get to platform engineering as an end state from the Wild West. It is most development environments. So why are we even talking about it?

[00:23:40.230] Ned: Because it’s Tuesday and we needed a topic for this week.

[00:23:44.390] Chris: No, we’re talking about it because Gartner told us to.

[00:23:47.180] Ned: Ned ah, fuck. All right.

[00:23:49.630] Chris: Platform engineering has been identified in the innovation no. Innovation wow.

[00:23:56.570] Ned: Eurovision. No, couldn’t be.

[00:24:01.310] Chris: Innovation Trigger phase of the Gartner Hype cycle, making its first appearance a year ago, August 2022. Now, being in the innovation trigger phase means that a technology or concept is gaining attention and excitement with all kinds of disruption potential. We love disruption.

[00:24:24.070] Ned: Love it so much every day. Disrupt me.

[00:24:27.850] Chris: Innovation trigger is a phase where early adopters are experimenting with the technology, but it has not yet seen widespread adoption. So it’s some stuff everybody’s heard about, and the bleeding edge folks are actively working with it, but the rest of us are kind of sitting on the sidelines going, let’s see how this goes. Hey. Is Eric on fire? However, in this case, Gartner does not think that widespread adoption is that far away. They are thinking that 80% of software engineering organizations will be using it by 2026, which is on the short end of their three to five year estimate. And it makes sense, because one of the ways to think about the value of platform engineering is to think about the before and the after. Developers, like I said, would need to either request or spin up their own infrastructure to host their applications. They would need some understanding paid to all kinds of other areas of the business. If it’s not the dev directly, somebody has to think about it for every deployment. We have to think about security, we have to think about storage, we have to think about networking, we have to think about clouds, in some cases glorally.

[00:25:52.450] Chris: And this means the development model slows down. The deployment is at least partly custom. And by that I mean unrepeatable. Do I have to say it again?

[00:26:07.990] Ned: Unrepeatable is bad.

[00:26:09.850] Chris: It doesn’t scale.

[00:26:11.330] Ned: Oh, that’s what you’re well, you repeated yourself then.

[00:26:15.530] Chris: Anytime there is standardization like this because of the silo we talked about before, it’s usually limited to the silo or to the specific developer. And this slows down collaboration and deployment times considerably. Here’s a fun, true story. For a complex three tier environment, this could realistically mean one to two months from initial request to first login. That sounds like a lot because it is. A fully formed platform engineering environment could do that deployment in an hour. Yes, because all those decisions had been made already. All the approvals are done. All the developer needs to do is select a template, get approvals, and click Go. So that is the end result that platform engineering is aiming for. All of that stuff that needs to happen still happens. Legal, compliance, licensing, even finance, everybody’s favorite, still gets their say. But the developers don’t have to care about that happens in the background, right?

[00:27:32.530] Ned: Yeah. To give it like this wasn’t platform engineering per se, but I was working on a project, it was one of my first sort of DevOpsy projects where we were leveraging cloud formation to automatically build environments for application testing and deployment. And we were doing it for like two different application teams within an organization and that’s as far as we had scaled. But the app teams loved it because they could have a copy of their application or a testing environment deployed in 2 hours where it literally used to take a week to build it.

[00:28:07.850] Chris: Right.

[00:28:09.450] Ned: Now you just have to take that concept and scale it out to the other application teams that existed in the organization and take into consideration some of the differences that they need in their environments and come up with sort of a standard self service portal and a way to keep it up to date and deliver it to the developers.

[00:28:29.890] Chris: Right. And again, the whole point of this is that it’s not just for engineering developers, it’s for the entire organization. Because, come on, how many times have you seen all right, well, we have it over here, but finance has their own guy.

[00:28:48.970] Ned: Right?

[00:28:51.210] Chris: No.

[00:28:54.330] Ned: If we go back to the DevOps principles of sort of shifting left and bringing people in on the process earlier, then that builds that big tent of it’s not just developers and operations, it’s security and finance and everybody. Getting in at the beginning and going, this is what needs to be included in the platform for me. And then having the platform team sort of make it so. And that could get into a whole tools conversation of how to make it so. But you really have to start with the core tenets and philosophy before you start picking tools out of the CNCF landscape.

[00:29:29.280] Chris: Right. With platform engineering, a company can pick their favorites, right? Because like I said, there are what’s the current count on CNCF? Is it 700,000?

[00:29:44.090] Ned: Well, it’s got to be 800,000 or 600,000, but yeah, darn it, I feel good about that.

[00:29:56.560] Chris: What was the question again?

[00:29:57.950] Ned: I don’t know. So in summary, in conclusion, congratulations, everybody. We did it. Platform engineering in under 30 minutes. Well done. Well, hey, thanks for listening or something. I guess you found it worthwhile enough if you made it all the way to the end. So congratulations to you, friends. You accomplished something today. Now you can wile away the rest of the day. Considering the relationships of engines and oranges, you’ve earned it. You can find more about the show by visiting our LinkedIn page. Just search chaos lever or go to our website, chaoslever.com, where you can find show notes, blog posts and general Tom Foolery. We’ll be back next week, or later this week rather, to see what fresh hell is upon us. Ta ta for now.

[00:30:48.490] Chris: If you really want to watch Chat Insane, by the way, ask you to.

[00:30:54.150] Ned: Try to rhyme complicated words more complicated than orange?

[00:31:00.050] Chris: Well, that was what triggered the idea, but yes.

[00:31:04.530] Ned: Well, now we have something to do for the rest of the day.