Thanks for all!
Good luck in future
The End of the Redis Adventure
201–210 of 308 posts
Re: The End of the Redis Adventure
#202Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
Thank you so much for all that you have done. Redis is a fantastic piece of work. It is everything software is supposed to be: it's simple and it just works :)
Good luck exploring your other options
Re: The End of the Redis Adventure
#203So they're moving to a new "community based", "light governance" model. [1] There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. Redis is unique in my experience in that it works the way you'd expect - it doesn't cause outages, it is fast, and it has a vanishingly small number of gotchas. The feature set is well curated and for the most part fits together cohesively. T…
Instead of a single BDFL, you could also have a board of e.g. 3 BDFLs. Those 3 people would have the final word, but they rank equal, and have to come to a common conclusion, e.g. by discussing internally. That only works if the board is not too big, and the people are somewhat compatible to each other. But in that case, I think it works much better, because there is less pressure on a single person, also less work (…
I think the mixed historical record of consul republics might be relevant to why a single leader is often a better idea than 2-3.
Re: The End of the Redis Adventure
#204Earlier quoted context omitted.
Redis is simple. Good. Has a nice api. Has good libraries. Single threadsed. Extremely hard to scale. Impossibly difficult to cluster in containers because it uses hard coded ips to address nodes. Performs poorly with large payloads. Doesn't run on windows properly. Is extremely expensive as a hosted service (orders of magnitude in some cases, eg. azure). You'll love it until you don't. The scaling and clustering sto…
Redis is extremely simple to scale. Treat each instance in a cluster as wholly independent from other instances, and build a thin layer on top to implement whatever sharding and availability requirements your use case requires. I've done it many times and it's always been simple and worked brilliantly. Redis's predictability makes it a joy to operate.
We've done just that. Some folks at work wanted sentinel in front as a cluster management layer, but our particular use case did not work well there. Instead, we have some "logical clusters" of 3 nodes that we replicate reads and writes to, sharded to (currently) six clusters. Some logic around quorum for ensuring writes make it to at least 2/3 nodes in a given cluster, with some optimizations for reads sometimes only needing 1 node to respond. We had to do a bunch of tweaking around state and memory management, and all the details were in the docs, which was great. It does exactly what we need it to do, but it is more expensive to run, and we've not figured out a way to do this right in k8s. We don't care for the cost model going forward for when we want this model serving 10x traffic (which is not pie in the sky, it is known actual volume this solution would need to support). For 10x traffic, we'd be looking at 10x node count. At nearly 200 redis nodes, that can get expensive, esp. if we want to move to a managed solution. Anyway, not sure where I was going with this. Yes, redis can scale. Yes it can stay performant. At some point, it just becomes a lot to manage though and costs can add up. We are going to be designing a new solution to keep costs low and performance high.
Re: The End of the Redis Adventure
#205HN hugged to death. Here's the snapshot on archive: https://web.archive.org/web/20200630130517/http://antirez.co...
I actually wonder how many request/s one gets from being on the top of HN.
My "Show HN" post was in the bottom half of the HN home page for less than an hour. Traffic to the site was roughly 100 times greater than its current levels (by bandwidth):
https://www.linkedin.com/posts/rik-roots-50349611_in-case-an...
Re: The End of the Redis Adventure
#206Earlier quoted context omitted.
Redis is simple. Good. Has a nice api. Has good libraries. Single threadsed. Extremely hard to scale. Impossibly difficult to cluster in containers because it uses hard coded ips to address nodes. Performs poorly with large payloads. Doesn't run on windows properly. Is extremely expensive as a hosted service (orders of magnitude in some cases, eg. azure). You'll love it until you don't. The scaling and clustering sto…
I only used it once, but it's clustering story was bad, and I never really understood the niche it filled between Memcache and databases.
better memory model over Memcache. If one of our memcached servers dies, that data is gone. Redis can write to disk, optionally. We mostly use redis and memcache as a cache to save load from the db. Even with dozens and dozens of dedicated read hosts, we can knock over our dbs if we are not caching data.
Re: The End of the Redis Adventure
#207As someone who loves programming and dreads most of project management (and being anywhere close to a limelight nowadays), I understand.
Redis is an awesome piece of software and who knows, maybe this'll free antirez to create another awesome tool.
Re: The End of the Redis Adventure
#208Earlier quoted context omitted.
> There are plenty of problems with BDFL-style projects, but I think there are a lot of advantages too. BDFL governance is extremely underrated in the opensource world. People attribute the success of the Linux kernel to its open contribution style, but I will argue that Linux is successful because there's a dictator at the top that enforces a direction, a long term goal, and most importantly, says NO. Community base…
Does FreeBSD have a BDFL? We don't have enough data points to determine if what you are saying is correct. I have also seen lots of BDFL projects smoke out. Is the lesson that actual dictatorships only survive long term if 1) the dictator is a nice person and 2) they eventually get managed by an open democratic process? I think you are actually describing the two clocks problem. Lots of BDFL projects have their own C…
>Does FreeBSD have a BDFL?
No, but it doesn't have as much success as Linux either
Re: The End of the Redis Adventure
#209Ok, so many thank you here, thanks! It's very nice to read the comments here. But I hope to interact more on HN, since basically the idea is to write more blog posts, write more OSS software too. Just totally random :D I'll just do whatever every morning I want to do for a long time. Then maybe I'll find a new long term interest.
I've always admired your work, and read your source code to learn how to structure a great project.
Looking forward to reading whatever you do next!
Re: The End of the Redis Adventure
#210Earlier quoted context omitted.
A (software) dictator is not necessarily good. But let me double down and say that a community cannot create a product as good as a single head at the top can do, for the single reason that people care only about their own garden, and integration needs someone to oversee and be responsible for all parts. There is no Steve Jobs in a democratic committee.
Cannot seems rather strong. I haven't been paying very much attention, but I was under the impression that Postgres doesn't have a dictator?
Or Rust, which - whatever you might think of it - does not feel very designed-by-committee.