The biggest challenges facing DevOps

Lucy Carey

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

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

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

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

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

Are there any DevOps tools that you would

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

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

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.

comments powered by Disqus