PlatformCon 2023 Sneak Peak – Charity Majors, Honeycomb

This is Techstrong tv. Hey, everybody. We are talking about Platform Con that's coming up here, uh, June 8th and ninth.

We're very excited about this conference. It's, it's got a huge groundswell of community engagement. Wonderful.

People. Speaking of wonderful people, charity majors. How are you doing?

It's good to see you Doing well. It's good to see you too. It's been a while.

It's been a while. We need to connect more. We've got, you know, we've didn't, we did a whole bunch of panels there together for a while, and then we both started traveling, I think, as we, I know the world came back or whatever.

Yep, yep. So you're, you're speaking at, uh, platform com. Well, first of all, if they're per chance is someone who doesn't know Charity Majors and hasn't read the book.

This is the vanilla version. I'm getting the enhanced version here someday. Um, there you go.

That's the one I want. So, uh, intro yourself for folks so they know who you are. Yeah, sure.

My name is Charity. I am a co-founder and c t o of, uh, honeycomb. Uh, we were the OG Observability company.

Uh, and, um, and, uh, I identify as an ops engineer. I, I've been doing infrastructure operations my entire career before it was called SRE before the DevOps fanciness started. Um, a and so that's definitely, you know, the perspective from which I'm, I, I'm coming.

Oh, fantastic. Well, is is great because you're bringing this continuity from ops to sre DevOps into platform engineering, and, and I'm excited to both hear your talk and of course, love to talk to you about this. So can you give us a little, uh, kinda sneak peek and idea what you're gonna be talking about at Platform One?

Yeah. The title of my talk is, is called, I think the Future of Ops is Platform Engineering. And, uh, you know, there, there's, there's all of this, um, heat and noise over the last year about DevOps is dead.

Uh, which is what sucked me into the discussion originally, because I got extremely irritated by that. Uh, I think it's, I think it's f*****g, sorry. I think it's, I think it's insulting.

I think it's stupid. I think, I think it has, no, it's coming from a place of just wanting to be like buzzwordy and flashy, having no, like, idea of how technology actually works. Uh, there's a kernel of truth there that's being just like smothered and b******t.

I think it's click made. I think that's what it started as. Totally.

And you wanted to, you get some clicks on stuff, And it's, and it's really obnoxious because it plays into a lot of some really frustrating tropes that I think really held us back as an industry. Mm-hmm. You know, this idea that what's hard about software is the writing of it.

Oh. And the easy stuff. Just running it, give it to the ops team.

They're not, they're not real engineers. They just run this stuff. Well, actually Most of what is hard about software is not the writing it, it's the owning it and the running it, and the maintaining it, and the sustaining it, and the fixing it and the understanding of it.

You know, and I think to introduce one more buzzword, uh, into the conversation, I think that AI is going to make this a lot more clear to people. I think that the relative difficulty of writing code has obscured the fact that most of the costs are in understanding it and, and mm-hmm. But now that writing code is becoming so easy, it's going to be more clear than ever over the next decade or two that the real burden of, of, of, of software is in the ownership over, over the long term.

So I think that the kernel of truth that is in the DevOps is dead crap, is that the era of dev and ops is coming to an end, and by coming to an end, I mean, it started and 20 years from now, it's still going to be in progress, you know? Mm-hmm. Like, we still have COBAL in production.

You know, it's not like these things ever go away. There's still, there are always gonna be ops teams and dev teams, and we're going to, they're need going to need to collaborate. Um, but I think the platform engineering is kind of the tip of the spear of this kind of new breed of engineer, which, um, you know, you can call it a full stack engineer.

I used to have a lot of righteous rage against full stack engineering. I'm like, I remember some. Nobody Out there like writing the firmware on the chip for the graphics card and doing the desire everything.

Nobody's doing that. Right. But I think that, you know, if you kind of look past the, the details a and look at what they're actually saying, we are saying that, uh, to be a well-rounded engineer, to be a powerful engineer, you, you, you don't need to go deep as much.

You need to go broader. Mm-hmm. And, and that umbrella of broadness encompasses operating your code.

You know, I think that increasingly you can't ask people to operate codes that they don't also write and own. You can't ask people to write code that they don't also operate and own. Because so much of the process of understanding it is iterative and ongoing.

You can't just perish you in and understand it. Uh, and I think that like, you know, platform engineering is kind of like the, the first team that really embodies that shift. You know, it's, um, and you, you of course, we'll grappl with this, it's all about understanding and context, right?

You can't, you can't figure out what to do about a problem until you both understand it, but also in the context that it's happening. Right. And I think that's what, what's cool about platform engineering that I like to charity is that one thread of it is kind of getting back to basics of we forgot about making things simple and simplifying this.

We got everybody involved in the whole DevOps stuff, and that's all goodness and collaboration. And, and, uh, we did things for security and did things for compliance, et cetera, et cetera. And, uh, but we made some things more complex.

And I think that's also a flavor of what, uh, what platform engineering is and feel pretty different. This script, you have a different view, but it seems like that's, that's another thing we're kind of building around this. Yeah, Absolutely.

As complexity balloons and new and exciting ways, we have to look for new and exciting ways to collapse it and simplify it and create interfaces to it. Mm-hmm. I think that's absolutely true.

And I, and I feel like, but if there's one thing I would, I feel like there's a lot of visits. So platform team or not, are we just rebranding us? Are we, I think there's one, just one simple question that you can ask yourself.

Uh, which, who is your customer? If, if your customer, if you as a platform engineering team, if you're responsible for SLAs, for customers, being happy, for, you know, service uptime, you're not a platform team. Yeah.

You're an s e team, right? If your customer is your internal, your developers, and if you're responsible for how easy, how hard it is for them to spin up a new service or own the code, and those developers own their own SLAs and SLOs and uptime and customer happiness, then you're a platform team. Mm-hmm.

That makes a lot of sense because, you know, sort of the cloud engineering teams that kind of come out of the network and infrastructure world not, don't really still gro or relate to the developers yet. Right. And, and SREs, you know, where they come out of ops, observability, kind of that path with great skills development, coding, performance testing, problem resolution, improving resiliency of reliability, extremely valuable.

Um, they're better connected to that. But now we can bring that even further with platform engineering. I, I totally agree with you.

If you're customers, developers Yep. That's what you're doing. Yeah, yeah, yeah.

Exactly. I think, and I think that there's a, um, this is a shift to like, we haven't even fully made this honeycomb. I mean, it, it's, it's a, it's a real pivot in terms of, I feel like a lot, first of all, as a, as an op engineer, I have to just like reassure people who are in operations, the need for your skills is going nowhere.

Yeah. They're more important than ever. Right.

Um, but like increasingly, all engineers write code and all engineers understand the code that they write. Right. Um, I forgot where I was going with that.

Well, you know, when we said we weren't gonna need all those, uh, security testing and ops people when we started DevOps, I think the op the opposite happened right? Opposite. That's what you get for saying that, right?

Yeah, exactly. Yeah. But, but, but the relationship to, um, shipping code is ship is shifting.

Mm-hmm. I think that, you know, uh, what we've learned about shipping code, you know, quickly and effect and, and there's this whole like speed of safety when it comes to software, like getting things out the door while it's still fresh in your head. And then looking at production and being like, is it doing what I expected?

Does anything else look weird? Is so critical to, to having, having suffer that isn't just a hairball of crap under your bed. Um, but, but we used to have all of these, this, these, um, points of, of, um, of like blockers in the path of like shipping code, like mm-hmm.

Oh, it's gotta get manual QA done. Oh, it's gotta get sign off from this team. Oh, the release engineering has to, team has to go and deploy this.

Oh, the SREs are gonna do the firefighting, you know, and, um, that, that all of these choke points creates. They, they create slowdown and everything and Yep. You know, what we're, what we're learning is you need the engineer who's writing the code to really shepherd that code out the door and validate those working in production and, and, and, and use these specialists as consultants, right?

They have all, you can't expect the software Deere to know all these disciplines, but you can expect them to dip into and get, get help from, you know, you need opera ability, help you get it from the SREs you, you know, the security team can both advise, can, can create abstractions, can, you know, contribute, uh, and then can verify after the fact and stuff. But they can't be in that critical path of, of releasing the code, right? Because mm-hmm.

That feedback of getting it out is so crucial When the environment we're deploying in is ever increasing. Yes. We have Kubernetes and it's complex and maybe it's getting better, maybe it's not mm-hmm.

But you've got wam and you, you know, you're, you're doing stateless, you're serverless, you're doing Yeah. The, the environment we are creating to deploy into is continuously moving, right? Yep.

And so that, that stack that's between infrastructure and our app is just getting bigger and wider all at the same time. So it seems like the perfect time to make this a critical discipline Yes. To help us connect that for the developer.

Cuz they cannot understand all that. I mean no security and that and that and that too, right? Because What I feel like a, um, a really critical part of this transformation that hasn't really begun yet is the introduction of an internal API for the, for the platform engineering team to, To, that's a cool thought.

Well, my friend Abby Bek is, is with credits and they're, and they're doing this, they're, they're basically making an API for platform engineering team. So it's like rails for Ruby, right? Mm-hmm.

Uh, so, so you know, for example, one of the examples Abby was telling me is like, you know, as a platform engineering team, you might get requests from some of your engineers to get the admin role on gras. You can see these graphs and stuff and you know, and then, and instead of you doing these manually mm-hmm. You know, you can set up a Google group.

Anyone in this Google group is allowed to have, you know, admin access. Then you create an endpoint in your API just so somebody just sends an API request, re requests admin access it checks to see if you're in the right Google group and gives you admin access. Right.

And I think that like, that, that api it, cuz you're right, I think a lot of, a lot most companies, all companies right now are pretty much using the repo as that api. Mm-hmm. Which, which is too much surface layer, right?

You're expecting everyone who needs to do something with infrastructure to like know how to use Terraform, which is too much. Mm-hmm. Mm-hmm.

It's gotta be reducible to an api. Uh, but I think we're a few years out from that. Well, that's also helps, you know, I was just talking with someone about the, the cloud is all about automation.

I'm not saying you have to automate everything, but that's, that's the scalability. It's not just more hardware and more capacity. Yep.

You can't, you can't leverage that stuff. You know, it, it's scaling what people can do through Yep. APIs through automation.

So I want to connect the dot with, you know, think, think your talks about the future of, of platform engineering and you mentioned AI and I'm very much a believer, I think in sync with what you're saying is writing codes easy, maintaining codes, hard meaning everything else. Right? And I'm always careful about, do we really wanna write code for that?

And so, I mean, generative and assisted First years, if they try to solve everything by writing code, You know, it's great, but okay, then suddenly we're in the tools business and not in the insurance business or whatever we're supposed to be doing. I kind of to look at AI generated code standalone that way is like, who the hell is gonna mi I'm sorry folks. Who the heck is gonna maintain that?

Am I gonna give it back to something to re to enhance it, fix its own vulnerabilities? Maybe someday. I, I, to me it's all an assisted tool.

It's a, it's, it's like a repository was when we moved to distributed development. Now we've got, you know, AI assisted and, and, and maybe bigger role in our applications too, but is sure Zach not turn the reigns over to a fully AI generated set of code. I mean, no, not yet.

Error spit. Yeah. What about, remember that context comment?

Hmm. That is a lot, lot that goes into that. So, so connect, connect the dots.

What are your thoughts about let's roll forward two, three, maybe five years down the road. We're getting an p i into the, uh, platform engineering layer. You know, we're, um, we're, we're, we're we're bringing together the Devon ops and not, and, and taking away that separation.

So it's, think of, I I would describe it as a flow path, right? Mm-hmm. So that it's happening not parallel, you know, sometimes diverging paths.

What do you, how, how would you think, how would you describe what we're moving towards? Uh, you know, I think we already touched on a lot of it where we're moving towards a world where there's no dev ops. There're only engineers who write their code and they own their code in production.

I think that, you know, because writing code is about to become so cheap, um, the emphasis is increasingly going to be on understanding code, uh, and, and, and not just understanding it in the moment, but making it understandable over time. Mm-hmm. And this is where instrumentation is everything.

Mm-hmm. You know, you know, we used to talk so much about documenting your code and commenting your code and stuff, which is just a really rudimentary and kind of crappy and unbelievable sort of instrumentation. Your code should really instrument itself because that's the only kind of documentation that actually takes reality into account that actually takes production and reality and users and everything.

If you actually, if you actually want to know what your code does, you shouldn't ask your comments or your docs, you should ask your instrumentation. Mm-hmm. And this is something that we've been like very behind on as an in, as a, as an industry.

And I was saying this like five years ago. I'm like, we're so behind when it comes to instrumentation. And then, you know, the whole open telemetry project really picked up steam.

It's, you know, the second, uh, you know, in terms of like, um, uh, velocity and people using it and everything behind Kubernetes. It's the, it's the second biggest project. Uh, I think that, you know, it's, it's, it's a little clunky, but it's moving fast.

I think that's great for people because, you know, the idea is to make it vendor agnostic. You instrument your code once with it. You can move between vendors, you can try out other vendors.

Your vendors have to compete for your business on the powerfulness of their application, not on vendor lock-in. I think all these things are super, um, the thing that I worry about is junior engineers, you know? Mm-hmm.

I feel like, to me the different, the bright line between a senior engineer and a non-senior engineer is, um, their gut. It's their, their intuition. It's have they seen enough wars to have a good instinct for where the problem is and where to pick up the rug and look at it, you know?

And, um, and I think it's going to, when, when, when we don't rely on our juniors to just crank out all this low level code anymore, I think it's, it's gonna be really challenging for people to get the experience that they need to even get to the point where their judgment is good and reliably reliable and trustworthy. And, and I, I don't know, I'm sure I don't wanna be like one of those, you know, people are like, oh, the calculator is gonna kill all math, you know, but I don't think we have a, I mean, juniors were already really suffering even before we got to this point with the rise of remote work where we really haven't figured out how to onboard juniors there. Mm-hmm.

And like getting that first job is, it's just so rough. And, and, and I understand why nobody wants to invest in it bec this because it, it, it is a big investment. It takes a few years before they're really, you know, positive It out loud.

Um, and it's gonna become even more so now that so much of that code, we did have them do, but it's so critical to our survival and evolution as an industry to have those fresh faces, fresh minds, and to really like bring them up properly. So, just my opinion, but I think the best senior engineers are the ones that know how to take a few. Absolutely.

Junior, you Don't really know That. Bring them along Until you know how to teach it. Mm-hmm.

Mm-hmm. Absolutely. Well, it's, it's fun.

It's, uh, it's fun talking with you about this. I wanna point out to, we're not here to promote your book, but there's a great chapter in here on, oh, observability Driven Design, which goes to what you're talking about, kind of think open telemetry for your app, right? I mean, that's where it's gone and maybe it's open telemetry for your platform engineering, right?

That's where we're headed for that. Who knows that, that would be awesome if it did. Charity.

Great. Pleasure talking with you. Um, I have one last question.

What are you looking in addition to your talk, what are you, uh, looking forward to most for Platform Con mission? Oh Man, I should have looked, I should looked over the schedule. I don't remember Couple since I Looked at it, but I don't do remember looking at it going, oh, these's, these are great, great, great faces, great names, great talks, Always good networking too, right?

Yeah. It's, it's, it's virtual and, but there's still all the connections that You make. Yeah.

But it's, I like that all the talks are so short. I I don't have long tension span, so I'm stoked that they're all like 20 minutes. Yeah, I, I'm agree with you there.

Right? Awesome. Fantastic talking with you folks.

Um, everybody, please whether, whether you're the developer, you're consider yourself a platform engineer, s r e somewhere, ops, any, any part of that spectrum, I think this is a conference you have to go to because this is what's bringing it back and making some important things relevant for everybody, especially for developers. So charity, thank you for helping make that happen. Your role in platform absolutely.

Con Absolutely. Great catching up. Yeah.

Good to catch up with you. com/register. Uh, check that out.

Uh, get online, get yourself, uh, situated. So you're attending, uh, it's on June 8th and ninth. Uh, and make sure you're, you're, you're ready to sit down and enjoy some great talks.

And the good thing is, you know, we can pick and choose and go back and watch and do all the great things with a virtual experience. So charity, until next time we get to, uh, get back together, uh, safe travels that now that we're doing that, a lot of that again in the world. And yeah, thank you so much for everything you do to contribute to the community as well as great products and the great work that you and the team there at Honeycomb do.

Thanks All. Thanks everybody. We'll see you soon.