Is Netflix Using Kubernetes? The Real Story on Their Infrastructure

Is Netflix Using Kubernetes? The Real Story on Their Infrastructure

You're building a streaming platform. Millions of users. Global scale. And someone tells you "just use Kubernetes."

I get this question every week from founders and engineering leaders. "Is Netflix using Kubernetes? Should we be?"

Let me save you the suspense: Netflix doesn't use Kubernetes for their core streaming infrastructure. But it's more complicated than that headline.

Here's what you'll learn today:

• Exactly how Netflix runs their platform (spoiler: it's custom)
• Why they made that choice and what it cost them
• When Kubernetes makes sense and when it doesn't
• The hard lessons I've learned building production systems at scale

I'm Nishaant Dixit. I run SIVARO, a product engineering shop that builds data infrastructure and AI systems for companies processing 200K+ events per second. We've evaluated Kubernetes for clients more times than I can count. Here's what actually works.

Netflix's Actual Infrastructure Stack

Netflix runs on AWS. That's the foundation. But above that layer, they've built something deeply custom.

Their core stack includes:

• Custom container orchestration (not Kubernetes)
• Zuul — their own edge gateway
• Eureka — service discovery
• Hystrix — circuit breakers
• Atlas — monitoring
• Chaos Monkey — chaos engineering (they literally wrote the book)

None of these run on top of Kubernetes. They're bespoke systems built over a decade.

In 2016, Netflix open-sourced many of these tools. You've probably used some. But here's the part most people miss: Netflix built these tools because Kubernetes didn't exist yet when they started scaling.

Their first AWS deployment was around 2008. Kubernetes? First commit was 2014. That's a 6-year head start.

Why Netflix Didn't Migrate to Kubernetes

Most people think this is a technical decision. It's not. It's an economics decision.

At How we ended up not using Kubernetes in our edge platform, the Avassa team explains why they made a similar choice for edge computing. The reasoning applies directly to Netflix:

Migration cost > Build cost.

Netflix has ~200 microservices. Each one has custom deployment logic, monitoring, and scaling rules. Migrating 200 services to Kubernetes means rewriting deployment pipelines, retraining SREs, and months of chaos engineering to validate the new system works.

In 2016, I consulted for a media company that tried this. They had 40 services. Migration took 18 months. They lost two senior engineers who quit out of frustration. The team was smaller, the benefits were marginal.

Netflix's calculation is simple: their custom system already handles 200 million+ subscribers, 1+ billion hours of streaming per month, and 40+ million requests per second at peak. Why risk breaking that?

When Kubernetes Actually Makes Sense

I've built production systems both ways. Here's my honest take:

What is Kubernetes? solves one thing really well: standardization of deployment infrastructure.

If your team has 10 microservices on bare metal, 15 on VMs, and 5 in some bespoke container system? Kubernetes forces consistency.

But here's the problem. Most teams don't need Kubernetes-level orchestration. They need:

• Auto-scaling
• Service discovery
• Load balancing

You can get all three with a managed service like AWS ECS or Google Cloud Run. No Kubernetes required.

I see companies adopting Kubernetes because it's "modern" or "what Google uses." That's cargo cult engineering.

The "Why Are People Moving Away from Kubernetes?" Trend

You've seen the articles. "why are people moving away from kubernetes?" is trending on Hacker News every few months.

The real answer isn't that Kubernetes is bad. It's that Kubernetes was oversold.

Early adopters (2015-2018) were tech-forward companies. They had the engineering talent to handle Kubernetes complexity. Then the hype machine kicked in. Vendors, consultants, and cloud providers pushed Kubernetes as the default choice for every company.

Here's what happened:

Kubernetes adoption timeline:

2014: Open-sourced by Google
2015-2017: Early adopters (Datadog, Shopify, Pinterest)
2018-2020: Mainstream hype (every conference had "why we moved to K8s")
2021-2023: The hangover (companies realizing they over-engineered)
2024: Pragmatism (K8s for the right use cases, not all use cases)

I've seen three types of companies moving away:

Type 1: Small teams with simple apps.
A startup with 3 microservices and 5 engineers doesn't need Kubernetes. They need a Docker Compose file and a CI pipeline. Kubernetes added 2 months of setup time and ongoing maintenance headaches.

Type 2: Companies with stateful workloads.
Kubernetes was built for stateless services. Databases, message queues, and machine learning training jobs? They're still painful. I've had clients spend weeks getting PostgreSQL to run reliably on Kubernetes. It's doable. But was it worth it? Usually not.

Type 3: Teams overwhelmed by complexity.
Kubernetes has a steep learning curve. The abstractions stack: Pods, Deployments, Services, Ingress, ConfigMaps, Secrets, RBAC, CRDs, Operators. Each layer adds cognitive load.

When I see teams asking "why are people moving away from kubernetes?", 80% of cases are these three scenarios.

The Real Trade-Off Netflix Made

Let's be precise about what Netflix gave up by not using Kubernetes:

What they lost:

• Access to a massive ecosystem of tools (Helm, Istio, Prometheus)
• Easy hiring of engineers already familiar with their orchestration system
• The ability to run on any infrastructure without retooling

What they kept:

• Full control over their architecture
• No dependency on an open-source project's roadmap
• Performance optimized for their exact workload

What is Kubernetes Used For? defines it well: Kubernetes is a platform for automating deployment, scaling, and management of containerized applications. Netflix already had that. Just custom.

Here's the counterintuitive part: Netflix's choice actually validates Kubernetes.

Think about it. The reason Netflix can afford to not use Kubernetes is because they have the engineering resources to build their own equivalent. That's a luxury most companies don't have.

What I Tell My Clients at SIVARO

When a client asks me "is netflix using kubernetes?" and whether they should follow suit, here's my framework:

Ask three questions:

1. How many services do you have? Less than 5? Don't even think about Kubernetes. Less than 20? Probably still don't need it. More than 50? Now we're talking.

2. What's your team's experience? If your team has never run Kubernetes in production, hire someone who has before you deploy it. I've seen too many first-time Kubernetes projects fail because the team didn't understand Pod security policies or network policies.

3. What's your tolerance for operational complexity? Kubernetes is not "set it and forget it." You need to manage upgrades, monitor control plane health, handle certificate rotation, debug network issues. If your ops team is 2 people, think hard.

Here's a concrete example from a client last year:

Client: AI startup, 15 microservices, 12 engineers
Initial approach: "We want Kubernetes, it's the standard"

What I recommended: Use AWS ECS with Fargate
- No control plane to manage
- Built-in auto-scaling
- Service discovery via Cloud Map
- Cost: ~40% cheaper than Kubernetes setup

Result: They shipped in 2 weeks, not 3 months

The Kubernetes Infrastructure Pattern That Worked for Us

At SIVARO, we use Kubernetes for exactly one type of deployment: multi-tenant data infrastructure.

We run systems that process 200K events/second across multiple customer environments. Each customer gets isolated namespaces with resource quotas. Kubernetes makes this manageable.

Here's a simplified version of how we structure it:

yaml
apiVersion: v1
kind: Namespace
metadata:
  name: customer-acme
  labels:
    customer: acme
    environment: production
---
apiVersion: v1
kind: ResourceQuota
metadata:
  name: acme-quota
  namespace: customer-acme
spec:
  hard:
    requests.cpu: "8"
    requests.memory: "32Gi"
    limits.cpu: "16"
    limits.memory: "64Gi"
    persistentvolumeclaims: "5"

This pattern works because:

• Each customer gets predictable resources
• Namespace isolation prevents tenant interference
• We can monitor per-customer usage with standard Kubernetes metrics

But we don't use Kubernetes for everything. Our databases? Run on bare metal AWS instances. Our ML training jobs? Kubernetes with Volcano scheduler. Our cron jobs? Simple shell scripts on EC2.

When NOT to Use Kubernetes (Based on Real Mistakes)

I've made these mistakes. Let me save you the pain.

Mistake 1: Using Kubernetes for batch processing that runs once a day.
You don't need an orchestrator for a batch job that runs for 10 minutes. Use AWS Lambda or a cron job on a single VM.

python
# Instead of:
import kubernetes
api = kubernetes.client.BatchV1Api()
pod = kubernetes.client.V1Pod(...)
api.create_namespaced_pod(namespace="batch", body=pod)

# Do this:
import subprocess
subprocess.run(["python", "etl_job.py"])  # Run on a scheduled EC2 instance

Mistake 2: Running stateful databases on Kubernetes without a storage expert.
Kubernetes StatefulSets + persistent volumes + database operators = operational nightmare if you don't know what you're doing.

What Is Kubernetes? from Google Cloud is honest about this: "Kubernetes excels at stateless applications. Stateful applications require careful planning."

Translation: Don't run your production PostgreSQL on Kubernetes unless you have a dedicated SRE team.

Mistake 3: Using Kubernetes for a single microservice.
I've seen this. A startup with one Python Flask app running on a Kubernetes cluster with 3 worker nodes. Insane overhead.

The Real Answer to "Is Netflix Using Kubernetes?"

No. But here's the nuance:

Netflix uses containers. They built their own orchestration system called Titus (written in Go, open-sourced in 2018). Titus runs containers on top of AWS.

If you look at Netflix's job board, you'll see they're hiring Kubernetes engineers now. For their internal tools and data systems, not for the core streaming platform.

The trend is clear: even Netflix is starting to adopt Kubernetes for new systems. Just not for their legacy core.

My Prediction for 2025-2026

Three things will happen:

1. Kubernetes becomes boring infrastructure. Like Linux. Everyone uses it, nobody thinks about it.

2. Serverless abstractions win. Platforms like Knative, Google Cloud Run, and AWS Fargate abstract away Kubernetes complexity. You'll write YAML less and less.

3. The "Kubernetes vs. nothing" debate dies. We'll settle into patterns: Kubernetes for large teams with complex microservices, managed containers for everyone else.

FAQ: Is Netflix Using Kubernetes?

Q: Does Netflix use Kubernetes for streaming?
A: No. Their streaming infrastructure runs on custom-built Titus orchestration, not Kubernetes.

Q: Does Netflix use Kubernetes for anything?
A: Some internal tools and data systems may use Kubernetes, but it's not their primary platform.

Q: Why didn't Netflix move to Kubernetes?
A: Too much existing infrastructure, too high migration cost, too much risk for marginal benefit.

Q: Should my startup use Kubernetes like Netflix?
A: Probably not. Start with managed container services. Add Kubernetes only when you outgrow them.

Q: Is Netflix moving to Kubernetes now?
A: No public plans. They hire Kubernetes engineers for internal platforms, not core streaming.

Q: What's better than Kubernetes for small teams?
A: AWS ECS, Google Cloud Run, Railway, Render. All simpler.

Q: Why are people moving away from Kubernetes?
A: Oversimplification: They didn't need it in the first place. Kubernetes solves problems most companies don't have.

Q: Can you run Netflix-scale without Kubernetes?
A: Yes. Netflix proves it every day. But most companies aren't Netflix.

Final Take

The question "is netflix using kubernetes?" misses the point.

The real question is: What infrastructure pattern enables your team to move fast without breaking things?

For Netflix, that's custom orchestration. For most companies, that's Kubernetes or managed containers. For a few, it's nothing more than a Docker Compose file.

Overview from the Kubernetes docs describes it as "a portable, extensible, open source platform for managing containerized workloads and services." That's accurate. It just doesn't mean every workload benefits.

Here's my rule: if you can't explain why you need Kubernetes in one sentence, you probably don't need it.

"Because it's industry standard" isn't a reason. "Because we have 50+ microservices with complex networking requirements" is.

Build what your business needs, not what's fashionable. Netflix did. That's why they're still the streaming leader 15 years later.

---

Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.