DevOps in the Age of Platform Engineering – Jim Douglas, Armory

This is Textron tv. Hey guys, thanks for the throw. We're here with Jim Douglas', the c e o for Armory, and we're talking about DevOps, whether it's dead or whether platform engineering is just the latest incarnation thereof.

Jim, welcome to the show. Mike. Thank you very much.

Good to be back. I'm tech strong. There's all this noise in the system about platform engineering.

It's the next great thing. And my question to you is how do you define it? 'cause some folks think it's the replacement for DevOps and others are like, well no, it's just the next iteration because well, we're all maturing Maybe the oldest thing in the world.

That's how I define it. It's been around forever and I wouldn't even call it the next thing. It's an augmentation, do a sound DevOps strategy.

Um, let me monologue for a second. I'll kind of back my way into it, but I'll be quick. You know, go back before kind of electricity, you know, 20, 25 years ago, um, before the IT teams were really part of the value delivery and value capture process.

You know, organizations were very stovepipe. You had developers in one hand in one org and you had operational folks that kept the computers running in another org. And that all had to change once the IT teams had to be part of, as I said, that delivery and the value capture process, i e e-commerce.

And so organizationally you started to, things change, then eventually you had to drive better communication and collaboration, build new processes and eventually start to automate those processes. And that was really the start of DevOps is how do you make that whole flow more seamless and how do you continue to optimize it? And it continues to be the case and it will continue to be the case forever.

People will come up with new names to call it, or new adjuncts to DevOps. But at the end of the day, people are constantly gonna try to improve and optimize the overall software creation delivery. And as I said, capture process platform engineering is a newer term, but there's always been terms for teams that have been building tools to help augment that process.

And I think the thing that's changed and why the term platform engineering came about is these teams used to have to either completely build custom tools before the market had produced commercial tools to really, um, if you will, automate parts of that process. Or they had to supplement commercial tools with a lot of customization. As I said, these groups have had different names forever.

Heck, when I started my career in software, I was in the cadcam domain electronics automation. And we used to have to sell into these groups called CAD groups or CAD managers. And they essentially were platform engineering teams that were building out a suite of tools for their designers.

And that's what platform engineering teams do today for people that are designing applications for changed since they moved from doing a lot of custom work to doing more integration and then building abstraction layers to create more efficiencies for developers is that process has changed from being a project and moved into being a product. I saw somebody a while ago wrote that line and I'm just absolutely stealing it from 'em. Uh, because I thought it was very descriptive of kind of the sea change where today these platform teams have this ongoing product that they continue to develop and advance and really focused on building more productivity and more efficiency for developers.

So think about it once again, it's just augmenting a good solid DevOps practice and good DevOps automation by creating a platform that is really gonna aid developers being more effective. There are some folks who are a little cynical and say, this is another attempt at the revenge of centralized it. So how do we kind of strike a balance between those cherished freedoms of innovation that we have and the tooling side and some sort of adult supervision?

Yeah, well I think in general all organizations kind of ebb and flow between centralization, decentralization, and the kind of technology domains are no different. Um, I think what you find is most organizations, these platform engineering teams, um, are building best practices and trying to deliver best practices to the dev teams. But in general, the dev teams still own and are accountable for what gets deployed.

And so they still have the power. The platform teams, I said, are just ensuring that those best practices are used wherever possible and doing everything they can to do two things, ensure that reliability, um, is met in terms of the objectives for the company. And the second thing, as I said, is just improving the developer experience.

So yeah, there always is kind of a ebb and flow of that relationship, but the developers at the end of the day are really, as I said, accountable for the work product that their customers are actually consuming. Um, so I, I don't see that happening. I think in most cases what we see in organizations or in the platform engineering teams offer up tooling and best practice to developers, um, as guides and once again as tools and the developers consume what works for them in different lines of businesses and big organizations.

Uh, but rarely is it draconian. I've seen very few examples where it's, it's so draconian that hey, not only are we gonna develop all the tooling, but we actually own the deployment of code. You just tell us what you want deployed, we do everything else and thou shall never touch that part of the SS D L C.

That's pretty rare. So I, I don't think we're gonna see that. Like I said, you see a little bit of ebb and flow each way, but in general, um, there's a good symbiotic balance between the two organizations and the dev teams generally since they're accountable, they've got the last say.

One of the longstanding criticisms of DevOps is it doesn't scale well. And you still hear idle folks out there saying, you know, idle scales, it may not be as agile, but at least it works Reliable DevOps folks, Hey, it's all about being quick. Is this an attempt to kind of get to the middle?

Well, I think it's a misnomer too. I, I think and that's one of the reasons that platform engineering as people are defining it today really gets a lot more attention because a lot of focus is on kind of that last mile of automation that is necessary for DevOps to really scale. Um, it's even more important in large organizations 'cause you have way more moving parts.

The problem is there's still holes in the automation of an SS D L C where there's too much kind of man in the middle in terms of critical pieces of that handoff between organizations. And that's a lot of what platform engineering's trying to address in a more systematic way, um, where they're adding in that last mile of automation that does make it scale. So that's where it really is, um, augmenting the capabilities of organizations to use DevOps effectively.

Do you think this will also lay the foundation for applying AI to DevOps? Because we see a lot of AI tools being used to write code, but the folks that are on the receiving end of that don't seem to be benefiting quite as much just yet? I, I think in two directions, absolutely.

Um, I'm a big proponent of it and I've argued with a lot of people about how soon it's gonna take hold, how big of an impact it's gonna be. You know, I think folks like GitHub are on the right path with copilot, typically you find abstraction moving two directions. One is going be kind of vertical, um, adding abstraction layers for developers so they can operate at a higher level of distractions, they can be more productive.

And I think you're gonna see AI as you are in the form of products like copilot, um, improve very, very quickly as more people use 'em and allow developers to work at a much higher level abstraction than a JSON file or a YAML file where they can really describe outcomes, um, rather than trying to describe in detail what they need execution to look like. So I think that we're gonna see take off pretty rapidly in the next few years. I think the other part is think more horizontal as you're deploying code.

Most of optimization, whether it's manual or through using tools to automate, is more focused on reliability and stability. That's the real vector today. And it's ensuring that whatever you deliver to customers is gonna work and work as advertised.

You don't have downtime. If you have downtime you can remediate either automatically, instantly, or rapidly such that you preserve that customer experience. It's not the only variable people should be looking at.

Right? There's other variables as well. Um, cost is one, right?

So maybe you're willing to give up a little bit of reliability if you could drive a much better cost envelope. So I see AI kind of at that point of a lifecycle as well, where as you have more and more operational data, you can start to add more variables into the mix in terms of what you wanna optimize for. I think that's gonna be kind of a longer, uh, pull in the 10 if you will.

The immediate one. I think we're on the right path relative to adding a higher level of abstraction for developers and I think that's gonna have a big impact. Should I arrive one morning until everybody that we're doing platform engineering or should I just maybe build some better portals and let people discover these capabilities and then after a little while I can go, Hey look, no hands, we're doing platform engineering.

Um, I think once again, don't get wrapped around the axle on the terminology. I, I think everybody wants to create the new wow thing. So they gotta come up with a new term.

At the end of the day, the folks in those organizations are focused on two things. It's developer productivity, so building a platform set that's gonna continuously add productivity. And then the other thing is how to onboard people so they can reap the benefits of that productivity.

That's one of the biggest and most kind of concentrated effort you see from all the platform engineering teams we work with is how can we improve that onboarding experience. So kind of two flavors of user experience. One is once you're actually on the platforms and really leveraging the automation, what does that look like?

Is it easy, is it intuitive? But just how do you actually address it? So how do you get on board these platforms and really adopt 'em?

Um, so I wouldn't get wrapped around the axle on the name of that org. I think more how do we continue to improve the tooling that makes up those platforms today and back on the path we run before? How do we continue to add higher levels of abstraction so developers don't have to be down in the weeds.

They can focus on what they do best is what architecture is gonna yield the best outcome and then have technology that's gonna help them implement that more effectively going forward. Speaking about not getting wrapped around the wheel, did we lose sight of developer productivity as an issue in recent years? It seems like maybe we obsessed about a lot of DevOps metrics but maybe forgot that the developer was the reason we all exist, right?

I think so a bit. If you look at Dora metrics, so you can kind of bid 'em out two directions. One direction would be around developers where you're looking at, you know, how fast does it, you know, how fast can you be ready to commit code, what velocity can you actually push code out?

Those are definitely developer centric. The other side of that coin is more operation centric, right? How fast can you remediate issues?

How often do you have issues? So I think we totally lost it, but we've been spending more focus on operational issues than developers. But I think we are seeing that swing back and I think a lot of it once again is some of the new tooling that are coming out in a developer space that are, you know, front and center focused on that whole developer productivity.

And more and more, as I said, the platform engineering teams, back to what you asked before that power struggle. Um, you only have that power struggle where they lose sight of what their job is and their focus. Um, if they think their job is control, they're greatly mistaken if they think their job is delivering value to their customers, which are developers.

Those are the folks that are building great organizations and you see more and more of kind of the really elite companies, um, really understanding that more and more and more attention is getting pushed where it should be on the developers and really helping them be more effective Speaking of jobs. And no one in these days who's seen anything about AI doesn't have that thought process in their head. Heck chat G P T could be a c e o one day.

Right? Um, Absolutely. I'll be chairman.

So my question then is, you know, do software engineers need to be concerned about their future? What does that look like and what role are they gonna play? Technology is always a disruptor.

It just changes kind of focus. It has since the beginning of time. It certainly has my entire career and this isn't the first technology that people thought was gonna displace humans, right?

Um, it's just a little bit more radical when you think about it 'cause you can apply all your sci-fi thinking to it about kind of what the future could look like without man in the middle. Um, the reality is it's back to what I said about 10 times now. Abstraction, abstraction, abstraction, you know, from the beginning of computer programming.

And we started at an assembly language because it wasn't very efficient to write ones and zeros that a computer could consume. So we created this abstraction layer called an assembly language and we kind of kept going up in terms of abstraction layers from a developer standpoint, this is just gonna be the next level of extraction and it's just gonna enable developers to be more productive at the end of the day. You know, people can still define the outcomes best, um, but tooling's just gonna get better at helping 'em actually implement those outcomes.

So well we see a shift. Sure. You know, you're gonna see a shift in where people are applied in that process.

But in terms of wholesale, job elimination, yeah, I don't think so. In general, certain functions absolutely. Um, but new functions will pop up.

Do you think that maybe we're on the cusp of approaching a level of innovation in terms of how quickly we can build applications and iterate on 'em, then the business can absorb. I mean, how are we gonna be on some new x some new curve that's people aren't really thinking through the implications Now? I love that question because I think that's been a challenge for a few years now.

Um, just look at kind of technology in general and how good it's got and how fast it's evolved. You know, think about Moore's laws, the underpinning to that. It used to be from a compute standpoint every three years absolutely you would upgrade, every corporation would upgrade every PC in the building or Mac in the building.

And then that went two years. We're at a point now if you look at things like phones where people just aren't migrating the next new thing as fast because they're so good and software falls in the same bucket, right? Um, it is so good at what people need in terms of base functionality that just because we can go faster doesn't necessarily mean people will be prepared to consume it.

So I think that is a good question. I don't have a great answer in terms of how the shape of that curve's gonna change, but I think businesses do need to look at that, uh, because there's a cost associated with building new innovations and if you're delivering things that people can't consume, you know, that's not a winning formula. So don't have a great answer, but I think you're on the right path there.

I think that's probably the bigger issue is how do you kind of translate that if you will, value creation into kind of value capture. Um, it's been pretty straightforward the last kind of 20 years because of deficiencies in technology and you could just make leapfrog progression in terms of the value you could actually deliver what you're leading to is that starting to slim? Now with that said, we go through those ebbs and flows too.

Um, and I think we'll see a step function probably, you know, five to 10 years from now as people really understand how to apply AI better and we're gonna be able to create a lot more value out of it versus fairly pedestrian things we're doing today. Interesting things, but fairly pedestrian. All right folks.

Well, you heard it here. It's time to buckle in because it's gonna be a wild ride for sure. Jim.

Thanks. It's funny. One, one funny thing to tell you.

I got did a Bloomberg interview probably eight years ago asking me about AI displacing jobs and like doomsday scenario that within the next two years that all developers' jobs are gonna go away and potentially, you know, assembly workers' jobs are gonna go away because of smart equipment down on factory floors. Um, so same thing I said that I'm saying now, it's gonna change the landscape of employment, uh, but it's only gonna make it better. But people will have to get new skills, um, retooling in some cases in terms of how organizations are built.

Um, but at the end of the day, it's gonna make us more effective. All right folks. Well, you heard it here.

We're gonna have to buckle in. It's gonna be a wild ride. Jim, thanks for being on the show.

A fun ride. Thanks. Appreciate it.

All right, thanks the studio.