Exploring Platform Engineering at Google with Leah Rivers and James Brookbank

Hey, everyone. We're back here live at Platform Con Day in New York City. com, register for the virtual event.

It's been going on all week. I believe you can watch, uh, these sessions from earlier this week on demand. Go do that.

Do it right after you watch this. But for now, let me introduce you to what this is. I wanna first introduce to my immediate left, Leah.

Hi. Hi, Leah. Your last name, I'm sorry.

I'm Leah Rivers. Leah Rivers. Welcome to Techstrong tv.

It's great to have you here. It's Great to be here. To my far left, James Brook Bank.

Brook Bank, easy names, E two Easy names. Thank you. Thank you parents.

James, welcome to Text on tv. Hey. All right, let's jump into this.

So, Leah, you, you are with Google. Yes. Tell us kind of your position.

Give, actually give us a little bit of your journey, how you wound up here today at Google. Sure. Uh, well, I have a, a background in both computer science and anthropology.

And so my career has been kind of a, a mix of really taking, kinda the heart of really understanding from anthropology and the possibilities and technical, um, insights of computer science and putting those together, really trying to help create, uh, technology systems that enable, you know, humans to, you know, keep getting better at getting better. So that's led me through, uh, you know, working at cloud, uh, various like cloud scale problems, um, other cloud providers and startups. And eventually to Google where I get to focus on leading product for Google's internal developer platform.

Kind of a dream job That is, especially here at the platform engineering come that would be like I, if we said, Hey, who would like Leah's job? They'd be lined up from here to the end. And today, uh, James and I are here at Platform Con, and we're, uh, we're kind of representing our, these are our personal thoughts in this conversation today.

Not on behalf of Google. Our formal talk is later. I gotta be honest with you, I've been in tech a long time, 30, 35 years.

I've been doing interviews like this for 12 years. You may be the first anthropology major I've interviewed. Oh, I didn't quite get my anthropology major.

I think I was one class away from actually com. Okay. It came down to computer science or anthropology.

I had to go with the computer science. With computer science. Yeah.

Okay. I loved anthropology. I have to tell you, look, I was a poli sci history major, so what do I know?

Oh, yeah, yeah, yeah. But, and we all wind up here eventually, but that, that's a fantastic thing. Um, so how long has Google had a formal internal developer platform, if, you know?

Um, well, I've only been at Google for three years and it, it predates me. It was well established. So It was well established by the time I arrived.

It, you know, to the point where they're putting product leadership, you know, I, my my, my role as director of product, um, um, so it, it was established enough that you added a layer, you know, product management capabilities to that Formal product. And In my experience, you don't put product management on a platform to help make it better. You put it on when it's really successful and you really wanna amplify that success and accelerate.

Yeah. You have to have a certain level of maturity there. Yeah.

Well, Well before we had a cloud, right. In this scenario. And, and I guess just for context, right?

So, um, while, while Leah sits on the, the sort of core pieces and looks after those, those elements for the whole of Google, um, like myself, I look after a team like solution architecture where we only really worry about the cloud piece. And that like sits as one of the customers for the overall alongside YouTube and Waymo and all the other cool things in that space. And, you know, for the cloud platform that really is, you know, sort of 10 so years old, right?

In its modern sort of the way it looks. And well, before that, there was an existing platform within, within Google. Listen, You know, it's fascinating if you ask, most of the people here, they think of IDPs as, as rather a new thing.

Just like platform engineering is a new thing, right? And, and it's almost always hosted, right? Mm-hmm.

Yeah. But there's no reason it has to be, and and quite frankly is, I think in the case of Google IDPs have been around a lot longer than, you know, the, the, the, the invoke platform engineering kind of, It's been a, a long time since sort of Verna came out and said, like, you build it, you run it. Right.

You know, that's 20 odd years now, right? But like, that was the era where platforms are being constructed at other hyperscalers as you, as you know, so, you know Yeah. A long time.

Yeah. It's like, to take the anthropology lens on that for a minute, um, one of the effects I think we're seeing is, is like there's new vocabulary that comes out. We, we get better at understanding the core issues, we're solving the opportunities and new language comes out.

So the, you know, the, the language of an internal developer platform, or the meaning of platform engineering has, you know, sort of bubbled to the surface as the thing that we have in common and we can, like, get better at. But the concepts and what we're doing and how we're doing it, we've been working on those for decades. Same, same things put together in new ways.

Yeah. You know, it's funny as well, 'cause I, I, I obviously don't, I don't have a degree in anthropology, but my degree is in biochemistry. Mm-hmm.

So it's a very strange sort of space that I think a lot of us get into. But you'll hear us talk about like things like ecosystems a lot mm-hmm. For that same parlance that like all those components are still fundamentally, well, some, some have evolved over the years.

Sure. Um, but to extend that analogy, like the way the ecosystem works in this space is really what we're interested in. And some of that is very much terminology.

And some of it we see, I think talking to people today, like, Hey, you're doing something new in an interesting way, but it, it's a way that you've, we contextualize all of those components. I get it. Kinda like carbon atoms, how easily they can combine with other elements and stuff.

So, so much stuff. Very, Yeah. Well, I just, that's about all I know about chemistry.

So I went, was it you? You're technically correct. No.

All right. Now you guys are presenting here today. Yeah.

Yeah. Yep. What are you presenting on?

You, you should say shift down? Like anything that shift down. Shift down.

All right. You know what? Scale up.

Look that camera down. Scale Left down to scale up, shift down, shift down Though. All right.

That's a great catchy phrase. Yeah. It's, it's a natural, um, extension of shifting left.

When we shift left, we move things earlier in the developer workflow. We help developers do things faster or, you know, more correctly. But we're not fundamentally changing the things that developers are responsible for.

With platform engineering, we have the ability to systematically solve problems in the platform that, you know, need to be solved globally. So we can take it off the plate for developers. Um, so they don't have to think about the implementation at all.

I think, I think it's, it's one of those things we talk about as well. 'cause people are often like, well, aren't we doing that with DevOps? You know, and I spent a lot of time, I work with the Dora team at Google, which does a lot of sort of DevOps research work, which is, um, you know, I think very insightful in this, in that we've all got the same goals.

We're all trying to achieve some of the same things in these areas. But, you know, a lot of the things we, that we've tried to do in DevOps, um, have worked effectively almost so that it's become the standard in many areas. Um, but sometimes when we've shifted some of those things left, we've become kind of overwhelmed.

Like, there's just so many topics. There's so many new things to tackle so many security vulnerabilities every day. And that's overwhelming out of it.

It's overwhelming me, right. I'm constantly having to deal with these new things. So, you know, I I, our sort of view, I think in that space is we're not stopping the DevOps journey.

Like that's still a very normal and healthy thing, but, but at scale, we, we've gotta do something to start pulling some of those capabilities down into the platform and, and, and stop overloading our development teams. And, and I think that's what the, the vision is in this place. I, I, I agree with you.

I, I think, James, what you just described is actually the reason for being of platform engineering as we understand it today, which I, I was talking about it. Our last guest just wrote a book on platform engineering for O'Reilly. Oh, Camille, er, you get a chance.

She's also speaking this afternoon. I think one of the problems, and, and it was the problem with Schiff left, and, and let me preface all this. com.

I'm a big DevOps fan, right. I've got 30, 35 years in tech. I, I think DevOps is a great thing.

And it really changed the way kind of we look at working together. The problem with Shift left, which was, you know, fundamental in DevOps, is we, we've set up this religion that we pray to the developer, God who's the predator, alpha predator at the very top of our food chain, the orca of our food chain and everyone else kind of exists to make that developer better. Yeah.

But you just can't keep throwing, it's not an omni potent bean. He's, they're a developer putting more and more on their backs eventually that camel's back breaks. Yes.

And it, and that's because it, it's a person, right? Like I'm a developer, so when I go and ask from, you know, my internal platform teams, like, Hey, I need these things. Like, that's your responsibility.

Now, I don't want that responsibility in some of these areas. Developers want to develop. They don't, you know?

Yeah. I, I, I think that was a fundamental mistake where we said, Hey, developer, you're responsible for developing your own platform, right? Yeah.

No, that's not the way I think it was supposed to work. But you're disagreeing. Well, no, no.

Well, we is a necessary learning process along the way, you know, we try, we learn. That's, that's kind of the whole thing. So We can thesis anti synthesis.

Yeah. And we get better at identifying the actual stable sub problem that we can solve. And if you like, we've built up a big practice around focusing on, you know, instrumenting and focusing and understanding that I'm doing the, the affinity loop here.

Mm-hmm. The, uh, you know, the developer experience. We could have a blind spot or a streetlight effect around that because it's really understanding what they're up against in terms of scale, in terms of what we call quality attributes or non-functional requirements.

Yeah. These big challenges and looking at where opportunities are to solve what they're up against on their behalf. And you have to look outside, you have to expand the frame beyond simply looking at how they're working.

You fundamentally wanna change how they're working by taking some of the those tasks away. Yeah. And I still want that freedom, right?

Like as a developer, I still want the freedom to operate. And that's why we can't go back, like the DevOps journey that we've been on. Like, we can't go backwards into, oh, I now I just throw it over the wall.

I want to have that optionality, but I want it with the comfort of being provided those quality attributes, being given those things as part of the platform. So, you know, if, if, if I decide that, oh, I think I need this new feature, and then suddenly it's not available from the platform we're back at 20 years ago, right? So we have to go through that journey.

We have to have that constant iterative process to that. And that's very DevOps itself. Yeah.

No, I preaching to the choir, right? com. Hmm.

And, and I, I don't think they're mutually exclusive at all. I think they're That's the continuum. Yeah.

That we, that we live under. And, and you one got the other. Yes.

And, and, but it is an infinity loop to your point. Um, we haven't mentioned ai. It's been spin, I don't know, 10 minutes.

That's a record. How is that playing into Google's IDPI mean, they're all about Gemini, right? That's all we're hearing.

I see it every time now. How, how are we, how's this playing in? I mean, you know, I, I think there's a, there's a, there's an open talk track here.

We've published, so I think some, um, some very obvious numbers in the past about how much code is being written internally, um, by, by AI or in this scenario in terms of our internal platforms. And that's getting to the sort of 20, 30% rate. That's a huge amount of code being generated in those spaces.

And that's done by our internal equivalent for, for Gemini. Um, I think the distinction there is we want to do that in a very cautious way. We want to make sure that there is a human in the loop for, for almost all of these changes.

And, you know, when we, when we talk about how we embed those, uh, into our platforms, that's gotta be done in a very conscious way. So that's already, I think, quite effective. And if you think about the history of Google, we've been using ML platforms for a very, very long time.

And so, like having those capabilities using them, that's already happening today. So that's already changing, I think what if we're doing, but I think there's a lot of areas where it doesn't necessarily change what we need. I'm more and more dependent on the platform to provide all of those quality attributes for the model usage.

Right. So I've got even more platform dependencies and even more asks from, from the IDP, But that's not a bad thing. Yeah.

It, it's like another way to look at it is, platform engineering solves business problems, right? And, and so the goal, like the commercial goal of platform engineering in any organization is to maximize value with existing resources at acceptable quality with sustainable costs. And so our ability to work with the resources available and solve more and more complex problems just gets better and better and better.

And, and AI significantly helps, but still that same goal that we're, we're working towards. Understood. Understood.

So have you been here most of the day? I don't know if you've logged onto the virtual event at all. What, you know, the vibe here is high energy, certainly.

I mean, it's not a huge venue, but it's packed. Mm-hmm. I heard London was even bigger.

I don't know, were you there yesterday? I, I wasn't. I'm from London originally, so I was missing out, but I, I think I'm too old now to try and do back to back.

Yeah. No, Lu Luca ante from, uh, human tech from the pleasure's. A big org's.

He did. He was there yesterday and flew back. I said, unfortunately, we don't have the Concord anymore.

Right. You might never do it. Easily had A couple of colleagues there as well.

And, and I think, um, this was something where we, we, we weren't in person last year. We did like a watch party. It was in Austin, and yeah, there was a lot of demand.

And I think that's surface today. Like there is a lot of demand here. I've been been talking with a lot of people here, some, some existing customers, some people who've never, never really heard of Google Cloud itself.

Mm-hmm. I don't think anyone's not heard of Google, but like the Google Cloud pieces. And I think, you know, a lot of, I think very interests, um, very interesting conversations around all of the topics inside platform engineering.

But we've got away from the time of, is this a thing? We've moved past that in this space. So everyone has come here for how do I solve this particular problem?

How do I go tackle this particular area? And, and I think that enthusiasm that we, we, you know, for a while was like, oh, is this gonna kind of fade? Or like, it's really just matured.

I, I think it is maturing. com. Every fifth article is what, what, what is DevOps?

What's what is not DevOps? Right? And now we are doing that.

Um, we've moved past that. We've moved past that with platform. Well, we've now still gotta argue what's our own definitions of DevOps versus platform engineering.

So we, yeah, no. What Are the things I've really enjoyed, uh, in my conversations and being here with high energy today is whether you're building, you know, at Google scale and supporting platforms at that scale, or you're, you're building at a startup, it, when we start talking about the problems of platform engineering, we have the same problem. Yeah.

They're pretty consistent. Yeah. And, you know, there are social problems as much as they are technical problems.

And kind of the thing you, you get to notice as you solve these problems over and over again, is no matter how good you solve a particular problem, like if you're successful, you just have another problem. Skip More on that. I don't if you ever read, do you know the, the book, the Goal?

Have you ever read the goal? Oh, you know the goal, Eli? Yeah.

So that was more manufacturing than tech, per se. Yeah. But that, but that's the whole point.

Yeah. As soon as you solve this bottleneck, there's a bottleneck behind it the next Yeah. So we have lot, but that's business.

Yeah. It's job security. Anyway, we are about outta time.

Okay. Leah, James, thank you so much both for coming on. You know, we do a podcast on platform engineering, actually, Luca and I Oh, cool.

Uh, called the Platform Engineering Show of all things. Love to have you guys come on one day. You know, it's remote.

We don't Yep. Can't always get together in person, but we'd love to hear more about what Google and Google Cloud are doing around your IDP around platform engineering. Yep.

More, More to come. Right. We've got more to come, I think in that space.

There's a lot of things in preview at the moment and sort of, you know, I think just excited to be part of the platform engineering journey with the community. Love it. Yeah.

We're live here at Platform Con. Thank you very much to Google and Google Cloud. James and Leah, thank you.

We, we have more coming up in just a moment, so standby and bye.