How opinionated are we about deploying elasticache redis into kubernetes?

[rhoboat]

A customer was curious about how opinionated we are when deploying redis/elasticache into a kubernetes cluster in the Reference Architecture.

[rhoboat]

In general we prefer the AWS Managed datastore solutions than running it yourself on any platform.

The amount of niceties that AWS provides when it comes to managing Redis, like HA, backups, scale, auto patch updates, etc, can add up to be fairly time consuming if you want to manage redis yourself, even on Kubernetes. Not to mention the other overhead around cluster capacity management, e.g., your application competing for memory resources on the node with Redis. So unless you already have in-house experience doing this and there is a reason Elasticache doesn’t work for you (e.g., you need to be bleeding edge), we typically recommend trying Elasticache first.

credit to @yorinasub17

[rhoboat]

Using a managed service wherever possible is our recommendation for data stores. It costs money, but it allows you to offload a huge amount of work on to a dedicated team of experts, including how to handle persistent disks, backup for disaster recovery, point in time snapshots, replication, sharding (for some data stores), monitoring, alerting, connectivity, security, upgrades, scalability, high availability, and much more.

If there is absolutely no way to use a managed service—e.g., you have a compliance requirement and the available managed services don’t meet those requirements—then you’ll have to run the data store yourself. So far, we’ve used VMs for this, and avoided Docker, but that’s something we may want to revisit, at least with K8S. From what I’m seeing, there are some good, off-the-shelf Helm charts fro various data stores—sometimes, created/maintained by the maintainers of the data store itself—that solve a lot of the hard problems for you. But I’m not 100% on this, and we should probably take some time to dig deeper, and see how well it works.

credit to @brikis98