In my previous post I briefly mentioned the importance of a good DevOps culture in an organization as an enabler to build state-of-the-art software, especially in the cloud environment.
The role of DevOps is crucial in modern software development and, at the same time, often misunderstood even by professionals. Creatively, new meanings were assigned to the term recently, and things got worse once again.
Is DevOps completely profaned or is there still a chance?
First, let’s summarize what I mean when talking about DevOps.
DevOps is a mindset, a way of working, not a job title or a department. That is, DevOps is not the guy who’s taking care of your server or pipeline. In a true DevOps model, everybody is a DevOps engineer. Although the name is a bit misleading, not only developers (Dev) and system administrators (Ops) are involved. Any team member is included: developers, operations, testers, QA, support, infosec, product owner, etc.
The team as whole is encouraged to make decisions and overtake responsibility. Really, there are no such titles as “Principal Senior Lead Architect” in an organization practicing DevOps. All in all, even the most inexperienced developer can sometimes bring the best ideas, can’t she?
DevOps is about communication. It attempts to avoid silos inside the organization where people with different technical responsibilities can’t effectively communicate with each other. Conway’s law is worth mentioning here.
Unfortunately, DevOps quickly became a buzzword. I’ve seen the true meaning of DevOps being ignored not only among recruiters and managers, but sadly, often also among developers. A typical misconception is to consider DevOps as a job title, to simply put an equal sign between DevOps and sysadmin. At the end of the day, there is no improvement whatsoever, just different job titles. The walls remain.
As if that wasn’t enough, lately I’ve been seeing another phenomenon that attaches a completely new meaning to DevOps. Sometimes, it’s close to the 10x engineer, a mystical person who knows practically everything about everything.
DevOps, Full-Stack and 10x Engineer
About 10 years ago, I was working as a full-stack developer without even noticing it — the term was simply not established yet. The technology stack was not as rich as it is today. For a lot of things there was just one (right) way to go for and it was still possible, though not easy, to master the entire stack in a particular field (such as web applications).
Can one have practical experience and deep knowledge of all of them? I don’t really think so.
One way out is to understand a full-stack developer as a developer with great skills specific to one field and some knowledge of the others. For example, a backend Java developer who can fix a bug in a React based application, when necessary.
Similar with DevOps. In the era of cloud computing it might be tempting to let the developers do all the operations work in addition. From setting up a build pipeline to monitor the running system in production. A lot of articles even advise doing so. While it’s definitely worth it for developers to have some level of awareness about the deployment process and operations, the field is just too big to be fully mastered by developers themselves. With Infrastructure as code setup, a developer can (and should) be involved in designing and programming infrastructure, however, she rarely possesses time and required skill to operate the system completely.
Operations is a full-time job that requires skilled and experienced professionals in many topics such as system administration, operating systems, hardware provisioning, networking, infosec, monitoring, identity and access management, tools, etc.
It’s absurd to think that someone can possibly master all those together with all required developer skills. Unless you’re a 10x engineer, which you are not, because they don’t exist! Unfortunately, this is exactly what the common understanding of a DevOps engineer nowadays is.
Such a situation, typical for startups with early and wild adopting new trends often without actually understanding them, leads to two possible results: 1. system is poorly operated, 2. one or more developers become full-time system administrators. The latter doesn’t have to be necessarily a bad thing, if you have enough developers (usually not the case), but can easily result in a lack of people in development and consequently poor quality of the actual software solution.
One exception could be a small product with a little operating overheads, typical for early phases of new products. As the product evolves, it will be necessary to review this strategy.
DevOps is about communication and responsibility for a product as whole. It’s not about a new kind of specialization or almighty superpowers. 10x engineer is a myth and you shouldn’t waste time looking for her. Instead, aim to have excellent developers, excellent sysadmins, excellent testers, etc. Remove barriers between them. Trust people to do the best work they can, give them the responsibility to do so, bring them together and build a great team with a common goal — a product that delights users.
People always tend to excel in one thing while being unhandy in others. This is perfectly natural. Accept that and prosper from it. Different skills are required for successful product development. A great product is the result of great cooperation.
All-in-one DevOps unicorns don’t really exist.