Unlocking Developer Productivity with Platform Engineering | KubeCon SLC 2024

This is Textron tv. Hey guys, welcome back to Salt Lake City. We're at Cube Con and we're here with BMK from section six who is also A-C-N-C-F ambassador and we're talking about well platform engineering.

Welcome to show my friend. Thank you Very much and very excited to be here. And it's all buzzing.

All buzzing with cloud native and open source. Excited to be here. You recently gave a presentation on platform engineering and adoption and I've been walking around the show floor and it seems everybody kinda likes the concept, but nobody agrees exactly what it is.

Yeah, I think like, uh, we are always trying to, uh, find the better way of doing certain things, like, you know, what we did with DevOps, what we are doing with, uh, in a cloud native, what we are doing with platform engineering. I think, uh, the important aspect of platform engineering for me is actually how do you help your developers to be more productive and um, with the help of an internal developer platform, internal developer portal, and giving a great experience for your developers by way your developers can help you accelerate business delivery for your customers. I think that's the primary focus for this.

Yeah. How do we get the developers to buy into that? And I'm asking this question because I would argue DevOps exists because we wanted to get away from centralized IT and platform engineering feels like centralized it to a lot of people.

So how do we kinda get everybody to link arms on this one? That's right. Like, you know, that's an interesting question.

Uh, if you remember like, you know, organizations, they always handshake using tickets and uh, I coined a term called TBD. It's called ticket based development in sense like if you want anybody to do anything for you, you raise a ticket with someone so they do the job. But what platform engineering primary focus is actually enable the developers to self-service what they want actually.

So the focus is not tickets anymore. It's more on enabling them to giving a standardized way of doing certain things in your organization and also helping you with self-service capabilities. By the way, you are not waiting for someone to action your ticket.

Rather you have things readily available, you can provision, you can consume and you can carry on what you wanna do, right? So even if I do decide as a developer that I could go do this and I wanna do it that way, the, it will take me five times longer to do it myself. So I might as well go with the path of least resistance, which is this kind of thing that's already been set up for me that maybe is customizable enough for me to kind of play with.

Of course, yes. Like, you know, because most of the, the workload, what type of workload that you often work on, like it's a dotted core microservices or it's a Springboard Micro or you are doing a React app or you know, uh, view whatever it is that you're doing, like including data pipelines. So when you provide actually the commonly used components in a more reusable way and it helps organization with standardization, helps you with managing the governance around the, the type of the workloads that you wanna run and also help you to standardize on the tools and platforms that you want to consume in your organization.

If you remember like on the back in the day that when, you know, when um, and I was uh, I was still code, but when we were doing like there's no consistency between the developers. We use different libraries, we use different frameworks, we have different programming languages, even versions like that. But now, whereas platform engineering helps you in bringing that consolidation and then provide the guardrail for you do it.

So it provides with the golden path the same time certain you the boiler plate is ready to go on, you can still customize, you can still work on that, but you are limited with what you actually provided as an organization. For you, What is your sense of, is it a technical challenge or was it gonna be more of a cultural challenge to get these things adopted? I think like all the big changes that we've seen in the last two decades, including Agile and DevOps and uh, lean and value stream and uh, I think always the challenges with the culture and how the organization, they go about it when they roll out this kind of an initiative, right?

And sometimes you also feel like a peer pressure understanding that okay, somebody else is doing agile, I need to do an agile, somebody's doing DevOps, I need to do DevOps. Now somebody's doing platform engineering, then I need to do platform engineering. But the case is that like, you know, you start where it makes sense for you and you don't need to boil the ocean and you don't need to wait for stars to align.

So for example, the most common problem, what is the most common problem for your developers? What you wanna solve within your organization? Primarily focus on that and uh, that that's the way, how do you take off, you know, this kind of a journey.

So cultural is what we see is a common thing and sometimes the organization, like when you have a enterprise cloud platforms, these people, they go back, they live in their own coco. They think that this is what the developers they want. They come back after six months saying that this is, Hey guys, come and we build it, come and use it.

Generally those kind of things doesn't work. No. You need to be tering and helping for developers for their specific needs.

It made me let them be part of the process for building the platforms. Yep, Exactly. As you kind of think all this through for a minute, um, where does AI fit in this platform engineering conversation?

'cause it feels like we're automating more things in general. Yep. So is is platform engineering an outcome of ai or is platform engineering what we need to do?

ai, uh, I I think, um, platform engineering will help you to speed up the adoption of what you wanna do, including ai. That's what I see. Like, you know, so platform engineering is definitely not an outcome of an ai, whereas actually platform engineering will become actually the fundamental, the building block for you for organization to build different types of workloads including, uh, mobile apps, front and apps or, you know, um, retail dub dub dub or including a workloads and data pipelines.

So definitely AI is there and where we see a trend at the moment is actually developers leveraging these kind of AI tools to speed up what they can do and they can do, it's, it's not replacing them, it's more actually helping them to be be in a more productive in the space, including GitHub co pilot. You talk about including some of the AI co-editors that you talk about, and I saw yesterday one of the demo from one of the exhibitors today, how they can do a root cause analysis for an incident. So click off a button, the AI is doing all the hard job and provides you with the bullet points that you need to action on.

So what have you seen among organizations that are doing this well? Uh, what, what made them different? How did they get there faster?

What, you know, what The, the, the, I see certain patterns between these organizations. Like, you know, I come from, uh, not from a tech industry, I come from a banking background. I spend, um, half of my career in the banking and financial industry, which is also highly regulated.

The one common, uh, I mean a few common things that I see between adoption is that these organizations are really, you know, thinking ahead actually how they wanna do in within this, whether it comes to DevOps or platform engineering or ai, and they are thinking about like, you know, a year or two ahead actually, how do they bring this in? That is number one that's helping them. And this is done with the help of the people who are like a change agents within the organization that they're the champions who are helping, but at the same time, they also have the buy-in from the leadership teams and the support from the CXOs, like a CIOs or CDs that you have.

So that is one thing that we come and see where things are really successful. That is number one. Number two, these organizations are really high performing organizations and because they are highly focused, they have a laser focus on, they want to deliver the better results for their customer.

And that is the primary focus. So you be the best in the game in delivering the best result for your customer and also for your shareholders and also for your company. I think when you have this laser focus, I think you cut all the craps in inside your organization, the bureaucracy, the red tape process, whatever it is, you always find the better way of doing it and innovate faster, accelerate your application delivery.

Yeah, I was talking to some folks about this and when I was explaining it to 'em, they kind of nodded their head and said, yeah, we've been doing that and we've been standardizing, we've been doing something. We just didn't call it platform engineering, but they were doing it outta their own self preservation because supporting 18 CDs was unsustainable. Oh yeah, I definitely, I agree with that.

I think the, the people who say that they do, I, I think they need to also assess themselves actually where they are. Uh, assessment in terms of actually, okay, where is my maturity in terms of adoption? Because we know that like, you know, c and CD tools is not new anymore.

Like it's 20 years, you know, we are doing in this space country is deliveries. Like in 11, 12 years we've been in the space Kubernetes like 10 years in the space. So we are not doing, now you ask the question.

Okay. Uh, the one other thing that I always ask when somebody says that we are doing better, okay, what does your MDTR looks like as of today when some there is an outage? How mean how quickly you can restore your services?

You know, what is the path that you do, do you need to open a tech bridge where you get all 20 folks in your call and then talk about where, what's going wrong? Or do you have a self-service dashboard with metrics and giving you exactly where the problem is? Do you have a self-healing capability in the organization where you can quickly heal and provide?

I think these are, are the different signals that you see in the organization. If somebody's doing really well, and I think there is a continuous improvement mindset, right? Like, you know, you keep improving what you're doing, it's not set in stone and that you can't live it, you know, for a while saying like, you know, everything will be all right.

I think the common thing that we see is actually the high performing organizations, especially, they always strive for doing better continuously. They're improving the processes, the practices, the engineering capability within the organization, including what's happening with the AI adoption. So if I basically become complacent, I'm probably starting to fall behind.

Right? Yeah. There you go.

Hey, thanks for sharing the insights and the knowledge. Highly appreciate that. Thanks very much for the opportunity today.

Thank you guys for watching this latest instance of our show at the CubeCon live event here in Salt Lake City. We'll be back with more in a minute.