Top 10 DevOps Myths: Separating Fact from Fiction

DevOps – it’s just a marketing buzzword with no substance behind it, right? Or perhaps there’s more to it than meets the eye. Is DevOps simply a collection of “correct” tools, or is it a specialized culture? And who exactly should be responsible for it, and what does a DevOps engineer entail? 

In short, there are some misconceptions abound, some trivial, some deeply rooted in the minds of respected professionals.

Myth #1: DevOps Can Be Done by a DevOps Department or Engineer

To achieve proper DevOps, we hire DevOps engineers or create a DevOps department, and voila! We’ve got full-fledged DevOps in our company!

This sentiment is quite pervasive. Despite numerous materials explaining why there’s no such thing as DevOps engineers or why creating a DevOps department isn’t advisable, DevOps departments still emerge, and DevOps engineer vacancies continue to increase.

Here’s a scenario I often encounter: a typical company where nothing much happens until the CEO or the board catches the “digital transformation” bug. It’s a highly contagious disease usually contracted at conferences for CEOs or top management. Suddenly, terms like Agile, DevOps, digital, product, etc., start popping up in their heads. The CEO gathers the troops and says, “Guys, we need Agile, DevOps, digital, figure it out and make it happen.”

In reality, it’s not the CEO’s task to delve into all of this. They’ve figured out, for instance, how to increase revenue, value streams, and realized that it correlates with these buzzwords.

Then the team starts brainstorming. They read about DevOps on Wikipedia: “A methodology that unifies developers, operations, and testing for continuous software delivery.” 

In their company, software delivery is continuous, deployments happen every three months, developers and sysadmins hang out together at bars – there’s no issue with collaboration. So, they decide to rename some department to DevOps.

Ultimately, either the quality assurance department gets renamed to DevOps or the operations department – depending on the experience of the individuals involved. But what to do with that department if it’s filled with quality/issue engineers? They need to be renamed to DevOps engineers too?

I regularly browse through DevOps job listings because we and our clients are looking for engineers. You can check out job search websites yourself; they’re all so diverse!

There’s no strict standardization or typification: from people setting up pipelines on Jenkins to testers writing automation scripts; from specialists deploying on AWS to those configuring monitoring, rolling out software, etc. Every possible IT profession is labeled as a DevOps engineer.

The exception is small companies genuinely producing digital products with real continuous software delivery. They seek people who can do it all because it’s hard to pinpoint a specific qualification. So, they simply advertise for a DevOps engineer position listing everything – Jenkins, Ansible, Chef, Docker, Kubernetes, Silex, Prometheus.

The most crucial aspect of needing DevOps is to create value flow throughout the company. DevOps should cover everything from analytics to actual operations. It’s not a separate profession or a designated role; it’s merely a concept that facilitates rapid digital product delivery.

The first mention of this term dates back to 2009 when Patrick Debois said at a conference: “We’ve started using a new approach. We’re now producing digital products, and we have a problem – the old ways aren’t working. I alone can’t solve it. I invite everyone to join the community to figure out how to live with this. Let’s call this problem DevOps.”

DevOps is the solution to the problem of producing digital products. It’s a methodology. Calling an individual by that term is incorrect.

If you’re seeking a DevOps engineer, consider why you need one. It’s better to specify a particular skill set and look for it in the market than hire an ambiguous specialist.

For the financially prudent: typically, a system administrator with Docker knowledge differs from a DevOps engineer with Docker knowledge not in skills but in price.

Myth #2: DevOps is about Hiring Jack-of-All-Trades Specialists

Let me share my interpretation of where this problem stems from. When the whole DevOps saga was just beginning, indeed, all the work was done by jack-of-all-trades specialists. For example, one person would build the delivery pipeline, set up monitoring, and so forth. I started from the same point and did everything myself because I didn’t know whom to delegate tasks to: I needed to research here, tweak there, and implement something else. As a result, I became a jack-of-all-trades specialist who configured Linux, wrote Chef scripts, integrated with Zabbix API, and more. I had to do it all.

But in reality, this doesn’t work.

Productivity:

• 18 jack-of-all-trades craftsmen capable of making a pin each produce 360 pins per day.
• 18 craftsmen divided into 18 specializations produce 48,000 pins.

This is a well-known example of production increase in a pin factory from Adam Smith’s book. In reality, the story about these pins wasn’t invented by him but rather borrowed from a British encyclopedia.

This logic still holds true today. When I hear that specialists should be cross-functional, I actually think that teams should be cross-functional, but certainly not individuals. Otherwise, we end up needing to produce 48,000 pins but simply don’t have enough people.

In the book “The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win,” there’s a story about Brandon, who does everything in the company, and everything bottlenecked around him. This is precisely the story of a talented jack-of-all-trades specialist.

But then the question arises – if not hiring a jack-of-all-trades specialist, then whom to hire? There’s no clear answer to this question. We don’t specify specific specializations for people working in DevOps.

I’ll try to outline these roles broadly and invite you to join this work because without role division, we’ll always be talking about jack-of-all-trades specialists.

DevOps, other roles:

• Developer with an understanding of architecture and production software work (writes tests and infrastructure code)

What sets this developer apart from a typical university graduate? A developer from a typical university can write algorithms – and that’s about it. A DevOps developer not only can write descriptions but also knows how these descriptions come to life.

I came to IT from radio electronics, and what amazed me here was that people think that a schematic diagram is a working product. An engineer in radio electronics doesn’t have such a misconception, but in IT – it exists.

We need developers who know that a schematic diagram is not a working product. There are few of them; they come from related fields – like radio electronics.

• Infrastructure Engineer (writes bindings for infrastructure, provides a platform for developers)

This role is so rich that it can be further broken down. Essentially, it includes a product owner manager who owns the continuous delivery platform product and the individual competencies of people who build this delivery platform. But this is for large companies.

For small companies, it’s simpler. This is an engineer who is well-versed in configuration management, knows Docker, Kubernetes, can create a continuous software delivery process based on them, and hand it over to the developer.

• Developer of infrastructure services (DBaS, Monitoring as a Service, Logging as a Service)

These are services provided to developers as a product. Note that you can go to Amazon and buy these individual services. Amazon can be considered a DevOps role model; that is, what they sell can be grown internally.

• Release Manager (manages the process and dependencies)

This isn’t the person who builds the build. They manage dependencies, versions, facilitate team agreements on integration environments, oversee the continuous delivery pipeline, and so forth.

They are the fairy who endows your team with magic so they can continuously deliver software.

Myth #3: We’ve Been Doing DevOps Since 1995

“We’ve been developing our corporate IT system for many years and have been releasing every week. Your DevOps is just a bunch of millennials in jeans with rolled-up cuffs who came along and renamed what we’ve been doing for years.”

This myth stems from a misunderstanding of what DevOps truly entails and a misinterpretation of the time-to-market concept. Some organizations believe that because they release software frequently, they are already practicing DevOps. They may view DevOps as simply a rebranding of their existing processes rather than a fundamental shift in approach.

The reality is that DevOps is not just about the frequency of releases; it’s about the entire software delivery lifecycle, from development to operations, being optimized for speed, efficiency, and collaboration. While releasing every week is a positive achievement, true DevOps involves more than just release frequency.

One of the key principles of DevOps is continuous improvement, which means constantly refining and optimizing processes to deliver value to customers faster and more reliably. It’s about breaking down silos between development, operations, and other teams, fostering a culture of collaboration and shared responsibility.

Another misconception related to this myth is the idea that DevOps only becomes relevant during incidents or emergencies. While it’s true that DevOps practices can help teams respond more effectively to incidents, they are equally important during normal operations. DevOps is about building resilience and reliability into the software delivery process from the outset, not just reacting to problems as they arise.

Ultimately, DevOps is about delivering software that meets customer needs quickly and efficiently. It requires a mindset shift and a commitment to continuous improvement, rather than simply sticking to existing processes and routines.

While frequent releases are a positive step, true DevOps involves a holistic approach to software delivery that goes beyond release frequency and encompasses the entire lifecycle of software development and operations. It’s not just about what you’ve been doing for years; it’s about how you can do it better.

DevOps Practices for TTM (Time-to-Market)

I’ve outlined some core DevOps practices focused solely on time-to-market, without which continuous feedback from your customers and the market is unattainable.

• Release Strategies (blue-green deployments, canary releases, A/B testing):
  It sounds good and quite simple — let’s roll out to 0.1% of users. But to do this requires monumental effort, such as transitioning from a monolithic architecture to a microservices architecture.
• Continuous Monitoring:
  This is monitoring akin to testing, where developers describe, in code, what needs to be monitored in production. Afterward, the artifact, along with the description of what needs monitoring, is pushed through the pipeline, and everything is added to monitoring at every stage of continuous delivery. This allows a real look at what’s happening with the application.
  When you’ve deployed to 0.1%, you can understand if the software is working as intended or if something is amiss. It’s pointless to deploy to 0.1% if you don’t know what’s happening with the software.
• End-to-End Logging:
  This is when, via an ID, you can see in the system how customer data has changed: they come in through the frontend, then to the backend, then to the queue, where they’re picked up by an asynchronous worker. The asynchronous worker then goes to the database, changes the cache state, and all of this is logged. Without this, figuring out what happened in the system is impossible, and deploying to 0.1% is futile.
  Imagine you decide to deploy some new software to all 2,000 attendees of the “International Internet Technologies” festival, but you lack end-to-end logging. These 2,000 people complain that it’s not working. You ask them what’s wrong because from your perspective, it’s like some kind of poltergeist. It’s a futile endeavor.
• Automated Tests (as a form of agreement between teams):
  Automated testing has long been known and used for improving software quality. However, automated tests need to be approached differently — as a form of agreement between teams. Instead of resolving numerous small issues in the software during integration, teams agree that each team writes automated tests and addresses these issues at the stage of developing individual modules, elements, etc. Writing automated tests is a separate story.

All these described components — DevOps practices for TTM — require a lot of time and effort if you’re not starting from scratch, but rather, for example, rewriting a monolith. However, without them, achieving a high time-to-market is impossible.

Myth 4: DevOps is all about the “right” tools

There’s a common belief that DevOps can be achieved simply by adopting the “right” tools. It’s like assembling a toolkit with Kubernetes, Ansible, Prometheus, Mesosphere, and Docker, and expecting instant DevOps success.

However, this approach often leads to disappointment. Organizations might install Kubernetes, for example, use it for a while, and then realize it’s not as effective as they hoped. They find themselves grappling with too many components, encountering glitches, and realizing that manual processes might have been simpler.

While powerful tools are certainly valuable, they’re just one piece of the DevOps puzzle. True DevOps isn’t just about the tools you use; it’s about the cultural and process changes within your organization.

That said, there are indeed tools specifically designed for DevOps, created by the community that emerged around the DevOps movement. These tools come with not only installation instructions but also comprehensive guides on how to leverage them effectively.

For instance, when you install Git, you don’t need to understand the intricacies of hashing algorithms. Similarly, with Kubernetes, it’s more important for engineers to understand how to work with it rather than the internal workings of the platform.

While the “right” tools are important, they’re not a silver bullet for DevOps success. It’s crucial to focus on building a culture of collaboration, automation, and continuous improvement alongside tool adoption.

Myth #5: DevOps is only for large organizations

DevOps can benefit businesses of all sizes. Smaller companies may even find it easier to adopt a DevOps culture due to their agility and fewer layers of bureaucracy. DevOps principles like continuous integration and delivery can be implemented incrementally, even with limited resources.

Myth #6: DevOps is only for startups or tech companies

While DevOps originated in the tech industry, it is not limited to startups or tech companies. DevOps practices can be adopted by organizations of any size and across various industries to improve software delivery and operational efficiency.

Myth #7: DevOps requires a complete overhaul of your workflow

DevOps is about continuous improvement, not starting from scratch. You can begin by focusing on small changes that promote collaboration and automation. Gradually, your development and operations processes will become more efficient and streamlined.

Myth #8: DevOps replaces traditional IT roles

DevOps does not replace traditional IT roles like developers, system administrators, or quality assurance professionals. Instead, it promotes cross-functional collaboration, shared responsibilities, and a culture of continuous learning and improvement.

Myth #9: DevOps is a one-time implementation

DevOps is a cultural shift, not a one-time fix. It requires ongoing commitment and adaptation. As your organization and technology landscape evolve, your DevOps practices will need to evolve as well.

Myth #10: DevOps is only for cloud-native or microservices architectures

DevOps practices can be applied to various types of software architectures, including monolithic, service-oriented, or cloud-native applications. The principles of collaboration, automation, and continuous improvement are relevant regardless of the underlying architecture.

By understanding and addressing these myths, organizations can better embrace DevOps as a cultural shift and a set of practices that foster collaboration, automation, and continuous improvement in software delivery and operations.