8. Platform Engineering Is the Revenge of IT Operations – Tech Field Day Podcast

It is all about the balance between structure and flexibility. And right now DevOps appears to be winning. But wait, platform engineering looks like it might be making a comeback.

In this episode of the Tech Field, a podcast, we look at the possibility that platform engineering is just the revenge of IT operations. Welcome to the Tech Field, a podcast, the only podcast that dares to be both on topic or on premise, and sometimes on location or on premises. Each episode, we bring together a group of IT experts in various fields to discuss a single idea or a premise related to enterprise it.

Before we jump into the premise for today's episode, I'd like to take a moment for our guests to introduce themselves. So you know what we're gonna be talking about, starting with Mike. I'm Mike Bazaar, chief Content Officer for Techron Group.

com and Cloud native now, and lots of things that are germane to this forthcoming topic. Mitch Ashley and I am principal analyst and run the tech strong research business, our analyst business, as well as CTO for Techstrong. Uh, one of our most popular items is the pulse meter where we pull our audiences on up and coming, or current analysis of topics and things like we might talk on this podcast right here.

Maybe we can do that someday. And lastly, a man who needs no introduction to the Tech Field Day podcast audience, but we're gonna make him do it anyway. Mr.

Steven FoST, I was just gonna refuse to introduce myself, but hey Tom, it's, uh, good to be here. Uh, I am Mr. Steven FoST.

Uh, you can call me Mr. Um, I, uh, am the, uh, organizer of the Tech Field Day event series, and I've been writing for Gestalt it for a long time. And by the way, if you're listening, you may notice that we got two Techstrong people and, and two Tech Field Day Gestalt IT people here.

Tom, what's up with that? Well, it's because we are now all part of one big family under the Futurum group, and we're very excited to be working with our friends over at the Techstrong Group on a variety of topics that are of interest to them. And likewise, we're gonna be cross publishing some content.

So make sure you stay tuned to all of your favorite Techstrong and Tech Field Day channels to learn more about that. Let's jump into the premise for today's episode. However, IT operations is a tale as old as time.

No matter who you are, you've touched it in some form or another over your lifetime, and we're always changing it. I remember dealing with the, uh, the wave of DevOps. Everything is gonna be different now, and I wasn't sure how I felt about it, but thankfully, the old adage is, we don't get mad.

We get even. And so the revenge of IT operations is gonna come courtesy of platform engineering. And I'm sure that I've already gotten somebody's hackles up out there because if you work with DevOps and you hear platform engineering, you're probably ready to leave nasty comments.

But there has to be a middle ground there, right? I'm gonna go ahead and toss this out to the experts in the field and see, you know, what is it that makes platform engineering the antithesis of DevOps? Well, you know, they say that the road to hell is paved with good intentions.

So let's dive in. Here's the thing. In theory, you have a bunch of individual development teams that have their own DevOps platforms and tools that they've been using to build applications.

And that creates a lot of friction, no doubt, but it also empowers them. The platform engineering advocates are essentially saying, we need to manage DevOps at scale, maybe reduce some of that friction and pull some of the costs out of the equation. But to do that, they're doing something called standardization.

This is something that centralized, it has always been banging a drum about for as long as I can remember. And I would argue that the reason we all embraced DevOps in the first place was to get rid of those people, or at least escape from them anyway. And now they're back with a thing called platform engineering that just basically is, you know, same as the old bosses, the new boss.

So Well, there, there's a, a multiple definitions of platform engineering as you're talking about standardized configurations, right? For dev test production, multiple production environments. There's also developer portals.

Um, increased improving security, improving overall performance, kind of winnowing down the tool set or the platforms that we're using. But hopefully it's all in service for something bigger, which is to get things done faster. Take some of that workload, take the drudgery workload that maybe developers don't wanna do.

What's interesting to me about platform engineering is the, one of the first things I heard about it was, we're doing this because we forgot about the developer in DevOps. We got so wrapped into cross-functional teams and doing workflows and pipelines and CICD and blah, blah, blah, blah, all that other stuff that we forgot. Developers are put really part of who we're trying to make more productive here.

And that's one of the focuses of it. So I, I think ably, there's, there's, there's something some to that. It kind of depends on how you're gonna look at the question, doesn't it?

You say, you know, we kind of forgot developers. I think a lot of the IT ops type people feel like they are the ones that got forgotten. And it, you know, like Mike was saying here, um, definitely I think that, um, the, one of the, the, the, the things that people loved about DevOps, but people not being IT ops people, was that it meant that they didn't have to deal with those IT ops people anymore.

They could just basically have their own software defined, uh, API driven, you know, infrastructure to run their, run their stuff on. Um, but if you're a DevOp or an operations person or if you're into IT platforms, you probably spend a lot of this time looking at that saying, well, that's not a really good platform. It's not standard.

It's a different, entirely different thing. You don't know anything about storage. You don't know anything about networks, you don't know anything about security.

Uh, but yet you're the one who's provisioning this. I think there's been a lot of anger, um, among the, uh, IT operations crowd. And yeah, I think a lot of those people are really embracing platform engineering because platform engineering means, okay, now that you're done messing around, why don't we get our act together and have decent platforms to run all this stuff on?

Again, at least that's kind of how it sounds coming from the people that I'm talking to. And the part that I give them some credit for is some, if I have a lot of individual DevOps platforms, it is hard to scale. One of the criticisms of DevOps is it just doesn't scale.

And you'll see that from the old fashioned idle community will say, we need something that is more, uh, structured in terms of workflows and the backend systems need to scale and otherwise we're never gonna get to the level of ROI that's required. But I do scratch my head every time I hear that phrase, developer productivity, these people are not working in a factory. They're not sitting there at the end of some bench banging out some sort of, uh, chair.

It's a, as much art as it is science. And so the fact that you gave them more time doesn't necessarily mean you're gonna see more software or better software because software, it's as much about inspiration as it is about the actual writing of the code. So I may just take that time that you're giving me and I don't know, I might play more games or whatever it is.

It doesn't necessarily mean I'm gonna be a better developer. Oh, for sure, Mike. We're gonna play more games.

I mean, part me That's, yeah, so there, there's, you know, you hear fancy words for like cognitive load and, and uh, interrupting people's flow, things like that. I think what, when you are a developer or you've been a developer, you understand that maybe like art, maybe it's not, but there's a certain level of concentration you have to get yourself so far into the problem of where you were at to pick back up where and begin moving the ball forward. Whether that's creative inspiration or it's just banging it out, trying to get it done.

You can't, you can't get five interruptions and go right back to it in most cases. It, it can when context switching between work or interruptions or all that kind of stuff, whether it's going and setting up infrastructure or something else, or arguing about what we're gonna standardize, getting back to that head space where you can actually be productive. That's what I think productivity is about, is giving people dedicated time and, and less interruptions, not lines of code per hour or whatever kind of ridiculousness we used to do.

Yeah. So what happens when I, as a developer come across some new cool tool that I want to try, and then there's some platform engineering team telling me I can't do that. 'cause I know what the answer from the developer's gonna be and he is gonna be like, my laptop, my development environment, I'll do whatever I damn well want exactly about it later.

That's exactly the answer. You think that's because we have standards. Why?

When did that ever change? Of course they could do that. They're gonna gonna play in whatever playground sandbox that they can do that.

Maybe it's on their development project that they're working on. Maybe it's not. But you can't have, you can't become the land of no platform engineering.

Meaning yes, you can use, yes, we'll, we'll standardize on anything you want as long as it's on our parts list. And that's what you get to use. People are gonna throw up all over that.

You've got to have a mechanism by which say, Hey, this, this is something we want to experiment with. We'd like to try it if it's something we think will at scale. What's our process for helping more widespread adoption if we think it is?

And you can't do 50 experiments a day and, you know, be distracted by all that, but you also can't say, well, you know, we, we open up between December 15th and January 1st where you can file your form for the next tool you'd like to use for the next year. I think that, uh, it does have a tradition of being, uh, a bit the land of, no, I mean, that was, I think the reason that DevOps appeared in the first place is because, you know, people like me were, uh, sitting there in the data center saying, no, no, no, we've gotta standardize, we've gotta use standards infrastructure. You can't have whatever you want.

And basically we said, no way too often. And the developers basically said, enough, enough is enough. We're done with this.

And, uh, you know, kind of the internet opened the door to a lot of Yes. Um, you know, and in a way it feels like, uh, you know, the IT operations world of the, you know, nineties and two thousands was the department of round holes. And, um, you know, no matter what shape your PEG was, that's what you're gonna get.

And I think that the efficiency of having a decent environment or a proper environment to run your operations on made a lot of sense when the, uh, when these cloud platforms were new. But now, you know, I am seeing an increasing, um, standardization. So remember, we're not talking about infrastructure, uh, engineering, we're talking about platform engineering.

And when it comes to platforms, I definitely do see an increasing, uh, interest in standardization and using standard tools, uh, from the developers as well, because I think that they're starting to realize, you know, back to your point Mitch, about the flow of development, I think they're starting to realize, you know, I shouldn't be messing around trying to figure out which database to use or which, you know, observability, you know, plugin or whatever, you know, I just need to freaking do the thing, right? And, and this one will probably work. So we can use that one.

I think they do want to, I I think maybe they're kind of learning the same lessons that the IT operations people learned, which is basically if, if the infrastructure is a total mess, if the platform is a total mess, it's gonna interfere with your ability to get, get stuff done. And I think that, you know, that's a, that's a positive, you know, I mean, we can be grumpy all day long, but it is a positive when people recognize that standardization is not a bad thing. All right, let's assume that this is the second installment in the Star Wars series and we're really talking about the revenge of the empire here and the empire strikes back.

So what's the third installment gonna look like? You're asking trick questions now. I think the third installment is Dune.

There you go. The spice must flow. Have you guys read those novels?

Because I don't think that that's a good paradigm to reorganize it on. What do you mean? Says, Says, says the IT operations guy.

It Is going back to silos too, a bit, isn't it? I'm the god emperor of the data center. You are.

Tom, I think redirect this conversation. Would you, well, I think you guys have hit on some very important points, is that developers, they, they chafe under restriction because they need to have that, that artistic mentality to develop all these cool things. And I, as you were having this discussion, I thought back to people who are car people, right?

Like they want to pop up the hood and they want to tinker with everything. And platform engineering is the reason why you're not just bolting random parts onto the system trying to figure out which one of these is making things not work when you're not a mechanic. It's also making sure that when you put this brand new part in to make things go faster, that you're not putting in metric bolts when the rest of your car is using standard bolts.

And then you're six months from now going, well, what kind of an idiot approved that? Oh wait, that was me. So we're fighting amongst ourselves because just like any family, you've got a group of people that want to follow the rules and provide structure so that things are easy to deal with.

And then you've got a group of people, we'll call them teenagers who chafe at rules and want to do whatever they want until they get to a point when they realize, oh yeah, having rules might have actually made a little bit more sense and kept me from doing things I might not have been able to. So where's the middle ground? Here are the platform engineering people going to have to just decide, well, what we're gonna have to give in on every little thing and hope that people learn eventually that that our way is best.

Or are the DevOps people gonna have to take a step back and go, maybe I shouldn't be switching my tool chains every six months or switching languages that I'm writing in every three months, just because Google decided that they wanted to rewrite the entire search engine in rust oxide Today. I, I, I have a third vote. My, my, my third vote is, can we just have better tools and platforms, please, you know, maybe throw some of this AI crap in there and then we don't have to have this conversation about platform engineering because, well, the tools and platforms should work the way they're supposed to.

And right now it's pretty clear they kind of don't live up to the promise. So maybe we just need a new rev of tools and platforms that are designed to run at scale. Let me jump in on that, Mike real quick, because one of the, and this is a problem that I've had going all the way back to my Linux days.

If I run into a problem, what's my solution? Is my solution to fix what's broken and develop the ecosystem better? Or is it to drop what I was working on and just find a new tool that does exactly what I wanted to do, but it doesn't integrate with these other three things that I've been working on, which means now I have to go figure out how to make all those other things work with this new thing.

'cause it does what I want. And then, oh, wait, by the way, that guy's not gonna develop that tool anymore because he got a job working for Microsoft. That's when the engineering manager steps in and says, uh, I think we're in the software creation business, not the tool integration business.

So here's where we need to focus, or No, that's a big enough problem. Let's go work on that. Let's fix that because that's gonna make our world better.

That said, people are gonna go to go off and do what they wanna do. What, what I wanna propose, Tom, is that the middle ground is something like this. Let's dev ops, the, you know what out of this, right?

Like the Martian, um, is, is it isn't about platform people going away or operation people going away and say, okay, here's our platforms. This is what we're gonna define them as, and we're gonna use these, these technologies and these tools and this is what our DevOps tool chain looks like. And then we're go back to the developers and here you go, okay, that'll go over real well.

No, what you say, what you do is you, you get the developers, the DevOps people, the platform engineering people team and say, what is our biggest set of issues? What are the things gonna make the biggest difference if we did something about it in the next week, weeks, month, whatever it is that's gonna move the needle for have your whatever metric, right? Our ability to get an environment spun up quicker so I can start a project ability to switch, switch between environments for the same application that are running in for different customers that are customized, blah, blah, blah.

What are, what are the set of issues? And then that's work on that. 'cause then you're gonna have the developer saying, you know, I've, I've always wished somebody would fill in the blank and now somebody is, right?

So it's those kind of problems that developers say, I don't really don't want to mess around, but I have to. I wish somebody would. And then let's work with the platform engineering to figure out what those things are.

It sounds idealistic, but honestly that's how it's gonna work together that otherwise it's gonna be one big, you know, what match, Which sounds great. And then we put Kubernetes in front of the developers and they go, what the No, we put in front of operations. And they also go, what the, There's a real, another really interesting trend here though, and that is the emergence of all these companies that are basically making, uh, consumable digestible versions of really difficult platforms.

I mean there's basically, that's the new open source business model, isn't it? You know, you, you've, you've pick a, um, a crazy over the top Apache license thing that was developed by, I don't know, goog Flix. And you decide that I'm gonna make an enterprise consumable version of it as a platform and sell it as a service.

And there's a ton of companies out there that are doing that. How does that jive with all this stuff that we've been talking about? Because if platforms engineering is so great, why are people buying enterprise version as a service products anyway?

Well, they're buying things like everything from GitLab in the cloud and GitHub and they're already using those services in the cloud. So I would argue that that is a better mousetrap. I think more and more of that stuff will be consumed as a service per se.

'cause I'm really just trying to get to the capability. Then I'm kind of gonna invoke through, uh, some sort of API that's ex exposed and then I'm gonna stitch a workflow together around it. That's a perfectly legitimate way to go.

There are folks out there that have on-premises environments to Tom's point, and they have data that doesn't necessarily let them go do that. But I can put maybe the control plane for that in the cloud and I can leave the data in the workflow on premises. It's not always gonna be one or the other.

I can have something that's more hybrid. I think there's, there's a couple, you're talking about a couple kinds of platforms. One is like a GitLab is a, is is, I would consider a platform where it is multifunction across the lifecycle of, of software development lifecycle into operations.

It isn't everything of all pieces of that, but it's a lot of pre-integrated components of that that you can choose to live in just that environment. Or more than likely you're gonna want to integrate some other tools and things that you're currently user using or things you wanna expand to. But it's that control plane.

It's that kind of base that things are built on. A lot of it coming from the same vendor. What, what you're talking about, Steven, is, let me create a blank as a service version of some open source product, right?

Which even even companies like, um, cloudish just announced that a while back here where they're running out running, uh, Jenkins as a, as a service in the cloud. So if you, you really don't wanna spend your time messing around supporting Jenkins and upgrading it and tweaking it and tuning it and expanding it and trying to figure out how to scale it, which is, which had, which had been an issue until some recent releases. You can move it to the cloud version.

So if, if it works for you. So that, I think that a lot of that is just Kubernetes is the perfect example. Like take the complexity away.

Just run it for me. I don't wanna have to deal with at least administering it and setting it up. The issue is we call that an opinionated instance of something, which is to say it's configured and set up the way you think it should be for everybody else.

And everybody else looks at it and says, I have a different opinion. So they go do something else anyway. And and part of the issue with a lot of the, as as a service platforms is there's some vendor's ideal configuration and when they get to the actual IT environment, the IT environment goes, that's not ideal for us at any level.

Yeah, that's true. 'cause uh, you know, what they say about opinions. Um, and, and I will say too that one of the other aspects of those companies is that a lot of those companies are offering, um, additional services, additional capabilities on top of the open source version.

And so you could see a situation where somebody might say, I don't like that company's opinionated version of let's just say Apache Cabernet. And so instead I'm gonna use, uh, you know, this other thing, but wait, but wait, their version includes like these 12 features that aren't part of the open source version and we really do want those in our business. You know, well what am I gonna do now?

Right? And it's, it's challenging because I feel like that kind in a way that kind of flies in the face of platform engineering because I feel like it's supposed to be bringing this stuff more under the control and under standardization and this kind of makes it little offshoot over there. But at the same time, I dunno, maybe that is platform engineering because you know, you do have at least somebody taking that workload off the, the devs.

Uh, So we, we call that putting a fork in it, right? Basically we go out and get 12 of our buddies and we extend it and we keep the core and then we have these extensions and then we offer the extensions back to the community if they want 'em. If not, we'll do it ourselves.

But, um, you'd be amazed at how many forks there are of open source projects that are running out there that are all slightly de slightly deviant from the core. You know, I'd argue that that this kind of call it a platform in a box, uh, approach to things is actually the ultimate in leveling the playing field because the platform engineering slash IT operations people, they don't wanna support every tool out there. They want something that's predictable.

And the platform eng or the DevOps people don't want to feel the structure of not being able to choose what they're working on. And so a third party, we'll call it maybe like a stakeholder or the people with the budget go, well, we're gonna use this because it's guaranteed to make you both somewhat happy and somewhat unhappy. And there's no better example of this to me than Salesforce.

I don't know anybody who's pleased to use Salesforce because it requires everybody to completely rearrange the way that they do their workflows. But it causes two things to occur really fast inside of an organization. One, you realize that your workflows might have been busted in the first place if they don't match up very easily to what a platform like that offers.

But two, it makes you realize how valuable the customization aspects of things are where you're like, why does it take me 18 steps to enter my name on this project when I could do it in three or four? And that actually can force the teams to come together and go, listen, we may not agree on a lot, but we both agree that whatever that platform was sucks and we need to get rid of it. So is there a way to create something with these kinds of seeds to bring people to a consensus by saying, we know now what we need to identify as the key important things in this project to make sure when we do it, that we're going to get the needs met for everybody.

So what you just described was the United States Congress, and I don't think that really works too well in an IT environment. No. What, what Tom just showed me is that he's worked in IT before.

'cause everybody thinks all the products and tools we use suck. I'm serious about that. I mean, there is some argument to say, you know, every, whenever, whenever you've got a compromise significantly, obviously you're gonna not like it, but you'll live with it because it works for enough people.

And you can, you know, other than for Mark Benioff who all of Salesforce works really well for, you know, for the rest of it, it's a, it's a compromise. I I, I think the, the one thing we always esti underestimate is that every tool, every product, every system has a way of working. It has a model of how it was built and what it assumed about how work is performed.

If you're talking about a Salesforce, right, it's, it's origins were in CRM and it does a lot, lot, lot more than that, but it's built on the structures of what they created. The CRM, you could say the same thing for Atlassian and Jira, other we're now a workflow tool, right? But started out as a ticketing system, it carries a lot of that heritage with it.

My point being is you can't make Jira act like Salesforce and Salesforce act like Jira. Salesforce wants to be Salesforce the way it does things. And so you don't get, you don't get to democratize how we're gonna do things just 'cause we have a workflow or an automation tool.

Um, you, you have to, you, you are best off if you try to use it the way it's used best and adapt where you can your processes and throw, throw out the bad ones. 'cause you didn't wanna automate those anyway 'cause we're just wasting your time automating something that wasn't work working and adapt the good things to how the tool will best support it. And I think that's something we, we overlook a lot.

Even has it become a benevolent dictatorship then? Is that the best we can hope for? I think the best we can hope for, yeah.

Is a, uh, yeah, a, a god-like dictator who can, uh, force everybody. No, honestly, I think that, I think that the Salesforce analogy is a really good one because, you know, Salesforce is, you know, one of those, one of those platforms that I think people kind of love to hate, but at the same time people love it and why do they love it? Because it does the stuff, if you put enough into it, it can do the thing.

And the thing that it does is actually very much in line with how businesses, um, or especially the sales side of the business works. And I think you could say the same for other popular platforms. I mean, if you look at, for example, slack, one of the reasons that Slack has been so successful is because, I mean, it's not that different seemingly from 10 other competitors, but Slack kind of speaks the language of that thing that you're trying to do the best way possible.

And so I do think that, honestly, I think platform engineering, if I can be a little serious here, I think platform engineering is the exact opposite of an, of a dictatorship. Because truly what happens is that companies, um, they figure out which platforms make the most sense and speak the right language for their development needs and then they standardize on those platforms. And no, nobody ever really, really loves them and everybody sort of chafes a little bit, but I guess the one that you chafe the less on is the one that's right for you.

And you try to standardize on it. Because I think everybody at all times realizes that you can't have the best possible tool for every possible task. Sometimes you do have to have some, some, some standard generic suboptimal, but still pretty good tools.

And I think that, that people kind of find their way around and we're all kind of feeling our way around blindly until we find the right corner for ourselves. And I, and I think to me that's the essence of platform engineering is, you know, the developers have kind of blindfolded themselves and, you know, bundled, bundled around in the whole world of, of it platforms and eventually they've sort of all clumped together over in that corner. So I guess that's our platform, right?

Am I wrong? I think what will happen in that set of circumstances is the developers will go home, they have enough money, they'll buy their own laptops, they make their own development environments, they'll set it all up offline shadow, and then they'll code away. And then they'll bring, when they get to something that they think they, they like, they'll bring it into the office and upload it onto the official machine.

And of course, you know, we'll have that same old, you know, well it worked on my machine, and then they'll go, which machine? And then they go, 'cause that's not a company machine and we're we're as far off as we ever were. So I I, I feel like we need something that's a little more developers gotta buy into it.

If they don't buy into it, then it's just, you know, more noise from corporate. I don't, I don't disagree with that, Mike. I think, I think, I think ultimately, and this is what I, where I was trying to get at before is there's, there's nothing to what you said, Steven, that everybody is gonna be head over heels positive about it.

But you have to get enough buy-in to say, can ops can platform engineering, DevOps, development, test, whatever, security, you know, whatever the cross-functional needs are, can we all get on board with supporting this and making it happen? I know it's not tool of choice by a couple of folks, but for all of us, are we in agreement this is that we're gonna make this work? Not that just that we're gonna use it, right?

We really need to be committed to making it work. And you know, when we run into issues and problems, we're gonna surface 'em, we're gonna work 'em together. We'll help we figure out the best way to handle the educations of the things that it's not good at work, work from there.

I mean, I think that's the, that's the best scenario you can put together because otherwise it's just gonna be another set of silos that everybody's fighting and gone off and done their own thing again. Well, as you can tell from this discussion, there's a lot of nuance in the way that things are done. You know, we have the one side who wants a little bit more structure and control and they say that things must be done our way if you want us to support it.

And we have the other side who loves a little bit more flexibility and well call it chaos says fine, do your things your way and I'm gonna do my things my way. And when everything works out, I guess we'll all be happy in the end. But the reality is, is that this discussion is no different than any other discussion that we've had in it over the years when it comes to one group of people who have decided that the, this is the way that things need to be done because it's the most predictable and stable.

And another group of people who says, this is the way that things should be done because it's the most efficient for being able to do what we want to do. And if you find yourself on either side of that argument, realize that in five years you're probably gonna be on the complete opposite side for one reason or another. And that's okay.

Because when you have the perspective you can tell your teammates, you can tell the opposing team why things work better one way versus the other. That'll just about do it For this episode of the Tech Field Day podcast. Remember to tune in and follow along every week.

com slash podcast. You can also subscribe to us in your favorite pod catcher. If you do, please leave us a rating and a review so people know what they're getting themselves into and they know to look for the premise in every episode.

This podcast is brought to you by Tech Field Day, which is a part of the future and group. com. We'll be back next week with another great episode.

Until then, make sure you stick to the.