JAXenter: Who is leading the DevOps show? Develops or operators?
Quentin: I think that the majority of the demand comes from the developers side, from a long period of time where infrastructure stagnation and frustration have lead to this rush to push ops to give developers more space on management… Which is sad, because DevOps has to be a common and shared approach to help the whole team be more efficient, without overpowering one another. The result is often a “hello world” driven architecture, mainly based on deployment agility sacrificing stability, monitoring, uptime and security to the rush. The cultural gap with sustainability is clearly coming from the ops side and is not filled today. I hope the relation will be more balanced in the future.
JAXenter: The focus is slowly shifting from “What is DevOps?” Where do we start?”. How do we answer the second question?
Quentin: There are simple and more technical questions to answer. If you really want to change the way it works, management has to change its point of view. Lots of companies have different budget and incentive between the ops team and the dev team. Basically you have developers that need to ship new code to production as fast as possible to maintain the edge of their company, and on the other side you have ops that are incentivised on making sure everything is stable, safe, and to reduce production costs. This leads to a conflicting culture inside the company.
The best way to make them work together (the real idea behind devops) is to reunite the teams with only one budget and organisation, with in-line goals. It will be a good signal from top management to help teams implement DevOps for real.
From a tech perspective, I think the best way to “go DevOps” is to start a clear inspection of the code base tooling: Is the project buildable in one command? Makefiles everywhere? It’s the first question to ask, because DevOps is mainly automation of the ops tasks. And the first thing is being able to easily build every source code in the organisation. Building solid bases is important, more than setting up a complex distributed workload orchestration system.
Start by automating things you already do. If you create lots of MySQL databases, then automate database creation, monitoring and backups; you will only be good at it if you do it often, you need to automate things you really do, not the hype stuff.
From a cultural perspective, developers need to understand some networking and system level stuff; learn about linux, containers, systemd and many others things to be able to speak with the ops. The Ops need to think about the future, and learn how to code.
JAXenter: How important is it to incorporate security into DevOps (DevSecOps)? What are the benefits? Should it be a priority or an afterthought?
Quentin: The Importance of security when it comes to infrastructure is paramount and has to be at the center of all the processes. I don’t think security should be a separate process. We all need privacy by design and in-depth security; my colleague Geoffroy Couprie wrote an article about this: “The End of the Fortress Metaphor” https://www.clever-cloud.com/blog/guests/2015/06/16/the-end-of-the-fortress-metaphor/ explaining this new way of building software with security as an important parameter in the process.
Now of course there are many levels of security. How absolute can you be when implementing this security process? It’s your choice. We, as a cloud platform, can’t compromise. It’s for instance one of the reason why Docker containers running on Clever Cloud are isolated in a VM. You might think it’s ok to share a kernel between containers; we do not.
JAXenter: How important is automation in a DevOps context and what are the areas where automation is really needed?
Quentin: Anything that can be automated should be automated. It’s one of our core values and we built Clever Cloud for this. As a species we have been automating everything from the beginning of technology, software is no different. We don’t like to repeat things endlessly.
In the DevOps context, it means enabling that culture of automating things. And that’s how you see traditional Ops writing more code, and being included in feature teams as DevOps.
Automation is the best way to be able to level up standards inside the company: always deliver production-ready quality.
JAXenter: Should testing become an essential component of the CI/CD pipeline? Are we underestimating its importance?
Quentin: I see testing in the same manner as I see security. How absolute do you want to be? There is always a balance to strike between the effort you want to put in and the expected results. (Which is why we give you security by updating software you are running on automatically, so you don’t have to, because we are nice people like that.) And it has become so easy to integrate testing as part of a CI/CD pipeline that I believe it should be included. One should always consider the tradeoff of time spent by the developers on designing the tests versus the actual gains of course.
JAXenter: Some companies are still struggling with DevOps metrics. What are the key metrics that matter and how can they enhance DevOps success?
Quentin: There are two hard measurements that I think we should talk about first. And these are “How well does your team sleep?” (“Clever Cloud, selling sleeping hours since 2010”) and “Can you ship ideas to production before that idea becomes irrelevant?”.
The final goal of every good DevOps has to be NoOps: the ability of the automation to manage the entire stack at minimal human cost. Too many teams focus on tools and not on optimization, that’s why simple business metrics are so important. Some call it Serverless (ok, often to describe proprietary lock-in solutions), but the major point is to remove server management and not the server itself (I wrote about this, here: https://medium.com/@waxzce/code-running-on-ionized-particles-or-wtf-is-serverless-9517e30012b6 ), and the final goal is to make software evolutions as easy as possible, to help business evolve. Maybe the ultimate metrics in a big company will be the organic reduction of shadow IT, because working with internal IT becomes more and more comfortable.
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?
Quentin: DevOps being first and foremost a cultural change, you can’t really skip anything. If you try to go too fast, changes won’t stick and you’ll be back to your old ways. Don’t try to transform everything suddenly. Changing culture takes time and has to be gradual.
You need to put the accent on learning, because DevOps relies on serious skills around networking, linux, system… Learning is the key to be successful. Use tools you understand better than cookbooks and dark wizardry, hoping it will do the job.
JAXenter: Do you think the abundance of DevOps tools has helped or slowed down DevOps adoption?
Quentin: Tools are accelerators. Which can be good or bad depending on the tool and the moment you are using it. If you are not ready culturally it can lead to misunderstanding or failure. And people usually don’t like to try the same thing again after a failure.
Globally I would say it is a great thing but should not be seen as the only answer. Culture first, tooling second. They will however take more and more importance as the Devops culture matures, resulting in a bigger user base and so hopefully more enhancements, features and empowerment for Devops practitioners.
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?
Quentin: First you need to understand what DevOps means. Which is not as easy as one would think. 🙂 Understand that you need to work inside a team and enable that team to deliver smoothly, safely and as often as possible.
If you want to be more practical on the actual skills department, in 2018 it would be looking for people that are familiar and understand three basic Cloud/Distributed software concepts: 12 factors, the reactive manifesto and the CAP theorem.
Purely technical skills are not necessarily relevant and will be learned on the job.
The other aspect is the one I explain in the book keepers conference (https://www.youtube.com/watch?v=OngWRJ8txps): DevOps is the union of developers and ops in one task force, with the same in-line goals, the same budget. And as “devops” your main goal is to avoid being trapped in a weird situation where devops are in the middle of ops and dev.
Thank you very much!