Should I move Redis to Kubernetes or keep it as a managed service?

[Nora3]

I'm trying to decide if we should move our stateful services, like our Redis cache, into our main Kubernetes cluster or keep them as separate managed cloud services. I'm worried about the operational complexity of managing persistent volumes and high availability ourselves, versus the cost and network latency of external services.

[JustinFH]

Been there. We started by running a stateful cache as part of our cluster, tied to persistent volumes, and wrestled with upgrades and backups for months. When we tested a managed option, it felt calmer—less YAML gymnastics, automatic backups, and simpler failover tests. We migrated a small hot-key set first, then rolled out regionally. Latency stayed fine in the same region, but cross region hops did bite a few services.

[Kevin14]

Operational toil is the real lever here. Self hosting means persistent volumes, snapshot backups, disaster recovery playbooks, upgrades, and scaling churn. We ran a controlled outage drill and measured RTOs that were slower than ideal. The managed path shaved off most of that toil, but added ongoing costs and some egress/latency in our architecture.

[Natalie_J]

I keep thinking maybe the problem isn't the cache layer at all. We added a tiny app-side cache for hot keys, and tuned eviction. The bottleneck shifted and a bunch of services just moved slower under load. It made the choice murkier because the cache still mattered even though we tried to reduce dependency on it.

[JasonAP]

Before we lock in, I keep wondering if latency and cost are the real blockers, or if the network layout between clusters is the bigger issue. We did a quick cross region ping test and it felt fragile under bursty traffic. Do you have a rough RPO in mind for cross‑region replication, or is latency the main driver? Not sure this is the real problem, but it's what we measured.