The biggest challenges facing DevOps
JAXenter talks to Jeff Sussna about the evolution of DevOps, vast and deep lean practices, and what companies could be doing to up their continuous delivery game.
DevOps puts collaboration and communication at the forefront of software development. But for all this emphasis on harmonious workflow, there’s a lot of disjuncture in how it’s applied across the industry. Ingineering.IT Founder and Principal and thought-process challenger Jeff Sussna (@jeffsussna) gives us an insight into where people are going wrong, as well as his opinions on hot-button topics PaaS, CD, and lean methodology.
JAX: What do you think are the biggest challenges in ‘DevOps’ culture, and how have they changed over time?
Sussna: I think DevOps has challenges similar to those facing Design Thinking. Both are approaches, or mindsets, not methodologies. They both represent a shift away from organizations based on industrial practices. We all still want to treat them as prescriptive practices we can adopt in an assembly line fashion, when in fact they are challenges to shift the way we think.
I think the challenges around DevOps have shifted from just understanding what it is, to understanding how to apply it rather than adopt it. As the term gets more popular, the pressure, from vendors and pundits and literature, to pull it back into the old conceptual model increases.
Is there anyone out there who you think fosters a truly excellent working culture for DevOps teams? How do they do this?
When I first heard the word ‘DevOps’ I was working for a SaaS startup. My initial reaction was “well, duh, how else would you do it?” In startups everyone cares about the customer, because they have no choice. Everyone cares about whether the code works and whether the infrastructure works, because they have no choice.
Dev and Ops work cheek by jowl, and sometimes sleep on the office floor next to each other. It all starts with a sense of shared mission and accountability. Enterprise micro-service architectures can help DevOps in larger environments because they break big, monolithic silos into smaller, coherent service teams that have a shared mission to support customers (other services within the enterprise).
At the other end of the scale, what do you think are the biggest mistakes IT organisations make in setting up DevOps?
Unfortunately this question is easy to answer. The biggest mistake IT organizations make in adopting DevOps is to try to solve the problem with a prescriptive methodology or a big, expensive, all-in-one tool. This approach makes it easy to miss the critical component which is that sense of shared mission and accountability.
Are there any DevOps tools that you would recommend?
I recommend every organization that wants to adopt DevOps start with Vagrant. Developers, testers, and admins all should use it. It’s a very simple tool that has a powerful amplifying effect in getting developers and admins starting to think about the same problems in the same ways. It also helps start the automation and Continuous Delivery journey at the right point: on everyone’s desktop.
What typifies the ‘lean approach’ to you?
Lean is a vast and deep topic, so I won’t try to provide any kind of comprehensive answer. To me, Lean means continually striving to maximize our ability to deliver customer value, and to minimize obstacles to that ability. Obstacles could take the form of wasteful processes such as manual sign-offs that take days to complete. They could also take the form of wasting time and energy building functionality without validating its relevance to customers.
What do you think have been the most instructive experiences you’ve had to date in helping you shape a ‘lean mentality’?
The most instructive experience I had involved integrating security testing into a Continuous Integration process. Instead of coding for three months, then entering a lengthy security testing phase with multiple test-fail-fix cycles, we ran security scans on every code-check in. When it came time for the governance-mandated security phase gate, our application was the first ever to pass on its first try. The extra upfront effort was minimal. The downstream benefit was huge. Perhaps even more importantly, our approach dissolved the adversarial relationship between InfoSec and Development.
You’ve said on your blog you want the discourse from PaaS providers to change. What would you like to be hearing more of?
I’ve long been a fan of PaaS on general principle. I think, though, that the discourse needs to mature. The current discourse tends to have a bit of a Dev vs. Ops tone: “PaaS frees developers from sysadmins”. What drew me to PaaS in the first place was the intuition, based on my experience, that PaaS could benefit both sides by giving developers freedom within a safe-and-sane operational environment. I’d like to see more concrete discussion of how PaaS can benefit everyone involved in delivering IT services.
Continuous Delivery is becoming a new ‘norm’ – what can companies do to up their capabilities in this respect?
They should make sure they know the key characteristics of Continuous Delivery: small batch sizes, fail-fast, and decoupled releases. Continuous Delivery isn’t about pushing junk into prod faster with fewer controls. It’s about improving quality by reducing complexity. It’s easier to code-review, integration-test, and diagnose production problems due to a 1-line code change than a 1000-line change.
Continuous Delivery increases speed, ironically, by failing earlier in the life cycle. The earlier you find problems, the faster, easier, and cheaper it is to fix them. Finally, Continuous Delivery gives the business greater control, not less, due to things like feature flags that let IT do technical releases when they want, while letting marketing do customer releases when they want.