Ken Muse, GitHub | DevOps World 2023

This is Techron tv. Hey everybody. Welcome back to DevOps World in Santa Clara.

I can't believe we're, we have our last interview. It feels like we just got started. We had so many great people we've talked to and, you know, we're, I think we're finishing up with a fascinating conversation with Ken Hughes.

Ken is DevOps architect, senior DevOps architect. Give you your due. And GitHub, it was great talking with you.

Thank you very much. Glad to be here. Good, good.

So, so, uh, it kind of roll back tape a little bit. I remember the conversations about is DevOps the title, should you put DevOps in your title? Is that a legitimate thing to do?

Right. And of course, of course people put it in there, right? Because they wanna advertise themselves, but you don't hear about DevOps architect as a role.

Tell us a little bit about what that is and what it means. Well, it's really more specific to, uh, the nature of the team. I work with the fast track team that we help customers to figure out what is the best set of DevOps practices to meet their needs, their goals, their deliverables.

And so we're helping them architect, starting with the people and the process. Mm-Hmm. And then coming back to the tool.

So while we don't really like the idea of a DevOps engineer as a role on a team, our role really is to help them architect their DevOps practices and to think more holistically about what they're trying to accomplish. Interesting. I mean, a lot of people, a lot of us, our journey has been, okay, let's start with CI/CD.

That's kind of the nucleus of where to begin. And then you start working on, you know, work workflow pipelines and tool chains and all the things that you, you do during, uh, kind of SDLC. Um, how do you approach it now when, when you go out and kind of talk about the people in the process first, what is it you learn about that?

Is it how the organization works so you know, what you're gonna implement is gonna work in that, in that company? Or is it something else? Well, some of it's how do the people work together?

What makes them effective? What are their friction points? Because if they're having friction points, it's slowing down their productivity.

It's impeding them from implementing other things that could make them even more successful. The other part is understanding a bit about the organization and its needs. The more compliance requirements that an organization has, the more specific needs that it has, the more things you have to consider as part of helping build a healthy process.

Hmm, Interesting. Very cool. So do you, so you spend a lot of time with customers or prospective customers, people that are, are they starting on their DevOps journey or they're in the, in the throes of implementing it, maybe kind of getting stuck on some issues, not quite sure how to, to get where they want to go.

Where, where do you usually enter the picture? It's a broad range. Everyone's at a different part in their journey.

Mm-Hmm. And in some cases it's people that have been doing it 20, 30, 40 years and they've got very deep established practices. Mm-Hmm.

But would like an outside opinion on how could we make it better? Because if we've done it the same way for 30 years, then something has stopped us from growing and evolving and continuing to mature. Mm-Hmm.

In other cases it's, Hey, we're starting a team. We're trying to get them off on the right foot. How could we accomplish that?

If you were starting fresh again, getting another opinion on the approach or some reinforcement that yes, these are good practices and here's how you can move forward with 'em. Great. Now is this a professional service offering from GitHub, or GitHub does this to help people that are just using GitHub as a product and a service?

It's more of an enablement that we help customers that are adopting GitHub to also adopt healthy practices around it. Because if you just simply try and adopt everything to the tool, you're not really getting the most out of your processes, out of your people. And eventually the friction is going to feel like the tool's not doing its job.

When the truth is the tool should adapt and help to enable the people in the processes to be more successful. It, it, it seems, it makes a lot of sense because I could imagine people approaching GitHub as the repository GitHub. Like we might have thought of GitHub five years ago.

And you think about all the things security and GitHub actions and copilot and you know, there, there's a whole kind of, uh, a string of, of capabilities that are there. But if you're not familiar quite how to pull that all together, it could be easily just like we use it as repository and we're still doing our same 20 or 30 year process and not realizing there's, there are some things, new things we could try and, and we just need some help to how to get started. Absolutely.

And just like with teams, the more siloed you treat things, the more challenging they are. And that's why with GitHub we try and show them that it's a platform that all the pieces are part of a whole that, that use together, interact with the other systems. They've got to enable a, a holistic practice as opposed to it's a tool for this and a tool for that.

Mm-Hmm. It's not a tool belt, right? It's a platform.

Precisely. So Let's talk about security. I mean, a lot of focus on supply chain security.

Um, and you can think about security, of course, shift left and SecOps and how we build security into our software. But what about the tool plane or the DevOps, um, tool chain kind of plane of it? Um, you know, some of the work I'm doing is like how you can containerize elements of that to try to bring some more isolation into the, into the tool chain.

Uh, so you don't have pipeline poisoning and things like that that, you know, yes, you have a secure image at the beginning, but you know, not just code the developer introduces other things could be injected. How, how does GitHub think of, of security in the software supply chain? It's really kind of a shift everywhere approach.

Um, I know we talk often shift left and shift right? But it kind of hides the complexity of a modern software security challenge that Mm-Hmm. It begins with what are the developers putting into the project?

Because as we adopt dependencies, it's not just the features it adds, but with these modern package management systems, it integrates into the build, it changes the developer experience. It can add scripts, new build deployments, other features. And so security really has to start with when I'm pulling it in, what am I pulling in?

And then am I keeping that tool chain up to date for whatever purpose it's providing? Whether it's assisting my build or providing me code I don't have to maintain throughout my entire lifecycle. Is that code still secure?

Because we're discovering over 300 new exploits a year and the numbers have only been exploding. Mm-Hmm. And so by being able to look across the process from the development side all the way through to once we've got it in the cloud, has a new exploit been discovered or delivered?

Is there a new CVE that six months after we stop development, just put our customer at risk? Is there a secret hidden in there? Is there a code quality concern that means we could have an exploit?

It's really thinking holistically about the security process rather than thinking of it as a bolt-on Yeah. That developers Tolerate more time thing we do at a certain step or whatever. Exactly.

Yeah. I totally get that. So, um, really curious.

You, you were telling me before we started, got a chance to get on air, uh, that you were working with a consultancy that worked with closely with Microsoft. What have you seen the influences that Microsoft has had on GitHub? Um, you know, it hasn't been that long ago that they bought 'em, but you know, Microsoft's got a strong culture and it's pretty tough for companies to leave the acquisition alone and let 'em do their own thing.

Those things kind of seep in or maybe intentionally do. What kind of influences have you seen, uh, from Microsoft that might've helped GitHub? Uh, just speaking from my experiences there, uh, that, uh, process of bringing in a company and then leaving them alone was, uh, a very surprising aspect that they recognized there was something special about the way GitHub operated Mm-Hmm.

And they needed to enable it, not get in the way of it, not try to pretend that there was an expertise there that should overwhelm it. And so like a good DevOps practice, it was about supporting the decisions that the people on those teams were making and offering them the resources to do it better. So we got the combined knowledge of the developer teams inside of Microsoft, the teams behind Azure DevOps, plus all the experience and expertise that had built up over the years from the GitHub side.

Mm-Hmm. Melding together. And then the liberty to take the best practices we were seeing among those and come up with a new way to look at the same problem In in Interesting.

Um, because, you know, sometimes there's the whatever acquiring company way of how we do things, there's also, but Microsoft's gone through its own transformation. You think about, you know, coming from where they were of selling, selling software products and database and all the tools and everything that they did to being very cloud centric. And not just running them but delivering it in new ways as a service.

Um, what do you think GI GitHub has to teach Microsoft? I think one of the big things we've had, uh, that we could show is, uh, an approach to agile development that really is highly people centric, that Microsoft is a great culture of, of trying to empower their developers. But GitHub's had a remote culture from before the pandemic.

Mm-Hmm. Interesting. A culture that required you to think about a global presence required you to think about how do you support someone that's thousands of miles away, hear their ideas, and then enable them to achieve those while at the same time building a business that can scale to hundreds of millions of active users with a few thousand employees.

Excellent. Excellent. So, so that last question.

Um, what, what do you hope you get to work on in the next year or two? What, what is an exciting idea or project or, you know, you obviously don't want to just do the same thing over and over. I assume that, that there's some ideas you have of where you want to go in your career.

What are some of those possibilities for you? Well, of course AI has become a really hot topic. Mm-Hmm.

And as was highlighted earlier in some of the sessions today, it's also an area where there's a lot of room to grow in terms of DevOps practices and principles. We're still just at the cusp of understanding how do we make AI repeatable, understandable, applicable in ways that really empower the broader community. And so that's an exciting area to continue to explore and to see what kind of changes can, can be influenced in such a, uh, emerging technology stacks Kind of copilot just the start, right?

I mean, it's just the beginning really of where we might go with ai. Yeah. It's a great way of, of proving out that you can improve productivity by thinking about a problem differently.

Mm-Hmm. And once you start opening that box, what other things can we do? How can we improve security, make it more seamless?

How can we enable new processes without making them feel heavy handed? Because at the end of the day, developers have so much on their plate already and they just need a way to support that and make it more effective, not just more things between them and a new release. Right.

More distractions. Right. Exactly.

Cognitive load dissonance. Ken, it's been a great talking with you. Thanks for being part of the DevOps world, uh, contributors.

And one of the, did you do a talk or a panel? You Were, I was part of a panel on SecOps. Oh, okay.

Very good. I'll have to go back and catch the recording 'cause I have been doing this all day, which has been fantastic too. So, um, good luck with your journey with GitHub.

It sounds exciting. And, uh, we're looking forward to see where the, where we go with AI as part of, not just a development plugin, but influencing kind of our whole development process, tool chains, software we create. I mean it's, it, the, the, the, uh, the the uh, uh, palette is open of what we potentially can do And we're just seeing the beginnings of what's possible.

Absolutely. Very good. Thanks again.

Thanks for having me. You bet. So this is our last, uh, interview today here at DevOps World.

I wanna thank the folks at CloudBees who've been super generous in inviting us to be part of this and sharing this experience that we've had. It's been fantastic. Um, I had a very special, extra special pleasure of, uh, leading a panel and meeting with, um, a select group collaborative conversation, uh, with customers talking about cloud native.

And, uh, it's just, I think one of the, one small way, couple examples of the vibrancy and the health of the, of the Jenkins and also the CloudBees community. So thanks to, uh, to the CloudBees folks, good luck in Singapore. That's the next one that's happening.

And, uh, we will see you on Textron tv. Again, stay tuned. We have some great content coming up out of research, by the way, around supply chain security, um, cloud native, uh, aspects on platform engineering, you name it, containerization, all kinds of good stuff.

So we'll be talking with you soon. Thanks for tuning in.