It may seem as if these days everybody is using Kubernetes. There’s a lot of hype. But the truth is, most companies are still using virtual machines and on-premises data centers, and that’s quite fine. Before you go and adopt Kubernetes, I want to share with you some misconceptions about Kubernetes and help you understand those problems won’t be magically solved by adopting it.

Will Kubernetes Reduce Your Costs?
One of the most popular reasons to adopt Kubernetes is to reduce costs. After all, if you can magically reschedule all your workloads in a much more efficient way, won’t your cloud bill suddenly go down?

First things first—you have to understand microservices are very inefficient by nature. Every time you hand off work across the (virtual) network, you pay for serialization and deserialization costs, memory copies (which traditionally both the kernel and the runtime have been working hard to avoid) and potentially various middlewares such as service-meshes and security software.

This pattern does not offer efficiency—it offers scalability, which is quite a different beast. And it’s obviously only relevant once you pass a certain scale. If you can run much of your workload on as many cores as fit inside a single computer, you are not at that scale yet!

The truth is that Kubernetes is quite good at packing lots and lots of light container workloads into fewer nodes. But, if your workload is containerized by nature, you are probably already using Kubernetes (or Docker Swarm, or Mesos, for that matter). On the other hand, if your workload is not heavily containerized, you have little to gain by moving to Kubernetes.

Will Kubernetes Be Transparent for Your Developers?
If your domain lies in site reliability engineering or DevOps, you might be thinking that adopting Kubernetes is in your realm and has little or nothing to do with your software engineering team. The truth is quite different. While running workloads on Kubernetes won’t require every single member of the team to understand the intricacies of Kubernetes ingresses, they are definitely going to have to know their way around.

Whether it’s spinning up a development environment (local or in the cloud), running basic `kubectl` commands on it or just being able to have a bird’s eye view of the architecture, your developers are going to be a part of this journey. You better have them onboard.

Will Kubernetes Help Break Down Your Monolith?
Many companies are struggling with an out-of-date monolith (often written in Java or C#) that they are looking to revolutionize. You might be one of them. The promise of migrating to a modern cloud-native technology seems enticing.

And yet, you have to realize most migration processes tend to be more of the “lift and shift” kind. Meaning, you are gonna be stuck with the same old monolith, except it’s gonna be running inside a much more complex and hard-to-access environment, instead of a plain old VM.

Breaking down a monolith into microservices should start with the Strangler methodology and you shouldn’t worry too much about the orchestration method when getting started. As things start to take shape, Kubernetes is definitely an awesome candidate.

Will Kubernetes Allow You to Move Faster?
So many tech-savvy companies out there are using Kubernetes. And they are definitely moving fast. Won’t we be moving faster as well by adopting Kubernetes?

Unfortunately, the answer to that question is almost certainly “no.” The most common reasons I have encountered that prevent teams from moving fast are:

Slow or inadequate tests.
Lack of automated build and deployment capabilities.
Poor understandability of the application.
Each of those problems is separate, and none of them are directly related to Kubernetes. Go ahead and invest in CI, CD and understandability. Containerization may definitely help. Kubernetes might come later, or it might not. But there are almost certainly higher-priority concerns to address if increasing velocity is your goal.

Is Kubernetes Better Than What You Currently Have?
If you have read this far, you are probably not satisfied with whatever orchestration solution you already have (or you just might be reading through before you roast me in the comments). And while Kubernetes is definitely awesome, it’s a complex system with many shortcomings. To be honest, it’s quite likely to cause as many problems as it’s going to solve for you.

If you are using a remote configuration tool such as Chef, Puppet or Ansible, that just might be what’s right for you. I would definitely recommend considering containers for most of those workloads, but that can still be carried out with those simple orchestration techniques and without a dedicated container orchestration platform.

If you are using virtual machines, or even physical machines, you might not understand some of the performance benefits you are getting out of those environments (which is why many tech-savvy companies still use them for high-performance workloads). If you move to more containerized, higher-abstraction workloads, you just might encounter performance degradations you are not expecting.

Summary
Whatever your complaints may be about your current architecture, Kubernetes is certainly not magic that will fix all or even most of your problems. My advice is to keep track of what you are happy about with your existing infrastructure and test to make sure what Kubernetes will not fail you in those areas or even make existing problems worse.

The truth is that most of us aren’t Google. We don’t always need the latest trend in software engineering, whether it’s distributed tracing or serverless or, yes, even Kubernetes. To be clear, we use all of these things to some extent at Rookout, so don’t misinterpret this article as a case against Kubernetes. Kubernetes is amazing. It just may not be for you, despite the hype.

Why DevOps Adoption Keeps Growing

Organizations of every size continue to pursue DevOps practices, driven by a common set of pressures: shrinking time-to-market windows, rising quality expectations, the need to cut operational costs, and the imperative to stay competitive in increasingly digital markets. The shift toward cloud-native infrastructure, agile frameworks, and digital business models has reinforced the urgency—but technology alone does not deliver the promised acceleration. The missing ingredient is almost always people: specifically, how well teams collaborate across traditional boundaries.

DevOps is not a tool or a product. It is a combination of cultural practices, organizational structures, and automation capabilities that must be assembled differently in every company. That is precisely why it defies a universal recipe.

Leadership Is the Most Critical Success Factor

Depending on company size and complexity, a meaningful DevOps transformation can take months—often years. From practical experience across many organizations, the single most important factor is engaged leadership. Without active sponsorship from senior leaders, silos persist, budgets stall, and cross-team initiatives lose momentum.

Effective leadership support enables organizations to:

• Break down entrenched organizational silos between development, operations, security, and business teams.
• Create flexible, dynamic workflows that span multiple teams simultaneously.
• Align software delivery speed with the ability to respond to changing customer demands.
• Sustain momentum through the inevitable resistance that accompanies cultural change.

Without this top-down commitment, even the most technically sophisticated DevOps toolchain will produce marginal results.

Implementing DevOps Is Unique to Every Company

There is no single DevOps playbook that transfers cleanly from one organization to another. Every company brings its own history, culture, risk tolerance, and way of working. Two organizations can adopt the same CI/CD toolchain and end up with completely different outcomes because the human and organizational contexts differ.

DevOps is best understood as an amalgamation of several distinct dimensions:

• Technology and automation: CI/CD pipelines, infrastructure-as-code, monitoring, and observability tooling.
• Lean process design: Reducing waste, minimizing batch sizes, and streamlining feedback loops.
• Cultural transformation: Building shared ownership, psychological safety, and a blameless post-incident culture.
• Organizational structure: Restructuring teams around products rather than functions, often using models like team topologies.

The weighting of each dimension varies by organization. A startup with 20 engineers needs a very different approach than a regulated financial institution with thousands of developers across multiple geographies. Copying another company’s implementation without adapting it to your own context is one of the most common reasons DevOps transformations stall.

The Challenge of Scaling Beyond the Pilot

The trajectory of DevOps adoption closely mirrors what the industry saw with agile: most organizations begin with a small, often hand-picked pilot team, demonstrate early wins, and then struggle to scale those results enterprise-wide. The pilot succeeds in part because it operates outside normal organizational constraints. Scaling reintroduces all of those constraints simultaneously.

Common barriers that emerge at the scaling stage include:

• Legacy systems and monolithic architectures that resist continuous delivery practices.
• Inconsistent tooling choices across teams that create integration overhead.
• Middle-management layers that have not been aligned to the new way of working.
• Lack of platform engineering capability to provide self-service infrastructure to product teams.
• Insufficient investment in developer enablement and training.

Automation tools bring organizations closer to continuous integration and continuous delivery, but the gap between a functional CI/CD pipeline and a truly continuous delivery culture is significant. Many teams achieve automated builds and tests while still releasing infrequently due to approval bottlenecks or release-night rituals that have not been re-examined.

Uneven Adoption Across Application Types

DevOps adoption is not uniform across application portfolios within the same organization. Mobile and greenfield applications typically see earlier and deeper adoption because they were often built without the legacy constraints that affect older systems. Core enterprise platforms, ERP systems, and mainframe workloads frequently lag behind, creating a two-speed IT environment that itself becomes a source of friction.

Organizations need strategies for both ends of this spectrum: accelerating delivery for modern workloads while carefully managing risk and compliance for legacy systems. Attempting to force a single delivery model across all application types rarely succeeds.

Measuring DevOps Success Meaningfully

A persistent challenge is defining what DevOps success actually looks like for a given organization. Deployment frequency and lead time for changes are useful technical indicators, but business leaders also need metrics that connect delivery performance to outcomes:

• Time to restore service after an incident, which reflects operational resilience.
• Change failure rate, which indicates delivery quality under speed.
• Product revenue or customer satisfaction tied to specific delivery improvements.
• Process efficiency gains measured as reduction in manual handoffs or approval cycle time.
• Innovation rate, such as the number of experiments or new features shipped per quarter.

Without connecting DevOps metrics to business outcomes, transformation programs risk being judged solely on tool adoption rather than value delivered. The metrics framework should be established early and revisited as the organization matures.

Learning from Others Without Copying Them

There is genuine value in studying how other organizations have navigated their DevOps journeys. Case studies, industry conferences, and community sharing surface patterns and anti-patterns that can accelerate your own thinking. However, the key discipline is translation: understanding why a practice worked in another context before deciding whether and how to adapt it to your own.

Two organizations using the same automation platform will have different team structures, different governance requirements, different release cadences, and different definitions of done. The tooling is the easiest part to replicate. The organizational learning embedded in how those tools are used, governed, and continuously improved is the harder part—and it cannot be copied directly.

Key Takeaways for DevOps Leaders

• Secure leadership commitment first. Technical initiatives without executive sponsorship will plateau quickly.
• Treat your DevOps adoption as a product. Define a roadmap, set measurable goals, and iterate based on feedback.
• Design for your context. Study best practices from peers, but adapt rather than copy.
• Plan explicitly for scaling. A pilot that works with one team will require deliberate investment in platform engineering and enablement to scale across the enterprise.
• Connect metrics to business outcomes. Deployment frequency matters, but it must ultimately tie back to customer value and business performance.
• Be patient. Fundamental shifts in how software is created, delivered, and maintained take years, not quarters. Sustained momentum matters more than rapid early wins.