DevOps Ad Absurdum
DevOps is about communication and responsibility. A great product is the result of great cooperation.
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.
What Is 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. All team members are included: developers, operations, testers, QA, support, infosec, product owner, etc.
The team as a 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?
An individual who makes a decision becomes more invested in its outcome. ~ S. McChrystal
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.
What Is DevOps Not
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.
DevOps before and after
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).
Nowadays there are tens to hundreds of options for every little piece of the development. Technologies have been involved a lot and it's really difficult just to keep track of them all. In each category there are plenty of libraries, frameworks and programming models to choose from. You may stay aware but having hands-on would probably require skipping sleep whatsoever. Consider just programming languages for backend development: Java, Kotlin, Scala, Clojure, Ruby, C#, F#, Go, Python, Rust, PHP, JavaScript, TypeScript, Erlang, Crystal or C++; frameworks for frontend development: React, Angular, Vue, Svelte, Preact, Ember, Web Components; databases: PostgreSQL, MySQL, MariaDB, Oracle, MongoDB, Elasticsearch, DynamDB, Cosmos DB, Redis, Couchbase, Cassandra, Scylla, Neo4j, ArangoDB, and so on and so forth.
Can one have practical experience and deep knowledge of all of them? I don't really think so.
Even as "just" a frontend developer you can't probably excel in all the frameworks and JavaScript libraries available on the market, so how could you as a backend developer? Unless you're a 10x engineer, which you are not, because they don't exist. However, recruiters and managers still may have all those required skills on their wishlists.
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.
Conclusion
DevOps is about communication and responsibility for a product as a 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 power 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.