While it's likely an easy process to drop in valkey, creating the new instances, migrating apps to those new instances, and making sure there's not some hidden regression (even though it's "drop in") all takes time.
At a minimum, 1 or 2 hours per app optimistically.
My company has hundreds of apps (hurray microservices). That's where "hundreds of hours" seems pretty reasonable to me.
We don't have a lot of redis use in the company, but if we did it'd have taken a bit of time to switch over.
Edit: Dead before I could respond but I figured it was worthwhile to respond.
> It's literally just redis with a different name, what is there to test?
I've seen this happen quite a bit in opensource where a "x just named y" also happens to include tiny changes that actually conflict with the way we use it. For example, maybe some api doesn't guarantee order but our app (in a silly manor) relied on the order anyways. A bug on us, for sure, but not something that would surface until an update of redis or this switch over.
It can also be the case that we were relying on an older version of redis, the switchover to valkey necessitates that we now bring in the new changes to redis that we may not have tested.
These things certainly are unlikely (which is why 1 or 2 hours as an estimate, it'd take more if these are more common problems). Yet, they do and have happened to me with other dependency updates.
At a minimum, simply making sure someone didn't fat finger the new valkey addresses or mess up the terraform for the deployment will take time to test and verify.
There's definitely pros and cons to this approach.
The pro being that every service is an island that can be independently updated and managed when needs be. Scaling is also somewhat nicer as you only need to scale the services under heavy load rather than larger services.
It also makes for better separation of systems. The foo system gets a foo database and when both are under load we only have to discuss increasing hardware for the foo system/database and not the everything database.
The cons are that it's more complex and consistency is nearly impossible (though we are mostly consistent). It also means that if we need a system wide replacement of a service like redis, you have to visit our 100+ services to see who depends on it. That rarely comes up as most companies don't do what redis did.
Indeed. Microservice zealot 'architects' love to ignore the work that has to into each microservice and the overhead of collaboration between services. They'll spend a couple of years pretending to work on that problem in any meaningful way, then move on to a different company to cause similar chaos
that’s a loaded statement without understanding the company.
Sometimes large companies acquire smaller companies and keep the lights on in the old system for a while. They may not even use a similar tech stack!
Sometimes they want to cleanly incorporate the acquired systems into the existing architecture but that might take years of development time.
Sometimes having a distributed system can be beneficial. Pros / cons.
and sometimes it’s just a big company with many people working in parallel, where it’s hard to deploy everything as a single web app in a single pipeline.
My understanding is that Valkey was forked directly from redis. So assuming you migrate at the forks point-in-time, then it literally is the same code.
Yes, but not the same infrastructure and configuration and documentation. Any reasonable operation will also do validation and assurance. That adds up if you have a sizable operation. "Hundreds of hours" is also not some enormous scale for operations that, say, have lots of employees, lots of data, and lots of instances.
The part you are thinking of is not the time consuming part.
At the very least you have to validate everything that touches redis, which means finding everything that touches redis. Internal tools and docs need to be updated.
And who knows if someone adopted post-fork features?
If this is a production system that supports the core business, hundreds of hours seems pretty reasonable. For a small operation that can afford to YOLO it, sure, it should be pretty easy.
The negative effect is that you have to bring the lawyers back in, and they tend to take an extremely conservative position on what might be litigated as offering “Redis-as-a-service”.
Many legal departments cannot afford nuance when a newsworthy license change occurs. The kneejerk reaction is to switch away to mitigate any business risk.
