If you want to keep tabs on what’s happening in the ever-changing world of DevOps, Gareth Rushgrove’s DevOps Weekly newsletter has been a must-read for the past nine years. By day, Gareth is a product manager for Docker, but every Sunday, from his offices in Cambridge, UK, he curates an eclectic mix of DevOps stories and resources that keep his almost 30,000 subscribers informed and up-to-date.
In the course of gathering content for 400 or so email newsletters (with an estimated 5,000 links to DevOps content), DevOps Weekly has kept Gareth’s finger on the evolution of DevOps since its early days. New Relic was thrilled to sit down with him to discuss the changes he’s seen over the years, and to learn how he expects the filed oew
New Relic: You’ve been publishing the DevOps Weekly for some nine years now… how has DevOps evolved during that time? How are things different now compared to when you started?
Gareth: It's a broader conversation now. Not because the people who were involved early were myopically interested in only a very specific subset of the conversation, but because there were fewer people. And frankly, we were all younger. Some of those people are doing broadly the same things, while others are in a lot more senior positions, dealing with bigger challenges. 
DevOps is wholly community oriented—it's about the people in the room.
In some cities, DevOps got a developer flavor because the people there who were passionate about organizing something were developers. In other places operations is more central. Sometimes it's more balanced between the two. And it’s important to remember that DevOps is still growing, still finding new areas that fit into its original brief of working better as software professionals.
If you look a bit further out, the term “DevOps” isn't the most important bit. It's allowed us to come together under the DevOps banner, but that visibility is pure marketing. DevOps is basically a marketing success story in that sense—it's one reason why people get emotionally attached to DevOps in the same way as they get attached to brands.
Sometimes people like the friction between things that are different. Sports teams are a classic example, but also picking your software tools or programming languages. You can't possibly like Java and PHP, can you? It’s the tribal nature of communities, people finding things to bond over. And sometimes that's the thing, and sometimes that's the thing you're against.
New Relic: Where does something like site reliability engineering (SRE) fit into this discussion?
Gareth: SRE has come out of Google, and not many of those people were in the room when DevOps was born because they were at Google. Google already had rooms filled with people talking about some of these things. One of the things that's changed about Google is they're now much more actively involved in external communities. At one point Google was known for sharing what it was doing via academic papers, but they've broken that down to where they'll often share via open source projects and other means.
The SRE book is a fantastic example. The previous generation would probably have shared that information via targeted academic papers, not in a mass audience book.
More specifically, DevOps and SRE is an apples to oranges comparison. SRE has had a parallel evolution to DevOps, but they’re definitely not the same thing. I see SRE as an implementation, a specific collection of practices, where DevOps is more of a community conversation.
Serverless has fans, too
New Relic: Given this tribalism that you talked about, are we starting to see newer approaches and branding for the DevOps mindset—in the way that DevOps challenged earlier mindsets?
Gareth: Definitely! The best example is what’s happening under the serverless community banner. A lot of conversations about tools and practices are tied up with current assumptions, especially the adoption of cloud. It’s not that DevOps is only about cloud computing, but a lot of the API-driven infrastructure and automation has gone hand-in-hand with the adoption of public cloud and cloud practices.
If you look at it from the point of view of the new serverless community, there are fundamental differences: “We're new. It's all different!” From the outside, though, you may say, "Oh, no. It's all the same." And there's a bit of truth in both viewpoints.
DevOps drivers vs. DevOps barriers
New Relic: What do you see as the biggest drivers for DevOps adoption right now. You mentioned the cloud, but what other items are pushing organizations towards DevOps?
Gareth: Speed. Organizations are now fundamentally understanding that they need to move quickly. Not moving fast is such a detriment to your competitive position, whether against existing competitors or against new competitors that may have a radically different, and much faster, business model. That fear of disruption has driven a lot of organizations to appreciate that they're not moving quickly enough.
Look at the State of DevOps Report from one of my former employers, Puppet, as well as DORA’s Accelerate: State of DevOps 2018 report. There's so much data and solid research showing that it is possible to go faster without sacrificing stability or security. The argument against DevOps was always, "No, we can't do that. We won't be secure. We won't be compliant. We won't be safe." But the data shows that’s simply not the case.
New Relic: On the flip side, what do you see as the biggest barriers to DevOps adoption? Is it primarily a technological issue, a cultural issue, or mixed?
Gareth: I think technology plays a part, but first and foremost it’s a people, process, and cultural issue. Especially in large organizations where you have such a broad range of existing technologies, existing people, existing processes, existing partners, as well as possibly different regions, locales, offices, different cultures, and different teams in different places.
Trying to change that is really difficult. It’s even harder when you’re trying to move toward a model of constant change. People want digital transformation to be something that they can do—a process with a beginning and an end. Ultimately, though, DevOps is about embracing a world where change is constant. Lots of organizations are not set up for that; they're set up for discrete, periodic changes, with success measured between those changes.
Another issue is procurement, purchasing, and budgeting. The importance of the financial side, moving past a project mentality to create incentives that lead to structures that can adopt these practices easily.
Getting started with DevOps
New Relic: So—if I’m in a really large organization, and I want to explore the brave new world of DevOps, how do I get started?
Gareth: Listen to people outside your walls. My government experience is a good example; in many large organizations, people end up in an echo chamber claiming that, “Oh, no. Government is different.” Or “Banking is different.” And they don’t want to talk to people outside their organization or industry.
Attending a local session of DevOpsDays can be hugely eye-opening. I've been to quite a lot of these, and there's nearly always a few people there who have never really been to anything like that before. And they’re blown away by how open people are.
Lots of people come back and bring that enthusiasm to their own organizations. Enthusiasm goes an awfully long way when you're trying to change an organization from the inside. If you're not enthusiastic, why are you even doing this in the first place?
There’s also a wealth of DevOps resources to dive into. The recent Accelerate book presents useful data and evidence that people can [use] to make their case for DevOps. The DevOps Cookbook, as well. There are books targeting CXO-type folks and books targeting technical practitioners. There are books for people who like data.
The critical role of monitoring in DevOps
New Relic: Let’s talk for a minute about the critical role that monitoring plays in DevOps—an issue that we care about here at New Relic. What’s your take on the current state of the relationship between monitoring and DevOps?
Gareth: Earlier we talked about cultural automation, measurement, and sharing. Measurement was always part of the DevOps mindset. And not just measuring infrastructure or applications, but measuring everything: people and practices and processes.
Monitoring was a fundamental thing. In the early days of DevOps you had a lot of conversation about deployment tooling, and you had a lot of conversations about monitoring. It was something that the community was interested in and everyone was able to talk about. The explosion of monitoring tools has gone hand-in-hand with the product and process things—especially the rise of deployment automation.
Ten years ago, the idea that Flickr was doing five deployments a day was crazy. Now, it's, "Oh, yeah. Of course we're doing five deployments a day." Even in large organizations with scale and compliance issues, this is demonstrably possible and demonstrably positive. But you cannot do it without two things.
One is comprehensive monitoring. It's not good enough to know what your servers are doing. You need monitoring of the whole system and how your users experience it. Otherwise, you can't react to issues before they affect people.
The other thing you need is continuous integration and continuous deployment (CI/CD). Again, that’s a sea change from 10 years ago when it comes to deployment tooling. The deployment pipeline is now a critical part of your infrastructure. Before, you might have said, "I need my deployment tools once every six months." But, “Now I need my deployment tools to be 24/7." It's the evolution of the monitoring tools that give us the confidence to do that without simply throwing people at the problem.
The DevOps Weekly—there from almost the beginning
New Relic: Now that we’ve talked about how DevOps has evolved, let’s delve into you got involved, and how the DevOps Weekly came to be.
Gareth Rushgrove: My involvement in DevOps goes back to when I used to work on the development and operations side of things for large organizations, building out continuous integration tools and helping get software into production. Probably most formatively, I worked for the UK government for about four years on what would now be regarded as “digital transformation,” although we weren't using those words then.
At the same time, I started doing a lot of things with small teams, growing an operations team to help other government departments adopt modern infrastructure practices. So my background includes everything from business software development to operations work to classic developer things, and also the consulting and people side. I think it's the broad spread of things I've done that drew me towards what eventually became DevOps.
New Relic: So how did that transition happen? How did you discover DevOps?
Gareth: Really by proximity to someone who was there at the start. The DevOps term began with Patrick Debois and organizing the first DevOpsDays event in Ghent, Belgium, back in 2009. I wasn't there, but one of my colleagues at the time was. He came back and said, "Oh, you should have been at that. They were talking about all of the things that we're doing and you're interested in."
I was at the second one, in Hamburg, and I thought: "We now have a word for this thing!" I ended up sending an email out to a few of the people I met and staying in contact with them. And I'm still doing that nine years later.
New Relic: So that was the genesis of the DevOps Weekly newsletter?
Gareth: DevOps didn't invent the practices that came to be attached to it. But it gave us a forum to talk about those things. I was already interested in build tools, I was interested in automation, I was interested in the crossover between operations and development. But it wasn't until a bunch of people who were also interested in those things got in a room and started talking about it, and realized other people were interested too, that suddenly it got a lot more interesting.
This was in the early days of Twitter. And at that time if you searched for the term DevOps, just about anyone using it was an interesting person, which created the opportunity for high-value conversations. So I met a lot of friends who were some of the first people who realized this was what they had in their head but didn't have a word for it before. Once we had a word for it, everything sort of coalesced.
Seeing that grow over time has given me a super-interesting vantage point, and DevOps Weekly is just one of those side projects that got out of hand.
New Relic: How you decide what to put in the newsletter each week? Do you put in everything that you come across that’s DevOps related, or just the best stuff? And how has the content changed over time?
Gareth: It's always been a curated thing. I put something in if I find it interesting enough. I read a lot, and I've always collected links, and I’ve found that if I think something is interesting, other people do as well. I'm pretty happy if I can hit one or two things that people find interesting in every issue.
Certainly, the topics that people write about have changed over the years. But so have the types of things I'm interested in. The newsletter has evolved along with the DevOps movement, which helps keep it fresh for me but also for some of the subscribers who have literally been reading from day one.
Is DevOps cool?
New Relic: I have one more question. This comes out of what we were talking about earlier: Is DevOps still cool?
Gareth: I don't think DevOps was ever cool. It was a bunch of geeks talking about service management under a marketing banner, and we were definitely not the cool people. I think it's interesting how DevOps emerged into the wider world, but I'm not sure it was ever cool.
On the other had, a lot of cool things have happened under the DevOps banner. A lot of people spend an awful lot of time and effort making people feel welcome in the DevOps community—even if that's realistically just made up of a word and the internet. And I think that's cool.
Las opiniones expresadas en este blog son las del autor y no reflejan necesariamente las opiniones de New Relic. Todas las soluciones ofrecidas por el autor son específicas del entorno y no forman parte de las soluciones comerciales o el soporte ofrecido por New Relic. Únase a nosotros exclusivamente en Explorers Hub ( discus.newrelic.com ) para preguntas y asistencia relacionada con esta publicación de blog. Este blog puede contener enlaces a contenido de sitios de terceros. Al proporcionar dichos enlaces, New Relic no adopta, garantiza, aprueba ni respalda la información, las vistas o los productos disponibles en dichos sitios.
