{"id":56022,"date":"2021-02-02T11:00:22","date_gmt":"2021-02-02T19:00:22","guid":{"rendered":"https:\/\/github.blog\/?p=56022"},"modified":"2022-02-04T10:24:36","modified_gmt":"2022-02-04T18:24:36","slug":"whats-next-for-devops-qa-with-lightstep-ceo-ben-sigelman","status":"publish","type":"post","link":"https:\/\/github.blog\/enterprise-software\/devops\/whats-next-for-devops-qa-with-lightstep-ceo-ben-sigelman\/","title":{"rendered":"What\u2019s next for DevOps: Q&A with Lightstep CEO Ben Sigelman"},"content":{"rendered":"

In the decade since the word \u201cDevOps\u201d was coined, its goal has stayed the same\u2014but the way organizations implement DevOps is constantly changing. For a closer look , we sat down with <\/i>Ben Sigelman<\/i><\/a>, CEO of <\/i>Lightstep<\/i><\/a>, whose observability platform is the easiest way for developers and SREs to monitor health and respond to changes in cloud-native applications. Hear the full discussion in our next <\/i>DevOps webcast<\/i><\/a> with Ben and panelists from GitHub, Red Hat, and RedMonk on February 4.<\/i><\/p>\n

Let\u2019s kick things off with the big question. In five years, what will DevOps look like?<\/b><\/span><\/a><\/h3>\n

DevOps isn’t new, but it also hasn’t settled in yet. As a result, there is a staggering proliferation of tools and technologies (CNCF Landscape<\/a>, anyone?), and yet there’s an equally staggering lack of consensus about how to actually do<\/i> DevOps. Of course there will not be\u2014and should not be\u2014a single answer for that, but in five years, we will have crisper definitions and success criteria for everything from CI\/CD to observability and back again, and we’ll also have a few well-balanced, opinionated, and holistic approaches to DevOps that organizations can adapt and adopt. The end result will be less time spent experimenting with tooling and more time spent actually shipping new products to market.<\/p>\n

It\u2019s easy to equate DevOps with CI\/CD and\/or automation. Although it seems like the goal of DevOps is to \u201cautomate everything,\u201d why aren\u2019t these the same thing? Does automating everything equal doing DevOps?<\/b><\/span><\/a><\/h3>\n

Automation is an important component of any software engineering practice, and there\u2019s no exception for DevOps. But it\u2019s imprecise (and maybe even a bit lazy) to define DevOps solely in terms of automation. The real driver for DevOps is the need to parallelize the complete software development lifecycle. It should be possible for an individual human being to take something off of a backlog and get it into production without blocking on anything, and especially without blocking on the slowest and least reliable thing in any organization: Namely, other human beings!<\/p>\n

\u201cThe big change for DevOps is giving individuals enough scope to develop, secure, deploy, and operate their own piece of a larger software application while minimizing the number of roundtrip communications with other people.\u201d\u00a0<\/b><\/p><\/blockquote>\n

This then brings us to automation: Once you\u2019ve eliminated blocking dependencies on other human beings, any good engineer\u2014DevOps or otherwise\u2013will always want to automate everything else that stands in their way, and with the broadened scope of DevOps, they finally can! So indeed there has been a lot of low-hanging \u201cautomation fruit,\u201d and that\u2019s super, but \u201cautomation != DevOps.\u201d Automation is just something wonderful that DevOps enables.<\/p>\n

A lot has changed in the last year. We know team culture and collaboration play a huge role in DevOps, and as we\u2019ve seen in our <\/b>2020 Octoverse Report<\/b><\/a>, many teams have had to find entirely new (remote) ways to address both. What changes have you seen to DevOps with this shift to remote work?\u00a0<\/b><\/span><\/a><\/h3>\n

Last year\u2019s mass-migration to 100 percent remote work has underlined the importance of self-reliance and parallelism in software development and operations. By consequence, there certainly has been more urgency and more need as far as DevOps is concerned. I also think we\u2019re all thoroughly sick of back-to-back virtual meetings, so there\u2019s been a refreshing added incentive to make the entire product development and deployment process \u201cself-service\u201d from the perspective of the people building and maintaining that software.<\/p>\n

On the operational side of DevOps, the shift to remote work means that you can\u2019t just walk across the office to \u201cthe haggard old-timer expert-in-everything\u201d when something breaks in production. Maybe you can find that person on Slack, but they might be in another window and it\u2019s certainly far easier for them to ignore you. That said, the pace of production changes continues to rise, and with each change there\u2019s new risk and new ways for services to interact in unplanned and problematic ways. So we need observability tooling that is built to take nothing more than \u201can unplanned change\u201d and help conjure up potential explanations\u2014dynamically, and without finding \u201cthe experts.\u201d This is certainly where observability is headed, and the shift to purely remote work is helping to accelerate that change.<\/p>\n

Let\u2019s zoom out a bit: What’s been the most transformative part of DevOps to software development overall?<\/b><\/span><\/a><\/h3>\n

Before DevOps was a thing, any improvement to software didn’t just require multiple people, it required multiple teams and even multiple organizations. To my mind, the single most transformative part of DevOps has been the parallelism and independence it’s brought to the individual software developer-operators themselves. As a side effect, these DevOps engineers are automating everything in sight\u2014which is fantastic!\u2014and we’re seeing organizations deploying software literally hundreds of times more frequently than they could before. It’s difficult to overstate the difference that can make, particularly when we consider the engineering-cultural implications and the compounding effects over the course of years.<\/p>\n

Speaking of parallelism and automation, we\u2019re also seeing security teams adopting these same practices in the form of DevSecOps<\/a>. In the future, do you think there will be a distinction between DevOps and DevSecOps? Or will security just become fundamental to DevOps as a whole?\u00a0\u00a0<\/b><\/span><\/a><\/h3>\n

Security is (obviously) a complicated topic. I\u2019m sure there are many intelligent and well-informed people who will disagree with me here, but so it goes! DevOps is a durable and valuable concept because 99 percent of Dev and Ops can truly be consolidated\u2014one person can fulfill multiple roles. Now, certainly many aspects of security can also be included in this: automated package vulnerability testing, real-time threat detection in production, tools that audit configuration, and so forth. It\u2019s all good, and I guess I can see how that might qualify as DevSecOps.<\/p>\n

The distinction in my mind, though, is that there are so many attack vectors that have nothing much to do with software development: your corporate email accounts, spear phishing, edge network hacks, DDOS, elaborate supply chain attacks like the recent SolarWinds exploit, and so on. So, while 99 percent of Dev and Ops can truly be consolidated, there are so many vital parts of a CISO\u2019s world that simply cannot<\/i> be managed by the person writing, deploying, and managing a service in production. For that reason, I certainly see security becoming one of many aspects of the \u201cOps\u201d in DevOps, but I am not a fan of DevSecOps as a term.<\/p>\n

While we may not have a perfect definition now, what does successful DevOps look like for you\/your team at Lightstep? How do you know when you\u2019ve \u201cmade it\u201d?<\/b><\/span><\/a><\/h3>\n

Good question, and over the years our Engineering, Product, and Design (EPD) organization has gone through different phases and iterations. I would say that, particularly after my experience working at Google for many years, I would never again want \u201cOps\u201d (or site reliability engineering in Google\u2019s case) to be its own separate part of the org chart. Incentives align when reliability and product goals are considered and balanced by a single team with a single strategy.<\/p>\n

That said, there\u2019s no single approach to DevOps that works at every scale. So as our customer base grows, and particularly as our EPD organization grows, we have to listen to each other and realize when the current set of processes and practices isn\u2019t working anymore. Do people feel like they\u2019re responsible for things they control? Is the scope of operational responsibility in line with the scope of development responsibility? Like any organization that\u2019s honest with itself, at Lightstep we are always learning and growing, and we\u2019ll never be able to say we\u2019ve \u201cmade it\u201d\u2014at least not in a durable sense. And that\u2019s fine. What\u2019s important to us is to be introspective and try to get ahead of issues before they become crises, and of course to lean into things that work well for us.<\/p>\n

You\u2019re joining us on a DevOps panel later this week\u2014where you\u2019ll also be answering questions live. What\u2019s something people should be asking about DevOps, but might not have considered yet?\u00a0<\/b><\/span><\/a><\/h3>\n

People often think about DevOps teams working cheerfully and perfectly in parallel\u2014completely independent of each other. This is as appealing as it is fictional! The reality is that the services that DevOps teams maintain depend upon and interact with each other in surprising and often problematic ways. What I want people to think about is how they can (a) plan better so that their \u201cindependent [sic]\u201d \u201cimprovements [sic]\u201d don\u2019t inadvertently ruin some other team\u2019s day or week, and (b) how they can respond more effectively when their own service goes sideways from someone else\u2019s change.<\/p>\n

With thousands of software changes going to production every week, we need a far more robust and dynamic way of understanding how changes in one service affect others\u2014and the DevOps teams responsible for them.<\/p>\n

Learn more about the future of DevOps<\/span><\/a><\/h2>\n

\"\"<\/a><\/p>\n

Want to hear more from Ben? Join him along with panelists from GitHub, Red Hat, and RedMonk for our next GitHub webcast this Thursday, February 4. We\u2019ll dive into the changes and trends we\u2019ve seen in how DevOps teams collaborate, including deploying on Fridays, treating monitoring the same as observability, and DevSecOps.<\/span><\/p>\n

When<\/b><\/p>\n

February 4, 2021
\n11:00 am PT \/ 2:00 pm ET<\/p>\n

Sign up for the webcast<\/span><\/a><\/p>\n