Guest: Austin Parker (LinkedIn, Twitter)
Company: Lightstep (Twitter)
Show: Let’s Talk
Keyword: DevOps

In this show, I sat down with Austin Parker, Head of Developer Relations at Lightstep, to discuss the evolution of roles in the IT, or more specifically cloud-native world. He feels that the Agile management style has been co-opted by the top-down management as a ‘thing’ instead of a process or way of doing things. This is something which is now happening with DevOps, which essentially was a counter cyclical reaction to Agile becoming a thing.

“I think DevOps is almost the reaction to what happened with Agile. It’s more about collaboration. It’s more about you as a developer owning more of the process and being able to make changes to things,” says Parker.

We touched on some very interesting points related to DevOps, emergence of soft silos, SREs and more. Check out the above video for details.

Highlights of the show:

• Adoption of Agile development by Top-Down management?
• Is ‘DevOps’ still a useful term?
• Is ‘SRE’ the evolution of DevOps?
• Emergence of soft silos
• Why should no one have a job title with ‘DevOps’ in it?

About Austin Parker: Austin Parker is the Head of Developer Relations at Lightstep, and has been creating problems with computers for most of his life. He’s a maintainer of the OpenTelemetry project, the host of several podcasts, organizer of Deserted Island DevOps, infrequent Twitch streamer, conference speaker, and more.

About Lightstep: Lightstep’s mission is to provide clarity and confidence to the teams that build and operate the software that powers our daily lives. Founded by ex-Googlers, the cutting-edge observability platform gives engineers quick insight into how changes in their applications and infrastructure affect their end-users and their business.

Here is the full, unedited transcript of the show:

• Swapnil Bhartiya: Hi. This is your host, Swapnil Bhartiya and welcome to TFiR Insights. And today we have with us Austin Parker, Head of Developer Relations at Lightstep. Austin, it’s good to have you on the show.

Austin Parker: Hey, it’s great to be here. Thanks for having me.

• Swapnil Bhartiya: Yes. It’s good to have you. And of course today’s topic is also quite interesting, which is why DevOps should never be in your job title. I do know that you have a lot of opinions on tech topics obviously. I want to know what are your thoughts on adoption or embrace of Agile development by top-down management?

Austin Parker: What I think is a really interesting thing about, we started off by saying, why should DevOps not be in your job title, right? And DevOps, I’ve read a little bit about this, where DevOps is really just a counter cyclical reaction to what we saw with how Agile became less of a way of working and more of like a thing that you bought, right? You can go and get Agile consultants. You can go and get Scrum certified. You can do all of this stuff. And originally Agile was about, hey, how do we become more responsive to the needs of our customers, right? As I pan away from the development methodologies about Agile, about very top-down heavy, sort of heavy handed management.

And I think DevOps is almost the reaction to what happened with Agile, right? So it was more about collaboration. It’s more about you as a developer owning more of the process and being able to make changes to things. And that’s why I think we’ve kind of come full circle and you see places doing DevOps centers of excellence or cloud centers of excellence, right? Where you might have a DevOps person in your organization or you might be that DevOps person and your job is indistinguishable from what it was before because now you’re just getting a ticket to go in and click something in your Cloud Console or to rack a server but now we’re using different words for it.

And in a lot of cases, you see those DevOps functions being subsumed by products, where now there’s a lot of companies out there selling DevOps tooling or DevOps lifecycle management or this and that and the other. And that kind of cycle will be like, “Hey, this is something new and exciting” and then people start making money off of it, I guess, and turning it into products. That’s been happening for the past 20-25 years really in technology. So I have some thoughts about where that goes next, but I think that’s one of the reasons that you should kind of not eschew saying things like, “Oh, DevOps is my job.” But really think about it in terms of, well what is DevOps really? How does this relate to the organization?

• Swapnil Bhartiya: In today’s work, how would you define DevOps?

Austin Parker: So, what I think of DevOps really as is sort of what it originally was supposed to be, right? DevOps is the concept that you’re not just throwing things over the wall to someone else. That if you’re writing code, you’re also implicitly responsible for running that code, for operationalizing it for production, for handling things like security. Because of what I used to work in a place that was very siloed and we had developers that were literally on one side of a wall and they would go and they would pull tickets, they would write a feature and then they were done. They would hand it off to a test team and the testers were supposed to look at the code without having the benefit of written it and then figure out how am I going to test this based on this sheet of objectives we got from the stakeholders?

And then they would come up with test plans and they would implement the test plans. And then all of that would go over another wall to the ops people, who got to figure out how to do package and run it. And that sort of siloed style of writing code, testing code, deploying code, wound up with a lot of flaws and failures. Just think about the amount of time that was lost because if at any step of this process if something goes wrong, you can’t fix that problem. If you’re a tester and you find a bug, then you aren’t empowered to fix the bug even if you know how. You have to send it back over to the developers and then let them have it kind of cycle back into their plate. So we would do a new release like twice a year if that, which is terribly slow like that just you can’t release twice a year.

Even in the enterprise market, you need bot fixes, you need features, because there’s always someone new coming up that’s going to be able to move faster. And now it’s easier than ever really for teams to adopt new technology. So even if you’re all this big embedded enterprise vendor [00:04:44] Slack, right?. Nobody really saw them coming and then now they’re here, they’re displaced a ton of different collaboration tools, Asana, Trello, you can name it. There’s a bunch of examples of smaller nimbler tools coming in and displacing kind of the standards because those teams could move faster. They could iterate faster. They could deliver value faster. So to me, DevOps is about how do we bring these development teams? How do we bring developers into a place where they can move faster?

• Swapnil Bhartiya: Right. Once again, thank you for explaining that. And that leads to one more interesting question, which is, comes from your answer, which you talked about. You come from a siloed world and we believe that this Agile, Nimble development, DevOps, it will break old silos. We were looking at Unicorn developers. One person will be able to manage everything. That is not reality today. We do hear a lot of words, NetOps, DevSecOps and then the SREs. I think the reality is that people will always be inclined towards the specific area of technology that they like. Some people, they just like networking. Some people, they just like storage. They specialize in that. Some people, they just like orchestration. Some people just like [00:06:00] different aspects, but there will still be these teams. So do you feel that in an attempt to break old silos, we are kind of creating new silos as well. I mean, there’s much more coordination between these silos. There’s much more cooperation, but then also you realize that when you talk about Chaos engineering, people are talking about, here are the team, they never saw each other and suddenly they’re all in the same room trying to fix the problem that went wrong. So how far have we come when it comes to breaking these silos with these new [00:06:27] that we have started using?

Austin Parker: That’s a really interesting kind of thing you identified there, right? That as these new specialties or these new kinds of subspecialties come up, they eventually turn into their own silos. They turn into their own things that have to be tossed over the wall, right? And I think at a lot of places that adopted Agile, like I said, with Agile earlier, right, they’ve became a bunch of certifications and professionalization of this concept of like, “Hey, maybe we should just listen to our customers more and we shouldn’t write out six months worth of development before we even do it.” And so the same thing happened with DevOps. So now you have DevOps teams that just kind of got added into this like Dev team, test team, ops team. Now you have DevOps team that maybe does something else. Now you have the DevSecOps team that used to be the security team.

And what do they do this different from what they did before? Well, now they run container scans as well as like endpoint protection, right? So the reason this all keeps happening is because you’re right, like people do, I think for a lot of reasons, they do want to specialize. And for a lot of organizations, specialization becomes necessary because you just eventually have problems that are too big to kind of handle by a bunch of generalists, but those specializations become then they kind of want to be professionalized. They want to be credentialed. They want to say like, “Oh, well here’s my DevOps conference that I get my DevOps badge from. Here’s my DevOps tools that I can buy to kind of make me more productive.”

I actually I don’t want to say this is like a value judgment because I really don’t think it is. I think this is kind of, again, this happened with Agile. It’s happened with DevOps and the new thing is SRE, right? SRE is kind of the, where did all the weirdos go that wanted to be generalists and wanted to do a bunch of things? Well, now, instead of talking about DevOps, you’re talking about site reliability engineering. They’re talking about all this new stuff. And even that is becoming professionalized and commoditized in a lot of ways where companies are starting to market to the SREs, or they’re starting to, within a couple years, you’re going to see like more SRE platforms or SRE tools or all this sort of stuff that exists in some fashion, but it hasn’t really gotten to that tipping point of, “Hey, there’s like this whole, there’s a a ton of fire here.”

We’re still kind of stuck in the mining all the value out of this DevOps term, but that’s the cycle, right? And I think my point about talking about this is less to say like, “Oh, this is a good thing or this is a bad thing.” And it’s more to get people thinking about why do these changes happen? And like, what are we trying to do?

Because I think at the end of the day, a lot of this comes from developers wanting to kind of take power back from management, from the people that are calling the shots and wanting to kind of make it more equitable. Because if you look at like what causes a lot of burnout, what causes a lot of heartache and headache and people quitting, it’s stuff that does get deprioritized when you’re in this very like push, push, and push mode, like it’s reprioritized in DevOps, in SRE, stuff like that, stuff like reliability, stuff like developer experience tooling, stuff that makes your job easier as a developer. And we’re just kind of going through the same loop every five to 10 years or so. It’ll be interesting to see what comes next.

• Swapnil Bhartiya: Do you see that SRE is kind of an evolution of DevOps, or you feel that, “Hey, you know what? It’s just we keep using different labels or maybe things are refining, things are changing. It is more or less like fashion also.”

Austin Parker: I do think it’s a bit of an evolution in the sense that DevOps was and remains incredibly broad, right? Like if you’ve read the Phoenix Project, which is sort of the seminal DevOps text, right? DevOps in the context of that book, like encompass so many things as to be just this universal concept that made it kind of useless I think in the more limited context of like, “Well, how do we like develop and run software.”

So SRE, I think fixes that, like that SRE addresses that tension in a way, because it says, “Well, look, if you’re running, if you’re building these very complex systems and any modern system of scale is very complex just by necessity. It could be something, the demands of our customers make it so. Even if you’re working in like a bank or an investment bank, or a ticket ordering system or e-commerce or whatever, right, like you’ve probably got mainframes, you’ve got all the way to Kubernetes somewhere in your tech stack.

And you’ve got people that are trying to access your product or your service from like really old browsers to brand new iPhones, to like everything in between. And this variety means that we need to have, we have infinite variety and so we need to have infinite ways to satisfy that variety.

You can’t do that, like at the application level and at the operations level, like you can’t really be the one person that says, “I’m going to create the Uber solution that fixes all these problems at once.” And so SRE kind of takes the interesting parts of DevOps around automation, developer experience, so on and so forth, splits those out and says, “Okay, we need a very professionalized way to talk about people whose job is to make our ability to write and run software easier. And I think that’s kind of the focal point of SRE that differentiated from DevOps at large. If DevOps is really more about processes and about the division of labor and responsibility, SRE is more like here’s an actual job title and set of work that supports these concepts.

• Swapnil Bhartiya: The burnout, the causes we don’t know yet. But if we do look at Unicorn developers, you are responsible for virtually everything in the organization, security is becoming a very big challenge and that could be a very, very dangerous thing. So how much engineering time or developer time you are getting to focus on adding business value to the applications versus also trying to secure it, which are two different ends of a spectrum? And if you’re responsible for both, there are chances of mistakes there. So what is your advice or what trend do you see, or you see that, “Hey, we are in a very, very early experimental age of this whole Agile cloud with you and over a period of time, we will settle down and we will realize that, Hey, we will need a specialized people just the way, go back to the old times.”

Austin Parker: Yeah. That’s interesting. I think the most cost effective way of securing your application is business insurance. It’s a joke, but it’s also true, right? Like at the end of the day, the reason that security is such a thing you buy rather than the thing you build is one that it’s very complex from the perspective of actually implementing good security practices.

So if I’m a developer, I’m always running behind the people that are running behind attackers, right? Like there are more people trying to break what I’m doing than there are trying to fix those breaks. And as everything becomes more complex and more convoluted, then the amount of service area that you have to be aware of, mitigate as attacks increases exponentially. And at some point you just kind of, you can’t deal with it.

So what do we do? We pay people to make it not our problem. We pay people to say like, “Oh, here’s a security scanning thing. And if something gets through, then it’s our fault, not yours.” That said, I’m not sure there’s like a quick and easy fix of this. I don’t know if integrating security more into the life cycle helps. I don’t know if there’s obviously tons of options out there for static code analysis, container security, things like that.

The one thing that I will say that really interests me and that I think does have a lot of potential here to address this at the developer, sort of at the point of the developer, is stuff like open policy agent and other least privileged systems, simple things like mandating mTLS being able to define in a pretty straightforward way like, “Hey, this is what this service and that service can expect to how we’ll talk to each other.” And being very explicit rather than implicit does help a lot in reducing the attack surface for an attacker and is something that I think developers can kind of just do naturally, especially if it’s integrated into other tooling, such as their RPC layer or something like that.

If you’re using gRPC and gRPC can just spit out a policy document for you that says, “This is the only way these two things will ever talk to each other.” And then you can hand that off to your orchestration layer, your networking layer and say, “Hey, this is the valid route. So this is how these things are going to communicate.” If anything else happens, then it shouldn’t. If nothing else you’re reducing sort of the space that something could exploit.

And that I think has a lot of potential for really helping to address this in concert with better supply chain security for the Software Development Life Cycle, right? Like more validation for packages and trusted repositories and things like that. But at the end of the day, this is also a problem that is, there’s no single technical solution for it. There’s no single fix. There’s more people trying to break your stuff than there are people trying to not break it.

So you need to keep security as, I think one thing that burns us out as practitioners is this idea that we can have perfectly safe, perfectly flawless systems, right? Like there’s always going to be an opportunity for failure. There’s always going to be flaws. The question is how do we build resilience and make sure that when things break, they don’t break everything. When there are fires, how are we putting them out in a sustainable way rather than just kind of burning the candle at both ends.

• Swapnil Bhartiya: So I want to go back to the theme of today’s discussion. And I want to ask you that, why do you believe that no one should have a job title with DevOps in it? What is the reason?

Austin Parker: So fundamentally I think that, like I said earlier, DevOps really is about practices and processes. And it’s about decision making. It’s not a collection of technologies. It’s not knowing how to write a script. I think that if you are interested in stuff like that, if that is what you want to do in terms of, maybe you’re not interested in writing business logic or programming in Java, right? You find scripting very interesting or you really like working with Kubernetes.

I feel like SRE, site reliability engineering, that’s kind of the discipline for you. And then if you’re not interested in that and you’re a developer, but you want to be better at it, you want to improve your craft and level up, then really it’s about taking the methodological learnings from DevOps and saying like, “Well, what can I do as a developer to write more testable code, to understand how my code is deployed, to be responsible for the changes I make and for fostering kind of a more healthy environment for me and the rest of the team.” Right?

So that’s what I think it really means to be a DevOps practitioner. It’s not like, “Oh, I know how to use the Amazon API, or I know how to use Ansible.” It’s about, “Am I working in a way that lifts people up rather than kind of silos them off by making sure that security is part of what I’m doing? Am I making sure that cost attribution is part of what I’m doing, right? Am I making sure that observability and chaos engineering and, da, da, da, da, da, right?” It’s about being well rounded as a developer and being a good member of a team rather than being like a Unicorn developer that can do everything because it’s ridiculous to say that everyone should be able to do everything. We need specialization.

• Swapnil Bhartiya: Austin, thank you so much for taking time out today and talk about this very interesting and it could also be depending on how people see controversial topic as well, but the beauty is that as you rightly said, that it really doesn’t matter, you use whatever you use, whatever works for you, but in the end, we are going with the loop, we’re trying to solve a problem and we’re just trying to figure out, what is the right approach there. So thanks for sharing those insights. And I would love to have you back on the show. Thank you.

Austin Parker: Thanks. Yeah. I love you back. And if you want to argue with me about it, you can find me on Twitter. I have plenty of time.