Unlocking the Power of Platform Engineering in IT Management with CNCF Ambassador Andreas Grabner | KubeCon SLC 2024

This is Textron tv. Hey everybody. We're back at CubeCon in Salt Lake City and we're talking with Andreas Grabner, who's technology strategist for Dynatrace and co-author of this great new book called Platform Engineering for Architecture.

You should all check this out 'cause well, everybody's talking about platform engineering all of a sudden. Andy, welcome to the show. Thank you Mike for having me.

All Right, so that's the first question in itself right there. Why are we all suddenly talking about platform engineering? And in your mind, what is fundamentally different from how we've always managed it?

We've been talking about DevOps and programming, programmatically managing IT infrastructure for years. What's changing? Yeah, Well, maybe, first of all, I think what we're doing now with platform engineering is not completely new, but maybe the world industry needed a new term.

The way I see it. Uh, we always see technology shifts, right from the on-premise monolith to a more decoupled, uh, architecture moving into the cloud. Now Kubernetes, well, who knows what comes next and every time a new technology is get adopted, at least that's how I see it.

And what's also in the book is, uh, individual teams try to figure out how does this technology work for me? How do I build, how to deploy? How to observe, how do we operate as these technologies become more, let's say adopted and more stable, more teams within a large organization maybe also adopted, and they then try to figure out, okay, how do I do this?

Oh, I should just copy something from this team, then I'll do something a little specific to me. So in the end, fast forward, you end up in organizations that have many different ways to do the same thing on the current technology stick, which in the beginning was good because it spurs innovation, but in the end you're doing a lot of duplicated things, a lot of wasted time. And so platform engineering tries to reduce that wasted time by centralizing the expertise that individual teams have about building containers, deploying it on Kubernetes, monitoring and operating it, and make this available to everyone in the organization through a central platform, which is basically a product for your, your engineers to get to build, to deploy, to operate.

Yeah. How will this be different than what it used to be? Like?

A lot of folks embrace DevOps in the first place to kind of get out from underneath centralized it, and now we're kind of going back towards that model. So how do we kind of strike a balance between, um, the freedom that people like to have to experiment and innovate and not be beholden to a platform engineering team that says, you know, thou shout all the time? Yeah, so First of all, you know, I used to be, I used to call myself a DevOps activist.

So when DevOps has been a big, big thing, I was also promoting the whole shifting left to do it. You own everything end-to-end, but it's scale DevOps. You end up in a situation where you end up with a lot of duplicated efforts.

And I think all, and I mean you've been around for quite a bit, you just told me earlier you started in 82 with this business. I've been around since the late nineties. So we always see this pendulum, right?

More autonomy, we like to do everybody, everybody can do whatever they want, complete freedom, and then we bring it back again. And I think the balance strike is now, and this is a platform engineering, I think might be a little bit different, uh, when you do platform engineering, right? You're building a platform as a product.

It says you're crafting modern platforms as a product. As a product means I need to build something that my internal users really want. I need to create a desire for my engineering teams to use my platform because it helps them, not because it constricts them to only one thing, but because it takes, uh, something that away from them that they don't wanna do.

Like, you know, maintaining pipelines, maintaining configuration for observability, security and so on. So I think what's important now is that modern platform teams see the platform as a product, which means it needs to provide value so that people wanna come to them and they also need to craft the platform in a way so that it doesn't constrain people and not going a little bit left and a little bit, right? So we hear a lot about these golden paths.

So platforms should provide golden paths, but still have a little side door if you wanna do something a little bit different. So I think that might be a little bit a different approach, um, on what I see now with platform engineering In that regard. It almost seems like we're trying to treat the developer as a customer and create this product, but if I'm selling them a product per se, I have to make sure they're happy.

And I, I think in the previous iterations of all these efforts, we didn't always focus on making the people happy. It was just more like, here it is and this is all there is to it. And you know, you can have this car in any color Exactly.

As long as it's black. Yeah, exactly. And, uh, there's two things I want to add to this.

It's not just a developer, I think it's everyone that is involved in the development, in the, in the testing, in the operating of software. So that means the platform is also good for your site reliability engineers, for your quality engineers, uh, for everybody that really, you know, supports the business to operate well. So that's one thing.

And the second thing, what I believe, to your point, uh, whoever the end user is, when we build a platform, we first need to understand who is the end user, what is the problem, how can we solve it? And then how can we take the success of them to make more people within the organization use it? And in the end, it comes back to classical product engineering.

Mm-Hmm. When we create a product, we want our product to be better than other offerings out there. And we do it by solving particular problems from the users that we know once we solve it and they're happy, they become our advocates.

And that's also one of the things we write in the book here of like, um, understand the user the pain, solve a problem, and then make them become your advocates so that more people will use the platform, but also architect the platform and in a way so that it, it's not constraining, but it's also open and gives, gives more, more, more reasons for other teams to use it as well. We were having this debate yesterday, how big is the scope of these efforts? Because some people will say platform engineering is about managing DevOps workflows at scale, full stop.

But I look at it and I wonder, are we gonna be pulling in all the database people, the IT service management people, or all the silos finally gonna kind of converge a little bit more than they have historically and we'll be a little more cohesive? Yeah, I wanna quote, um, ThoughtWorks, I always use that quote in my presentations when I explain platform engineering and uh, the quote goes, platform engineering is the centralization of expertise. Your, your da your database experts, your observability experts, your security experts, they're all experts, but if you have them incentive of excellences, they're silos and then they become the bottleneck if I always have to go to them.

So this is why platforms is the way to centralize the expertise, making it available as a self-service platform to, uh, to foster and increase the innovation of the people that are using the platform so that not everybody has to become a security observability expert, and not everyone has to go to the center of x, Y, Z to do their job. So I think one model is that you look at the different experts in your organization and bring their expertise into the platform and make it as simply available as a self-service that is always corner cases where you need the database expert to look at your configuration. So they also become mentors, but the idea is they provide their expertise as part of a, of a product feature, as of a capability of a platform.

Everywhere you go these days, somebody's talking about ai. Yep. Do you, as I look at ai, it kind of takes a village to build anything.

I gotta line up my developers, data scientists, data engineers, security people, and all these things. Will AI essentially force a platform engineering mindset? Because in order to go build these things, we need to kind of have a more centralized approach.

I mean, if you look at a keynote from today, right? That is exactly what the folks have shown. They're building platforms to make everyone easier, leverage the AI models to do the data calculations.

To do the predictions. Exactly. It's the same, right?

So you have individual experts in, in parts of that domain, and you can centralize this and make this easier accessible to everyone in the organizations that need to use these AI capabilities without them having to be an expert on how to train the model, right. Making sure it's secure how to, how to use it. So that's, yeah, that's engineering everywhere.

It seems like there's a lot more focus these days on developer productivity. As part of this conversation, we've always worried about developer productivity. So as you kinda look at all and how this is coming together, um, do the developers themselves feel less productive, do they Or, or is it more of the business side is just trying to get more out of a limited resource?

I mean, who's kinda wakes up in the morning and has this kinda aha moment? No, I think the developers definitely feel it because I talk with a lot of developers and many are frustrated with having to do things, having to wait on somebody approving a ticket to get some stuff done. The state of DevOps report, which is a renowned report that came out in over the last years, the latest edition of platform engineering, I think came up with a number that, uh, only 40% of engineering time is spent in productive activities.

But another number, which for me is more shocking is that 36% of developers say they're going to leave the organization because of bad developer experience. So if you're le, if you're losing your best talent because you make it very hard for them to get that creative work, kind of, you know, influencing the next software product that they build, and if they're leaving, that's, that's a bad thing. It takes a very, it takes a long time to hire new people to train them until they become productive.

So to answer your question, developer productivity is a problem. Individual developers feel it there because they leave organizations and organizations also feel it because of the additional costs, longer release cycles and people leaving needing to hire and onboard them again. Yeah.

You've talked to a number of organizations that are implementing platform engineering. Are there any common things or traits that they're doing that you're seeing that you maybe other people should be copying when, what is it that makes for a successful platform engineering initiative? Yeah, There's only one advice I have, right?

Because you don't wanna make that mistake if you don't do it. Start to listen to your developers or to your engineers, find out what their pain point is, and then build a platform. Don't build a platform because you are here, the conference and everybody talks about platform engineering.

Don't just go off to build something where you try to solve a problem and don't, and then you don't have anybody that actually has a need to solve this problem. So, coming back to what I said, what we also said in the book, crafting modern platforms as a product, find your end user, find their pain point, solve the problem, then they will come and don't do it the other way around where you build something and then you hope somebody's using it. When I look at it, almost, I view it kinda like platform engineering is almost like a social contract between the IT people and their end customers that they're committing to.

Um, how do I get the developers to buy into that? 'cause a lot of the times they're so used to just saying, you know, they have the skills and the resources, and they're like, nevermind, I'll just go do it myself. But then they become part of the problem.

Yeah. So I think two approaches to this. On the one side, if you're building a platform, you wanna make sure whatever you build, you fit it in, into their existing way of daily work, right?

Developers are in the right, they are in the git, they look at certain tools. So whatever you build, you wanna make sure it seamlessly follows their basically day-to-day work. So if the platform provides an easy way to provision infrastructure or deploying something, maybe make this available as a command line interface in the right e or as an extension to the IDE and not make them go into a completely different tool.

That's one thing. The second thing is, if you have developers that wanna, you know, change things, they're building something on themselves already, invite them to become part of your platform engineering team, not only as the end user that you interview and what you want, but also bring them in. Because in the end, modern platform engineering is about building a product, a software product that contains many different moving pieces.

But essentially it's a software product. No, no. It couldn't be better that you actually get developers that wanna help you build that software product by stitching together ci cd security observability, right?

It's, it's a perfect world. So you work for Dynatrace. Where does observability fit in this equation?

Where do I, what it, does it sit on top of the platform? Is it embedded everywhere? How do I think about observability?

It's, it's in the platform, but there's, there's, there's two major things on observability. The first one is, if we are building a platform as a product, that means this is a software product. Every software product needs to run when people need it.

It needs to be fast, it needs to be resilient and, and and secure. So you wanna apply observability best practices to your, to your platform, to your Argo, to your Jenkins, to your GitHub, to your GitLab, to your verno. All of these tools and everything else you build around it.

So you need to observe the platform because the platform engineering team needs to know if the platform works as expected and they want to get alerted in case there's a problem. They wanna see who is using it and who is not using it. So the first aspect of observability is observe the platform itself to make sure it's available.

The second thing is the, the major use cases will be to help engineers to create new software through the help of the platform. So that means when they're creating new services, when they are deploying new serverless functions or whatever they do, the platform can automatically inject observability so that everything they do and they build is automatically observed so that they get the logs when they need it, the traces when they need it, that they get alerts when they need it. So that's the, the two angles observing the platform to make sure the platform works and observe everything that your engineers do as they work with the platform, as and as they create value through the platform.

All Right. And are you working on the SQL for this yet? Uh, we just released it last week, so, uh, I think we, we need a little bit more feedback from, uh, from the readers.

Uh, I hope you have a chance to read it and give us feedback and then we're happy for a second edition. All right. Awesome.

Everybody. This is platform engineering for architects. You should check it out for sure.

And, um, I don't know, are you gonna be signing this book here? We are actually. And it's not just me, it's actually three authors, right?

It's Max who initiated the whole thing? Andreas, it's me and Hilary. Uh, max also happens to be here at CubeCon.

So tonight, uh, from six to eight, it's Wednesday at the Cube crawl, uh, at the Dynatrace. Poof, that's J nine. We are doing some book signings.

We have a couple of copies that we are happy to give away. All right, everybody, make sure you stop by and get your book signed. Hey Andy, thanks for coming by.

Thank You so much for the time. All Right. And we'll be back in a minute.