Have you ever wondered what is behind the success of a car assembly line? How they manage to optimise work and minimise waste, operating only on what brings value?
In 2009, John Allspaw from Flickr spoke at the ‘Velocity’ web conference in San Jose, claiming that his team deploys software to production 10 times a day and that the process is enhanced by close collaboration of the Development and Operations divisions. Back then, the audience in the room couldn’t even imagine it, but they felt it was a breakthrough moment. Those who shared Allspaw’s views on breaking the silos between Devs and Ops started a new series of meetings called ‘DevOpsDays’, which remain very popular to this day. The relation is not clear-cut though. There are many misconceptions related to the DevOps environment, even among IT specialists. That’s why I have asked Adam Nowak, the Development Process Practice Lead at Netguru, to explain what exactly is DevOps and why it is more necessary in the IT industry than ever.
First of all, DevOps is not a single person. It can be done by a person, an engineer, but it is a process, or more generally speaking a culture. It originates from IT companies, as it is a proven model for production of software and digital solutions. Recently it has become so popular that everybody wants to work in a DevOps environment. Why exactly? Because it is a culture based on open feedback, work automation, team communication, and continuous learning. It stands on the idea from the book ‘The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win’ by Gene Kim: “Improving daily work is even more important than doing daily work”. Which means everybody should devote some time to learning, experimenting and organising their work better, instead of focusing solely on day-to-day, urgent tasks.
Since the ‘Velocity’ conference in San Jose in 2009, DevOps indeed became a buzzword. All the companies started trying to introduce it within their structures. Soon, they realised that it’s not enough to hire someone to “do” DevOps to have such a culture in their organisation. The entire company has to work by its values. Just like it happens at a car assembly line, where each part of the process is automated and serves a bigger purpose.
These days DevOps is a process facilitator no company should operate without, especially in IT. The more software you produce and digital solutions you provide, the more you need it. It was introduced years ago in such tech giants as Netflix, Etsy, Spotify, Facebook, and Google. The latter ones have upgraded the concept even further, to Site Reliability Engineering (SRE).
A DevOps engineer is someone who delivers quality both to the work environment and the final product expected by a client. He or she does that through a certain flow, very much alike the linear process of assembling a car - in a simple pipeline - from the left to the right. It’s up to DevOps role to ensure that the automation of work is done effectively and smoothly, without bottlenecks and waste. To avoid unnecessary costs, the DevOps engineer makes sure that the code gets reviewed in very short loops and is improved piece by piece.
Additionally, he or she minimises repetitive work of the delivery team and, if needed, builds a toolset supporting it, allowing them to focus on more productive tasks. In other words, the engineer is expected to provide assistance at all stages of product delivery. Whenever you need to spin up a new server, set up a production or staging environment for a project, upgrade a machine or get a security patch, a DevOps engineer acts as a consultant in the process. There are instances when their work resembles a doctor's work - they are available ’on-call’ and, in case of an emergency, diagnose a problem with monitoring or telemetry and fix it.
In this role basic skills in development are required, and a willingness to continuously learn and experiment is very welcomed.
Yes, according to the annual State of DevOps Report, in organisations which introduced a DevOps culture the burnout rate among employees decreased. DevOps makes people cooperate with each other, prevents them from working in silos and sparks innovation. The employees are driven by the goal of having a positive effect on everybody’s productivity and happiness at work.
It has been proven that if people feel good in a company they work for, they are more motivated and effective. Conversely, the more effective they are at work, the more satisfied they are with the job. They don’t feel tied up to routine, have a more enthusiastic relation with clients, and don’t even consider changing companies. Consequently, staff turnover doesn’t slow down business growth.
A DevOps engineer is interested in the work at the intersection of delivery and operations, not in either of the two in particular. Which means that he or she is curious about each phase of the process - how the QAs test, how the Ops put it all on the server, how the PMs manage the tickets. Of course, to do well as a DevOps engineer it’s good to know the first thing about a software, so that in case of an emergency you can diagnose an error and fix it yourself. On the other hand, when working in operations you have to realise that creative work on code is only a part of a bigger picture - a process which implements it in an app and makes it alive. The DevOps philosophy knocks down silos and promotes a more diverse and inclusive approach to software production.
Hence, the roles may intersect, but are not interchangeable.
Before you start browsing the courses, ask yourself the question: what was the last thing I automated? If nothing comes to your mind, give applying a second thought. This work requires a natural knack for improving everyday workflows, eliminating repetitive tasks and reducing the so-called toil. You should be familiar with CI/CD processes, have some knowledge about servers and monitoring, and be able to operate them. If that’s in place, you can take the next step. Basic skills and DevOps tools can be learned online - follow this link to get a list of 10 DevOps courses for experienced programmers. You will learn how to deliver better software and they will help you excel in deploying software using Git, Vagrant, Chef, Ansible, Jenkins, Docker, and many more.
DevOps is all about mindset, so if you’re into constant learning and want to get some DevOps background, I definitely recommend turning to literature about the subject. Books like „The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win” and „DevOps handbook” by Gene Kim are must-reads. If you prefer to listen to podcasts, Red Hat’s “Command Line Heroes Season 1” covers the entire history and the possible future of the DevOps movement and the problems it solves. If you already work in a team and want to improve your DevOps skills, e.g. focus more on diversity, the most helpful resources are devops.com (together with their “Devops Chat” podcast), the “DevOps Radio” podcast or the DevOps newsletter “Devops Dispatch”. Finally, Javin Paul provides quite a solid guide to becoming a DevOps Engineer with links to relevant courses in his article “The 2019 DevOps RoadMap”.
But please bear in mind that although there are DevOps tools which you can easily find online, learning them will never replace practice and testing them with a team.
Let’s clear this up - DevOps is not bad, it may just be badly implemented. One of the common misconceptions about DevOps is that it is sufficient to transfer servers to the cloud, but this doesn’t solve any problem in the organisation. Nor is it enough to call somebody DevOps to have such a culture in the company. A certain trap you can get yourself into is when you specialise people in Ops so that they take over ownership for all the processes. It builds a wall in no time and makes other team members, such as devs, less willing to share responsibility for the project. Imagine that you have 5 DevOps in a 500-people company, and only they can manage certain processes. That being the case they will never manage to satisfy all the needs. And too narrow a specialisation of a position makes people focus only on their part of the job and miss the bigger picture.
DevOps engineers shouldn’t replace devs in their work, but only improve it.
Finally, at the first glance DevOps may seem redundant or threatening to the “here and now”, to everyday effectiveness. “We are supposed to deliver 50 items today and we will, no time to lose on talking” - speaks the voice of productivity. Even though an improvement to the workflow may allow you to start completing 70 items per day. Daily tasks may indeed seem more urgent, but if we don’t sharpen the saw we’re cutting the tree with, the problems will accumulate and get us double-barrelled.
By and large, DevOps should be the workflow of every company, always. This is because in a DevOps environment the organisation of work is better and the business is less susceptible to unexpected circumstances. Employees are not tied to their chairs and limited by a closed set of tools. They can develop a more enthusiastic approach to work, which improves relations with clients. You deploy more products more often and minimise the chance of failure, not to mention the increase of business value.
Nevertheless, by definition DevOps is all about evolution, so it has to evolve as well. We can expect it to be heading towards SRE in the near future, which has already happened in the case of tech giants like Netflix, Google, Facebook. They are reducing departmental miscommunication by installing team-lead engineers who have an operations background and mindset. SRE, together with security solutions, are now the most trending organizational structures around the world.