Should I move Redis stateful services into Kubernetes or stay with cloud?

[Alexander_P]

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, but the cost of the external services is adding up fast.

[EthanHM]

Took a run at Redis inside the Kubernetes cluster using a StatefulSet and PVCs. The HA was doable, but the day to day ops were exhausting—disk provisioning quirks, node drains, backups, and DR testing ate weeks. We ended up leaning toward a managed service despite the higher cost.

[Samuel.T]

We moved to a managed Redis service. It cut ops toil a lot—no more PVC drama, easier failover, built in backups. The price on the bill climbed, but we saved time and reduced incident noise. We also looked at reserved capacity to soften the cost.

[Addison.W]

Are we sure Redis is the real bottleneck here? Maybe the bigger issue is release cadence and how we coordinate stateful workloads. It’s easy to blame the cache, but the organization friction might be the bigger thing.

[Dennis_P]

We ran a quick 2 week pilot with two Redis nodes in a separate namespace to compare. Latency was roughly the same, but failure recovery time dropped with the managed option. It’s not a slam dunk, and we’re still unsure, but it at least gave us data and a risk view.