Sentry Scouts: DevOps — A Recap

Sentry Scouts Meetups are organized by software developers for software developers, about the future of building and using software. Sign up for the next Sentry Scouts Meetup or enjoy a video of a past Meetup.

Or do both. Or do neither. Or simply become paralyzed by choice and take a nap.

February’s a fun month, right? Look, we know it’s June now but please come along with us on this nostalgic tour. It happens directly after January, there’s perhaps more or less snow depending on where you live, and you can get your fill of discounted chocolate during the second half of the month! February of 2018 was noticeably more fun than usual, as it also hosted the second Sentry Scouts Meetup.

In case you aren’t familiar, Sentry Scouts Meetups are opportunities for like-minded friends and professionals to swap stories around a campfire. Except, instead of being seated around a campfire, everyone is actually gathered around a projection screen. They’re both sources of light, so it counts! Also, we were fortunate enough to be joined by an accomplished group of panelists:

One incredibly helpful takeaway from Sentry Scouts: DevOps is that “DevOps” is practically unGoogleable. You can click through page after page without really understanding exactly what DevOps is. (It’s worth noting that “unGoogleable” does return Google results, and is in fact an actual word recognized by credible sources, like Urban Dictionary. But not by our computer’s spellcheck.)

What’s that? You landed in this recap after Googling “what is DevOps”? Got it. Good thing we tasked our panel with that question first!

What is DevOps?

Before we get into the “what,” it’s helpful to address the “who.” While other engineering teams work on products, issues, and tools that effect end-users, DevOps teams often work on products, issues, and tools that effect other engineering teams. As Brian Lucas of Optimizely explained, “The main goal of DevOps, at least in my view, is to serve an internal group and anything that is externally facing that requires uptime reliability. But we make a lot of things that service our customers which are internal, our engineering group.”

With that context in mind, DevOps encompasses two themes: empowerment and automation. Each panelist highlighted the fact that a core aim of DevOps is to empower those on their teams and beyond. For example, Courtney Wang from Reddit enables a strong developer-product relationship by “giving tools to developers to let them ship stuff to production, let[ing] them do stuff to those services in prod, giv[ing] them the ability to fail and fail gracefully, and also see[ing] and improv[ing] on a daily basis.”

As Wang hints and Heidi Waterhouse of LaunchDarkly eloquently states, part of the empowerment process is “automating away as much tedious crap as possible.” Or, as Brad Green of Google asks, “how do we reduce uh-oh moments?” Automation moves a developer’s focus from scut work to actual work, increasing overall productivity and empowering those developers to have better insight into their own projects as well as those of others. Simply put by James Cunningham of Sentry (hey, that’s us!), “less time operating means more time engineering.”

With Great Power Comes Great Responsibility

Whether you’re an engineer, a developer advocate, or something else entirely, Cunningham explains that “no matter what title you have, you probably work on the same stuff.” Same stuff, indeed! DevOps teams often unite with the single goal of solving a problem, which establishes a sense of shared responsibility.

This responsibility extends past a DevOps team into other engineering teams. For example, DevOps teams attempt to find a balance of what they think other engineers want and what they truly need. Shared responsibility also emphasizes the need for (or lack of) documentation, as building a knowledge base allows developers outside of a single team and company to learn from and contribute to a project. “You’ve automated [something], and that’s great,” says Waterhouse. “But then it breaks, and no one knows how to fix it, because there is no documentation.”

Considering the nature of DevOps, things can and do go wrong. Fortunately, shared failure is a natural result of shared responsibility. Katy Farmer from InfluxData proposes that “we made this decision together, and if we fail, we failed together… There’s never been a solution that didn’t also come with problems.” Shared failure (hopefully) results in a blame-free process that empowers teams to better address the issue and move on.

What Does the Future of DevOps Look Like?

The future of DevOps is planning. That’s right; the future is thinking about the future. Intuitive, right? If DevOps teams are striving to empower and automate, it only makes sense to also act strategically. Take critical components that bog down the process and move them upstream. Don’t reinvent the wheel, however tempting it may be at times. Understand and document priorities.

Audience member Jim Scott, a Site Reliability Engineer from Stripe, shared an anecdote about his time at Urban Airship, explaining that the DevOps team was tasked with a problem that ultimately fell apart due to lack of strategic planning, resource management, and documentation. He’s now a firm believer that DevOps projects should be proactive rather than reactive, treating each project as a product that you’ll be shipping to customers (who just happen to be internal engineering teams).

Also relevant is the Jurassic Park quote shared by Wang: “[You] were so preoccupied with whether or not [you] could, [you] didn’t stop to think if [you] should.” Ideally, strategic planning will include thoughts and discussions of both could and should.

If you joined us for the Sentry Scouts: DevOps Meetup, thank you! If not, maybe next time? We also highly recommend that you check out our amazing blog, educational (yet fun) tutorials, and other helpful resources.

See you there! Or here, on the internet!