JAXenter: Who is leading the DevOps show? Developers or operators?

Jérôme: It takes two to tango, so I’d say both! The best developers are the ones who know operations (and how to write code with operations in mind). The best operators are the ones who know development (and how to automate their jobs). The point of DevOps is to make sure that both sides can (and actually do!) talk to each other. In some organizations, the pull to DevOps will come from developers (who are happy and eager to participate in deployment because it enables them to do a better job), in some organizations, the pull will come from operators (who are happy and eager to share the burden with developers to empower them). But you need buy-in from both sides.

JAXenter: The focus is slowly shifting from “What is DevOps?” Where do we start?”. How do we answer the second question?

Jérôme: I once said, “one way to start your DevOps journey is to get started with containers.” But I have also said, “using Docker (or containers) doesn’t mean that you do DevOps.” I stand by both statements, even if they sound contradictory at first. Using containers (to facilitate on-boarding and achieve consistent development environments, for instance) is a good way to get started. From there, you can move on to reproducible builds. Continuous integration is a great next step. From there, you can explore continuous deployment for QA and staging (for instance). And eventually, to production. It’s important to make sure that all teams are on board at each step, and remember that tools like Docker and Kubernetes are just tools, and can be misused.

JAXenter: How important is automation in a DevOps context and what are the areas where automation is really needed?

Jérôme: Computers are fantastic to perform repetitive jobs. A program or script will never forget or skip a task in a 25-steps checklist. It will never get bored or complain about completing seemingly useless verifications, tests, and safety checks. I think everything that will be done at least twice should be automated, at least if it is important to get the same result each time. (I won’t automate a jazz solo, since I expect interesting variations each time it’s performed, for instance. :-)) But “automation” doesn’t necessarily mean breaking out the big guns. The best automation starts as a README file that you leave for future you, when you will need to do the thing again in a few days or weeks and want to make sure that you won’t forget anything important. From that point, it can naturally evolve to a checklist, and then a shell script, and then (depending on the context) a Dockerfile, a Puppet manifest, a Helm chart, you name it. Another important detail is to resist the temptation to write things that are overly generic. Should I make sure that this install process works fine on different versions of Debian? On Debian and Ubuntu? On Fedora as well? On Intel 32 and 64 bits? What about other architectures like ARM? It’s important to know where to draw the line.

JAXenter: Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?

Jérôme: Yes and yes! You cannot release quality software without testing. (Anyone telling or believing otherwise is lying or lulling themselves.) But automating tests is hard, especially when you haven’t done it before and don’t know where to start; or when a project is still evolving very fast. There again, it is necessary to put the boundary at the right place; and that requires experience.

JAXenter: Some companies are still struggling with DevOps metrics. What are the key metrics that matter and how can they enhance DevOps success?

Jérôme: There are many metrics that you can use as a proxy to figure out if you’re “doing it right.” How long does it take for a new developer in the team to stage up their local development environment? How long until they can get their first commit into production? How long does it take for a fix to be deployed? To roll back an older version? To scale up? In all these operations, how many people have to be involved and why? (Are they involved because nobody else knows how to do it, or because they are the ones to assume responsibility?) And of course, we can tap into more classic metrics like uptime, response time, user satisfaction … Since at the end of the day, it doesn’t matter how stable your service is, or how fast you deploy. What matters is the value you deliver to your customers or users and (if you’re a for-profit company) your revenue.

JAXenter: How important is it to not skip steps in the DevOps transformation cycle? What are the steps that companies and/or teams usually ignore or underestimate?

Jérôme: I’ve seen too many teams and organization try to go straight from “works on my machine” to “works in production.” Instead of taking that huge leap of faith, I often suggest to go through a number of intermediary steps, including but not limited to continuous integration, continuous deployment to staging and QA, etc.; each step helps to build skills and confidence that will be critical when going to production.

JAXenter: Do you think the abundance of DevOps tools have helped or slowed down DevOps adoption?

Jérôme: Helped! Of course, sometimes it can slow things down a bit on a local level, because people are waiting to see which particular tool is going to “win” or be better suited for their needs. And that’s perfectly fine! But I’m glad that today we have Ansible, Chef, Puppet, and Salt; that we have Kubernetes, Mesos, Nomad, and Swarm; because they all have different strengths and weaknesses and this is not a “one size fits all” situation.

JAXenter: There’s a huge demand for DevOps professionals. What skills do you need to have in order to tap into the perks that accompany the job description?

Jérôme: Curiosity, empathy, perseverance (in alphabetical order). I’m aware that these are more like personality traits rather than skills per se, but these things will help you to build up everything else that you will need.

Thank you very much!