So they're moving to a new "community based", "light governance" model. 
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.
The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense. No to PRs that didn't fit the vision. Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision.
Maybe I'm a pessimist, but I predict after a few years of this new model we'll see weird features, more stability issues, and performance regressions as more cooks enter the kitchen. Time will tell.
> The most important thing Antirez did, in my opinion, was to say "No" to things. No to new features that didn't make sense.
Redis has had tremendous mission creep over the years. It started of course mostly as a volatile cache but I've now seen it also used as a message bus (in three different ways: BLPOP, PUB/SUB and Streams), for service discovery and as a general purpose database - something that Redis Labs (in my opinion: wrongly) encourages.
Memcache existed in 2009 when Redis was first released, also as a volatile cache...and still is just a volatile cache. Memcache is what "saying no" looks like. Redis is what "saying yes" looks like - and there are a lot of gotchas.
Memcache is what saying no to changing the use-case looks like. Redis is what saying no to changing the architecture in order to implement features looks like.
Redis has stayed the same, architecturally, from the beginning: it’s a keyspace where the values are arbitrary in-memory objects owned by their keys, and where commands resolve to synchronous function-calls against the objects (or ref-cells) at those keys.
Anything that can be done without changing that architecture, is in-scope for Redis. (Though if a data structure doesn’t have wide use outside of a domain, it’s best left to a module.) Anything that cannot be done without changing the architecture, won’t be done.
Much of the “fun” I’ve personally had in watching Redis evolve, has been seeing how Antirez has managed to solve the puzzles of getting features that intuitively wouldn’t be a good fit for this architecture, to fit into it anyway: changing technologies that are implemented one way everywhere else, into something else for Redis, that still work, are still performant, and still solve isomorphic use-cases—if not with the same steps you’d use to solve them in other systems. (E.g. using Streams vs. using a regular MQ; using Redis Cluster vs. using regular RDBMS replication; etc.)
Memcache also is about saying no to changing the architecture. That chosen architecture is similar to Redis Cluster -which is a change of architecture Redis did undertake.
I personally have not enjoyed all the strange and wonderful ways people have found to use Redis. Most of them are pretty fragile and (most dangerously) they often put all Redis uses in the same instance...with eviction turned on.
This. To me, Redis was always about the rich set of operations you can atomically perform on data without going full ACID. It's very different from a pure cache (although it's probably a good choice if all you need is a cache).
Yeah. I do think that Redis has suffered from some mission creep, including a deprecated misadventure in to a mode where values could be stored on disk and only temporarily cached in memory.
Maybe that's what Cal and his colleagues were using it for at the time, but the claim that it started as a volatile cache is just not true. Interesting datastructures and the fork based persistence model were there from the start.
Lists, hashes, sets and such that you have available in your programming language, but available as a networked server so any language/app/process can access the same data using the same useful structures.
Strongly, strongly, disagree that Redis works well as a message bus.
Lots of reasons why but here is just one because I'm short on time: all of these (four) ways of doing a message bus with Redis offer either a work queue mode or publish/subscribe - but not both (perhaps excepting streams which I've forgotten some of the details of). I have yet to see many real world messaging scenarios where you don't end up using both.
A "proper" message bus needs to have topics, exchanges and queues - like Rabbit. 50% of that functionality is usually not 50% of the value but 10% or less (especially when you consider all the other things about Redis you need to think about - like how eviction is configured).
This is a bit typical of Redis: for any X, you can normally do X in Redis, but is it really a good idea to do X in Redis? IMO, usually no.
There's a wide field of messaging from distributed logs to queuing systems to event sourcing to complex service buses. Kafka, Pulsar, NATS, RabbitMQ, Tibco, NServiceBus, ActiveMQ, Solace, AMPS, and dozens more. What's "proper" depends on your needs.
Redis Streams actually does exactly what you describe and is basically a single-node fast Kafka replacement with multiple independent consumer groups, per-message acknowledgements, and queue semantics. We use it successfully in many high-load scenarios.
Name of the hash is a topic. Keys are nanosecond timestamps, values are the packets. You put in the data, you send a pub notify to the listener, listener goes and drains the queue. It acts as a direct exchange queue, recovers fine from a restart and it works wonderfully. For fanout, you can simply use pub sub. For topical, you can keep a list of direct exchange queue hashes. I haven't needed it.
> 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 based governance is a direct cause of that jwz's Cascade of Attention-Deficit problem one can find all over the open source world, especially Linux desktop related.
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 Cascade of Attention-Deficit issues, the project only goes in the direction the BDFL actually cares about.
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.
As usual, Fred Brook's Mythical Man-Month had some valuable insights on this back in 1975:
> To make a user-friendly system, the system must have conceptual integrity, which can only be achieved by separating architecture from implementation. A single chief architect (or a small number of architects), acting on the user's behalf, decides what goes in the system and what stays out. The architect or team of architects should develop an idea of what the system should do and make sure that this vision is understood by the rest of the team. A novel idea by someone may not be included if it does not fit seamlessly with the overall system design. In fact, to ensure a user-friendly system, a system may deliberately provide fewer features than it is capable of. The point being, if a system is too complicated to use, many features will go unused because no one has time to learn them.
* (This is quoted from the Wikipedia page as I don't have an online copy of MMM to hand).
The main differentiation (and risk) with BDFL projects is having (or not) a very competent (like one percenter) BDFL.
The structure of a committee project doesn't make it better or worse than BDFL. It just makes it more average. Any greatness present is toned down. And substandardness is brought up.
This also main reason the "led by greatness" BDFL projects are better than the committee run ones and the "led by less than great" BDFL projects "smoke out". The committee's tend towards the middle of the bell curve, BDFL's are all over the place.
this is IMHO no different the real world - a 'good' despot/monarch/etc can be a good leader, but this is highly dependent on the situation (read: leader), and leadership transition process is always a risky one. Democracies/Republics work well so long as the community has a generally shared vision, but can be hampered when there is too much dissent, but generally avoid the succession problem
Democracy is more of a principle (is just means that legitimacy of government comes from some aggregate choice of the governed), than a political system. Radically different political systems can be classified as democracies, all the way from direct vote (self-organized communes, also Switzerland) to complex federations with layers of indirect representation, such as the USA or the EU -- with a lot of other interesting alternatives such as sortition.
In a FOSS it is very easy to fork, so if the BDFL get's mad you can just say thanks and fork the project and continue. So that keeps BDFL in check.
IRL you own a plot of land, or a home. Or you have a small factory, and there are a lot of network dependencies, who does you sell the supplies, where you sell your products. It the local BDFL get's mad it is very difficult to move. (Specially if there are some cash flow controls were you can't get out with the money that you get selling your home or that you have saved.)
You can fork Linux if the dictator doesn’t suit you, but you can’t fork a nation. You also can’t switch to another nation that is more appealing, generally. Finally, Linux can’t imprison and torture you if you criticize it
Did FreeBSD not have the discussion about this years ago? Though they did not have a single person, but a 20 person core team, which were cut down to a 9 person core team that is voted for every 2 years.
There's no hard rule. The committers are expected to behave like a civilised human beings, ie talk to each other to reach consensus.
Let's say you have a fix for some driver used on ARM. You'll submit it via Phabricator to get ARM maintainers to review it. If they don't, because eg they don't have time, then you'll probably commit it anyway, but if someone points out you did something wrong, you'll be expected to fix it.
Underrated in the open source world — whilst at the same time, feels obvious in the writing world?
Imagine an author has gotten started writing volumes 1 and 2, and those volumes became popular — maybe the Harry Potter books as an example. Now, adding more authors with equal "story-line decision making power", or a committee, for volumes 3, 4, 5, is a weird idea, right.
> 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.
Linux is made because of many people all over the world, but it is successful because of the BDFL at the top. A consistent sense of mission absolutely benefits a project in the long term. There just isn't anyone that's going to get your idea better than you, when you're doing something that you know enough about to seriously get started on.
I think it's _just_ underrated; I think it's underrated in the business and government worlds too. A good leader should take different points of view into account, but should also be able to make a decision when needed.
I feel like Antirez has already done everything needed to ensure this doesn’t happen, by 1. building the module system into Redis, and then 2. working with companies like Redis Labs to establish that Redis is enhanced through these modules, and to ensure that modules offer everything required to enhance Redis in all the ways that matter.
In essence, Antirez has protected the core of Redis from needing to bloat, by making it possible for anyone who wants to build on top of Redis to literally do so—build on top, rather than inside. As such, I expect future PRs to Redis Core to look much like current PRs to Redis Core: just fixing bugs, adding stability, and resolving infrastructure-level interoperability concerns.
I 100% agree with you and I think it explains why most OSS UI projects are, well, terrible. Questionable features, inconsistent UX, millions of "options"... these are the hallmarks of a community model lacking strong leadership and a coherent vision.
As for the future of Redis I choose to be more optimistic. I think the Redis philosophy (thanks to Antirez) has become ingrained. The benefits of a minimal feature set are hopefully well-established.
In the very least I suspect this will last much longer than many expect before the bureaucrats take over.
Thats something a have regarding PR and code reviews: much frustration can be avoided by discussing what to do and how to do it before showing the work done (avoiding also infinite bikeshedding). Often code review talk about the strategy to do X and not the way to do X
And some people take the 'No' badly. It's frustrating having to explain that the code in a PR needs to be maintained forever, and it's the repo maintainer that will have to do it, not the contributor. A simple proposal upfront makes all the difference, and saves human effort and feelings.
>Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision.
Reminds me of Brian Goetz: "We have to say no to almost anything. If we didn't, things would pretty quickly degenerate to the point where the system collapses on its own weight (...) if we did this, which of these eighteen possible features might we foreclose on, and might we want to leave those possibilities open, at the cost of saying no to this thing here." (https://www.infoq.com/presentations/java-history-present-fut..., 24m+)
The one drawback of the BDFL model is that you need a person, and a very specific kind of person at that, which tends to be irreplaceable - to sustain it.
Redis has succeeded because of antirez. I really wish it can continue doing so for the long run without him. More than anything it reminds me of Steve Jobs' death (although gladly this is in much happier circumstances and I wish antirez many more decades of hacking). It's true that a decade later Apple is still doing great, but you just know things would have been different if he was still around.
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 (they can distribute it somewhat), and probably more reasonable and consistent conclusions.
I was active in a smaller open source project (http://www.openlierox.net) where it mostly was like that, i.e. we were 3 main developers, and all major design questions were discussed among us. But this example is probably not so representative, as there rarely were further contributions by other people. But anyway, I was very happy with this model, that there is not a single leader, but 3 people.
Thing is, with a consul or triumvirate system (you can’t have more than one “dictator”; all of these terms are from Ancient Rome anyway so let’s use them properly), if any disagreement arises between the 2 or 3 leaders, it will develop a new instability where there wasn’t one before. Or else, one of the 2-3 leaders will start to dominate the others. Even without turnover the dictator system is more stable. In fact the only benefit of a consul or triumvirate system might be the stability and continuity under turnover.
It's an interesting proposition. Whether it's Python, Redis, Laravel or Linux itself, a lot of software projects have been driven primarily by singular people and their decisions which shape the project over a period of time.
One example that was mentioned in this thread was the whole "master" thing going on.
Is Torvalds really going to get involved in that? Most likely no, and that's a decision he's free to make.
I worry in the future, after he's gone, depending on the model being used, we'll see more politics in software projects where Linux itself gets dragged into these things and doesn't have a single guy to say NO!
Or maybe you see an old white guy in charge of Linux and that can be considered a problem in itself, I'm sure many would love to see some change there and finally overrule Torvalds' decisions.
So in reality, we're seeing a slow shift away from BDFL type situations, and in the near term future, very few (what I consider influential) projects will remain with that setup.
Erhmmm, why does his age or colour matter in this context? Debate can happen about people and their leadership style, (I'm not a fan of Torvalds) but when the first criteria someone sees for criticizing another person is their age, colour, or race, that seems a bit shallow and biased.
Chain of events: I was tempted to try a respectful reply with substance, but then realized I wouldn't be allowed to discuss this here, due to moderator preference for "not talking politics".
I was then [regrettably] tempted to write something with a "mic drop" feel, just to express my disagreement in an acceptably pithy way.
And then it occurred to me that this whole sub-thread is Twitter-length comments. And I was about to add one more. And I realized that maybe the moderation of HN actually prevents us from going as deeply on this topic as we do on everything else, and so that moderator preference has essentially reproduced a pithy and unproductive Twitter dynamic for topics like this.
Pithy and shallow self-censored comments in reply to pithy self-censored comments.
EDIT: But also, moderation is really hard <3 Just wanted to try to put words to a small dynamic that's perhaps playing out here.
There was a huge thread yesterday on HN about this topic with many comments much longer than tweets. It is certainly a topic that can be discussed at length on HN. People were voted down and up, but no one was cancelled; we're all still here.
I'm not aware of any moderator preference against talking about this subject. Again: huge thread on it yesterday that persisted on the front page all day.
However, I don't think every single off-hand mention of race or gender needs to devolve into a subthread of 50 multi-paragraph comments. So I appreciate your decision to avoid it in this instance.
FWIW, I probably disagree with you, but I wish we could talk about these things in a civil way. I think the PC/cancel-culture prohibition about discussing this stuff is a real impediment toward progress. Further, I don't envy the moderators since it's hard to keep things civil--bad actors on both sides come out of the woodwork. Anyway, have an upvote as a small gesture of peace and kindness in a world where disagreements are supposed to make us bitter enemies.
Yeah, I was a moderator on one of the first university-run online forums, and it was so stressful and difficult...! All the first-year students just spoke off-the-cuff, but "monitoring" all that speech was SO challenging...!
thanks dang. Was thinking about y'all when I added that "<3" edit. I appreciate you.
> What made you think there was?
I recalled a post way back when trump was voted in, asking the community not to speak about politics. (I'm sure I'm misrecalling the specifics, but that's the fuzzy take-home that's nestled in my mind after all these years.)
"Racism" against white people in the US is completely devoid of systemic material consequence. Understanding definitions isn't about "mobs" or even ideology, it's about identifying what happens in incidents of racial bias and why those things happen.
Fair enough, but does that make it "good" or simply "less bad"? And if it's just "less bad", then why should we tolerate it when there's no dichotomy between "racism against whites" and "racism against minorities" (i.e., we can and should aim for a world with no racism at all)? Further still, once you've established a racial worldview with a racial hierarchy that puts whites on the bottom, you've established a framework that facilitates white supremacist arguments (both by making it easier to frame whites as victims of racism and by validating racial worldviews in general--a worldview that puts whites on the bottom is a lot closer to a worldview that puts whites on the top than an egalitarian worldview is to either). Liberalism (i.e., treating people as individuals instead of identical constituents of their race) has been the driving force behind the massive reduction of white supremacy and anti-minority racism; it's an enormous success and an important bulwark that protects minorities. Why should we erode this important bulwark by replacing it with a system that (1) perpetuates injustice against whites and (2) paves the way for white supremacy? Racism is lose-lose.
You’re begging me to go nutpicking with the phrase “precisely no one” but let’s grant that point. Many people have been outspoken about, in general, replacing white males in positions of power and importance with non-whites or non-males. The degree to which none of these people want to replace Linus probably has more to do with the degree to which Linus Torvalds is perceived to be in a position of power or importance.
Ok, 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 want you to know that your code is a real inspiration to me. Redis is a beautiful C artifact and an excellent reminder of how joyful it can be to create and read code.
Also, congratulations to moving off of Redis. In open source, there is a thing where people look at retiring from a project as some sort of failure of either the project or the maintainer, but I think the opposite is true.
We all have a finite amount of time on Earth, and everything has its natural beginning and end. Moving on to something else means creating the opportunity for yourself to find the next big project for you. And for the project itself, it means bringing in new eyes and perspectives.
I normally don't write about what I come across during my work, but in aggregate I can tell you that Redis, Linux and MySQL are the most common recurring elements across 150+ jobs looking at different companies, and using it rarely if ever leads to trouble.
So even if I don't use it myself directly quite a few of the companies we have invested in do, and an indirect 'thank you so much' is well deserved. I am very curious what it is that you will do next besides blogging. Linus had 'git' as his second major project, arguably it has had just as much effect on the world of free software as Linux did, you've definitely raised the bar for yourself :)
As someone who was in ops, I really disagree with MySQL in that category.
Saw it multiple times at multiple jobs just break on its own.
Most memorable one was a bug where certain pattern of data caused mysql think data is encrypted, crash and refused to start until data was restored from backup. It took quite time to fix it because it happened randomly and initially we assumed it was broken hardware.
@antirez Thanks man! Maximum respect for everything so far, and for your honesty over the years. I rarely login or post on HN but I have just for this post.
I've been using redis since I think 2.2 and have learned so much from your posts over the years! More than just about redis. Are you able to post links on your site to the videos you're making? I don't speak Italian but I'd love to learn from subtitles.
I'm really excited for you and look forward to whatever fun things you decide to do next!
Greets from NZ
> I write code in order to express myself, and I consider what I code an artifact, rather than just something useful to get things done. I would say that what I write is useful just as a side effect, but my first goal is to make something that is, in some way, beautiful. In essence, I would rather be remembered as a bad artist than a good programmer.
This entered my list of favorite quotes! For this, if not for your huge contribution to OSS, grazie!
Hey man, like a lot of people here, I wanna say "Thanks fort Redis, it's solved a bunch for problems for me at work", but also "Thanks for dump1090, I've had heaps of fun with that, and learned a lot from digging into your code there."
Best wishes for whatever it is you choose to do next.
You are a hero sir and thanks for all the effort that you have contributed for redis. Someday, I too hope to create a project that would touch at least a fraction of as many people as redis did. You are a big inspiration. All the best for whatever you want to do next.
Congratulations on completing such a very successful project!
Also, good decision, and happy to see that you now can finally take a real vacation if you want.
Also, it is good news for everyone, because it means you will be able to concentrate your energy on new creative pursuits if you want. Which, for example, leads to beneficial things like video tutorials, etc.
It feels like people may still kind of be on your back a little bit but this time they may be asking you what the next big project is. I hope you can shake them off and just follow your passion without needing to make a commitment to something new
(especially not anytime soon). This will be best for everyone in my opinion.
Thanks for putting so much effort into Redis! The software itself is awesome (I've been using it one way or another over the span of nearly a decade now), and in my opinion anyway you've handled the project and yourself in an exemplary way. You're the only programmer I can really say I think of as a personal hero. Best of luck in the future!
Your initial post about Redis is one of the first things I remember seeing when I started reading Hacker News. The great thing about Redis to me was that it was extremely clear what it did and what the use cases were, and I always appreciated how you talked about it in such a simple, practical way.
Thank you for Redis, and I hope you can relax and have some fun with whatever is next!
Thank you for all your work these years. Your blog was/is inspirational and I especially learnt a lot from your "writing an editor in 1000 lines" article, when every other example on the net used to use a library.
Thank you antirez! I've used your remote dictionary server from the earliest days and it has been a staple of my tool chest ever since. Three cheers and enjoy your time doing whatever it is you want to do!
Wow I guess I don't have nearly the knowledge of redis as many others here, but either way redis has been one of my favorite coding experiences! It works well, it's reliable, and it's very easy. Thanks so much for your efforts man!
@antirez - Thank you for Redis! It's been a joy to use across so many projects.
> However I never wanted to be a software maintainer.
And nothing say that you have to be. There's this perverted view that anytime someone creates a popular FOSS project, they need to dedicate every waking minute to maintaining it. That's neither economically feasible nor psychologically reasonable.
> Redis was the most stressful thing I did in my career, and probably also the most important. I don’t like much what the underground programming world became in recent years, but even if it was not an easy journey, I had the privilege to work and interact with many great individuals.
Yep it's the open source, and in general the "spontaneous" development world, that happens without big money, just for hacking. This "place" once was kinda free and not observed much. Now you can't say anything, if you don't respect a good practice (LOL) people yell at you on Twitter. Even saying that commenting is a good idea is a problem. Not cool.
Dude, the problem is just Twitter. Everybody shouts on Twitter, it's a system that encourages mob reactions. "Back in the day" people had to subscribe to a ML to yell at you, so fewer people did; and we all knew which lists were cesspools of trolls and flamers, making it easier to avoid the bulk of it. Twitter instead gives you the whole firehose, unfiltered and amplified. It's not a problem restricted to opensource or programmers, we see it everywhere at the moment.
> Even saying that commenting is a good idea is a problem.
I'm glad I'm not alone experiencing this.
One of the core open source projects I use has taken a no comments stance because "the code speaks for itself". It does if you're a core contributor, but if you dive in less frequently it takes a while to grok what's going on and re-build the mental model. Comments would reduce that.
Thanks for all you've done Salvatore, and for your blogging. Your enthusiasm puts the fun back into my programming!
> Yep it's the open source, and in general the "spontaneous" development world, that happens without big money, just for hacking. This "place" once was kinda free and not observed much.
Thanks for explaining.
> Now you can't say anything, if you don't respect a good practice (LOL) people yell at you on Twitter. Even saying that commenting is a good idea is a problem. Not cool.
Just because they're loud does not mean they're correct or that they're the majority. I can understand not wanting to deal with any of it though.
The larger than life you become in your space, they more your words, actions, and non-actions get parsed and twisted for political intent. It's either step away entirely or hide behind the mask of a pseudonymous alt.
> Just because they're loud does not mean they're correct or that they're majority.
They're not. They're the mediocre developers with nothing substantive to contribute. Think of your developer heroes. Almost none of them will ever engage in such nonsense. They're too busy building wonderful things to bother with petty nonsense that gets nothing done.
Lowering the barriers to open-source contribution has allowed in people who have absolutely no business being there. If you have standards, you get accused of gate-keeping.
Thanks for mentioning the T- website specifically, it takes a lot of courage to call it out directly these days, because all it takes is one of them with a lot of followers and then you get swamped with hate. It's fucking unreal man.
There's a ton of us down here programming and having fun, free of politics and bullshit. Look forward to seeing you (again).
I think some of these agile thought leaders have a bit to answer for here (but of course it's mainly up to the individual to be responsible for their own judgement - just because somebody else makes their money on marketing doesn't mean you are forced to buy the product)
The problem is that people don't recognize the efforts of the ones who do it. Antirez did it for years. Do people expect someone to have the same very high-profile job with constant overtime and the same project for their entire lives? His efforts to stay on that project were heroic.
There are lots of other people who want to maintain it. Let them, and if they screw it up that is not his fault. He finished his project. Give him a break.
I think everybody wants it on their resume, but the practical day to day work tends to be more filtering poorly written GitHub issues than writing any interesting code. For a job that doesn't pay much (often at all), that's not something I would want to spend my time doing.
Agree. I’d like to thank conjectures, brodouevencode, Bjartr,
kungtotte, m0xte, fidelramos, chii and pokot0 for their contributions, but gently suggest none of the jokes were really that funny.
Said well: https://news.ycombinator.com/item?id=7609289
Since we have a norm that those who post unfunny jokes shouldn't complain they are downvoted, we should also have a norm that those who don't like jokes should just downvote without comment. Of course, I'm violating the obvious meta-norm...
That's fine, and there are probably some would-be HN comedians who haven't heard the news about this yet, but meta-discussion is really boring. This is the last thing I'll post in this thread, and I won't be surprised if it gets downvoted to oblivion.
I say this frequently both online and when discussing system design with newer devs, but will repeat here: of all the production issues I've debugged, the culprit has has never been redis. In fact, redis has been a critical piece of achieving cost-effective scaling. It is one of only two pieces of software (along with postgres) that I blindly recommend without any caveats. From following along here and on your blog about how you approach things and think about the software, I think its clear that you and your vision for the project are a large factor of why it has been so reliable.
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 story is not nearly as nice as the quick start.
It's definitely worth recommending... with caveats.
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.
> When did you start sharding? How many GB memory did your previously single-machine-Redis-instance use . . .
Sharding is always something you do on day 1 for every project, because a single-machine-Redis-instance is a SPOF and won't pass even the most basic operational readiness checklist.
> (capacity planning questions)
The answers to these questions don't generalize, they depend on your workload. You should figure out some approximation of your data types and request profiles, and use those to get a rough understanding of what one Redis server on a given machine class is capable of delivering. This usually means applying a few different classes of read/write loads against a small cluster at steadily increasing RPS, and documenting how CPU, memory, and latency characteristics change. From these numbers it's possible to derive a capacity plan.
The last time I did this, for my workload and machine class, one Redis instance (one core) delivered 250-500k RPS, invariant to memory used. We'd use the conservative end of that range, combined with the RPS and data set growth rates we predicted, to provision for ~12 months of growth. Operationally, we would deploy (cores-1) or (cores-2) instances per host (I forget exactly) on 32- and 64-core machines. I think they had like 64-128G of RAM, and we made sure to leave enough memory overhead so the AOF or whatever persistence option wouldn't lock up the box. But even the choices of what class of machines to use is a function of your use case, if you have really large dataset with relatively non-costly (CPU) operations, you want a totally different machine profile than a relatively small dataset with complex operations. Availability SLOs also factor in.
All of this is basic operational stuff, and with Redis the answers are pretty well-understood and highly predictable. Completely opposite to systems like Elasticsearch, which was a total nightmare to predict, provision for, and operate.
> "Sharding is always something you do on day 1 for every project ... SPOF ..."
Cannot agree with that. If one does that or not, would depend on things like Service Level Agreements (SLA) — and one can have a pretty high SLA uptime %, without sharding, e.g. if there's an underlying pretty stable hosting provider that live migrates if there's a hardware failure.
Thanks for writing about the last time you used Redis. Interesting to hear that, in that case, the machines had sth like 64 – 128 RAM, and 250k – 500k RPS. Yes I agree that I'd need to benchmark and think about what type of machine(s) to use (some time later — a bit too early for that now). Sounds as if you are / were a pretty large company / project, needing that much memory and machines :- )
> Cannot agree with that. If one does that or not, would depend on things like Service Level Agreements (SLA) — and one can have a pretty high SLA uptime %, without sharding, e.g. if there's an underlying pretty stable hosting provider that live migrates if there's a hardware failure.
Sorry, no. A single instance is never acceptable from any risk perspective, no matter what guarantees the hosting provider claims.
Extremely hard to scale in what sense? A single redis server running on fairly commodity hardware can serve some pretty intense loads (10s of thousands of ops/sec). Once "scale" bigger than that is an issue, companies should already have in place the development staff that will ensure scaling up is done in a sane way, i.e., that have enough sense and/or experience to choose the correct tools for the job.
Redis is one such tool--its clustering "story" may not be ideal but even a small, minimal cluster will be more than sufficient for any use-case that a distributed memory cache is fit for at a scale that will cover 99% of business' needs.
> Extremely hard to scale in what sense? A single redis server running on fairly commodity hardware can serve some pretty intense loads (10s of thousands of ops/sec).
~90k/sec on a single core of L5520. Scaling Redis is a premature optimization for 99.99% of the use cases. While it may be sexy to talk about millions of ops per second that one's project does in reality the number of projects that have that as a requirement is probably barely in triple digits globally.
I think you are using it wrong. It is not meant to be run in a K8S cluster woth dynamic IPs in multiple instances. You are supposed to deploy VM mesh of fixed IPs as database store. Moreover, it is design-dependent. You can live with just multiple master-slave pairs and have your data implicitly sharded by something, e.g. by user country or continent. It's sad that some people still think "perfect db" exists: partition-tolerant, high-available, durable, horizontal-scalable, low-latency, acid-compiant, open-source database dosn't exist and never will (see the CAP theorem, see the broken guarantees found by Jepsen). Live with it and design your architecture appropriately.
I don’t think most people need a fully partition tolerant solution; even at very high scale and with high SLAs quorum based solutions are used successfully. If you remove strict partition tolerance from your above list there do exist such databases. And I’d argue it’s much easier to develop against such a database and you’re more likely to actually preserve its guarantees in your application than running an ad-hoc cluster of Redis instances with a home-spun clustering scheme where your application logic is heavily implicated in maintaining consistency.
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.
It's been a word for a long time ... we used that when we were kids (at least in earshot of our parents). Searching for "dang" in Algolia results in (by a quick count) more than 80% of the results being for @dang (the person/handle) rather than the perjorative use.
Personally I think it's mainly the result of having people constantly being hypercritical of your code.
And I think he's proven himself to be a superior programmer. In that in almost every category of engineering skill and knowledge, he is better than 90% of the people criticizing him. If he didn't start out that way, over the years his knowledge and skills grew to make it so.
But also maybe it reflects a bit that there is always some new "best practice" or something that some months ago no one heard about, but now many people are unfortunately using the adoption of as a proxy for programming skill because they are unwilling or unable to actually judge something or someone on actual merit.
I think he's done a great job with Redis. It goes to show sometimes that you need to let go of the thing you created for the good of the community. If I were in his position, I would have made the same move
My thought here. I'm not exactly a disinterested party because I built my own key value store company (possibly the wrong way but that's a different story).
I have a huge respect for Redis, and Antirez, but I have to say my respect doesn't include RedisLabs. They're the ones who started a commercial endevour to capitalize on Redis initially without Antirez, and then later offered him a position. They're the ones that Kyle@Jepsen says is making claims about ACID, not Antirez. I always heard that Clustering was a feature Antirez was very reluctant about.
I hope Redis is, fundamentally, taken away from RedisLabs.
Antirez, you say you want to express through code and open source, and I can't square that with your association with RedisLabs. You've been taking their money for quite a few years now to allow them to put up a billboard saying "the home of redis".
I'm going to stop right there. I've cut my own path through the wild jungle that's Open Source, and it's not yours, and I respect the years you put in to make the product with your vision. I'm sure there are some other first coders of foundational databases on this list, but it's a small club.
As an employee of RedisLabs, I don't think you are free to say what you'd like to say, I hope you follow whatever path does allow you to freely express in the future.
I just want to say thank you to antirez for Redis, for how simple, fast, and rock solid it remains to this day. Redis is one of those things that allows you to tilt your head a little on a problem--thinking of solutions in terms of set operations and lookups. A lot of people use it understandably for a cache but it is so much more than that...for me it's introduced an entirely new way of composing solutions to problems. Cheers for all you've done--you've shown at least one programmer that there is still a place for small, elegant design that will stand the test of time.
Actually the web site uses Redis as the only store. And Redis is using 0.1% of CPU. The problem is that Ruby sucks at doing anything scalable. It's just a Ruby/Sinatra app. If you do that in PHP, it will work out of the box with many concurrent accesses. With Ruby not the case. There are ways to deploy it better, but it should be fast as default, which is not the case.
While a very different circumstance, the pull between "I write code in order to express myself" and being an "artist" vs. "useful" and the drudgery of maintenance reminds me of famous rubyist _why and why he stopped doing stuff in the community.
Underground as in programming for fun or as art, because you enjoy it as a hobby/subculture. Opposed to the "above ground" programming world of programming for other people (possibly also for money, but OSS is often just for recognition) where people have demands about unimportant features, terminology, coding styles, codes of conduct, etc. Sometimes they get quite aggressive about their demands, too.
The underground in underground programming refers to maintaining low visibility, as to present low target silhouette. Additional benefit is not attracting too many participants that are in it for the clout, rather than for solving problems & good engineering.
Open Source is no longer sufficient for software freedom; the current 'battlefield' is maintaining security from activist pressure or gradual take-over.
I created the Occupy Wall Street website nine years ago. Believe me when I say the lengths people will go, to try and control community projects, is downright traumatizing. I never could have imagined that same kind of nastiness would impact open source.
If you don't feel comfortable engaging with the new toxic culture, you can use my underground liferaft. My liferaft isn't an operating system, but rather an attempt to help us not depend on them as much. I have no idea who's controlling GNU/Linux these days and Occupy was enough drama for one lifetime. My code has the same focus on clarity that Antirez put into his Redis codebase. My liferaft also empowers you to build and distribute tiny native portable programs (like Kilo!) using hermetically sealed tools. See https://github.com/jart/cosmopolitan
This implies that a lot of the politicization of open source projects has to do with outsiders making power plays (for in group status or just because narcissism). I think this is part of it, for sure. I also think it can also manifest when parts of the community get trapped in a purity spiral, which is somewhat related but comes from within rather than without.
Advice? I don't know. Stay underground and ignore the mobs, they will get bored and move on if you ignore them.
Ironically, I think lowering the barriers for involvement in open source has let in a mass of people who have no fucking business being there.
Replying to myself to highlight antirez's own comment upthread:
>Yep it's the open source, and in general the "spontaneous" development world, that happens without big money, just for hacking. This "place" once was kinda free and not observed much. Now you can't say anything, if you don't respect a good practice (LOL) people yell at you on Twitter. Even saying that commenting is a good idea is a problem. Not cool.
> In eleven years I hope I was able to provide a point of view that certain persons understood, about an alternative way to write software. I hope that such point of view will be taken into consideration in the evolution of Redis.
To me this epitomises what Bill Gates meant when he said "Most people overestimate what they can do in one year and underestimate what they can do in ten years.".
I just wish I had something to show for my last decade that had as much impact as Redis!
As a redis user for more than 8 years, i just want to say thank you. I had embedded redis 2.8 on small IoT system with 200mhz/64Mb of ram to huge cluster as a message bus (redis-as-kafka pattern).
Want a shared memory with a type system? Use redis. Want a queue? Use redis. Want something easy to mock, with an API in all major ecosystems? Use redis.
It's long past due that we should move to software which isn't maintained - because there's nothing to do. Adding features could be done either by writing a new one - because the requests don't really fit the meaning of old one, the creators saw that and rejected; fixing bugs - yes, fixing bugs may remain, but are there many bugs in, say, TEX code?
We don't yet know how to write a completed software well - the one which isn't updated on Github for years yet nobody calls it stale or outdated.
I think video games fit in the area of 'completed software'. Most video games today rarely see updates a few years after they're released. And older video games were on read only mediums, so you would hope whatever you release is very stable and feature complete.
@antirez - thank you so much for your work, and for your patience with dealing with us all over the years. I have benefited greatly from your willingness to share your engineering skills, and you are one of the most respected programmers in my list of people to follow online.
So, onwards and upwards to new things. Perhaps now you have time for my favourite of your projects, LOAD81? :)
Thank you! In building Redis you’ve contributed some wonderful software to the world. In addition, I’ve always found your blogs to be interesting reads. I’ve also learned by the examples you set both from a coding perspective (reading your wcode), and engineering perspective. Thank you again, looking forward to whatever is next!
I am struck by how beautifully expressed this letter is. @antirez, thank you so much.
It's really great to see when someone who is totally honest with themselves and what sparks joy in their life/career, and is also respectful to all the people who depend on the work/artifact. So much respect.
When some software I was responsible for started melting down under a load 10x bigger than it could handle, I was able to fix it by doing an emergency rewrite of the data storage part using Redis with Lua scripting. This was back when that feature was still experimental, so I was using unstable tarballs in production -- and yet everything worked perfectly! The emergency was fixed in a single long day. It was a miracle.
Thanks for all the great things you've done with Redis! "Beautiful" describes it well.
Thank you, @antirez! I have a live stock market site that heavily relies on redis for streaming data, tracking leaderboards, and message passing. It would have been difficult without Redis. You really affected my life. Big hug to you, Salvatore! I hope you find your next inspiration, and bless us with your next masterpiece. :)
I'm grateful to Antirez for inventing Redis in the first place and putting in all the great work he's done since. However I'm worried about the implications of this change for the continued existence of Redis as open-source in the public-goods sense.
What does it mean that Yossi and Oran are taking over as maintainers - are they doing so in their personal capacity or as employees of Redis Labs ?
How are potential conflicts between the business interests of Redis Labs and the interests of the community to be identified and resolved ?
Who will own the copyright over the newly submitted code and are there any safeguards against future versions of Redis being released under licenses more restrictive than the current one ?
Thank you for writing this antirez, I think I'll remember it as a statement of some principles that I like to think I aspire to also: like many people here I guess, I would describe myself as someone who loves writing software, and in my own small way I've also tried to avoid being dragged into team/project management because that is not what I seek out of a lifetime involved with code. And, yes, I do like to think of writing code as a creative activity / form of expression. I also need to study your C code more! Perhaps I'll look at the early redis commits.
Congrats and thank you, Salvatore (@antirez), for producing such a beautiful, powerful, useful and important piece of software... and for articulating and demonstrating such passionate commitment to a personal vision that is so very rare, valuable, and inspiring... and for your responsible stewardship of its maintainance even when it came at the cost of your personal preferences. You're a class act, and I have no doubt you'll be successful with whatever comes next. Hats off for doing it right! Bravo!
Antirez thanks for the Redis.. even though I have not used redis in real time.. some what I got attracted into redis and when I have attended redis conference in Bangalore got to know much about redis and got a chance to see and listen your talk.. all the best for your future hopefully you will come back with new thing where I can learn more from you.. partially missing you from github mail nofications which I didn't thought....all the best
There are only a few pieces of infrastructure that I haven't found myself cursing at, redis and haproxy are among them. They both are the closest to set-it-and-forget-it I have worked with. No doubt the leadership of Antirez played some part in that. I hope the project can continue to reach the bar he set.
Thanks for Redis! I never built anything that successful but can relate that being a software maintainer is really hard and many great software developers who build great software, have a hard time with it and not finding it very enjoyable.
Building a thing is fun, maintain not. Especially if it is a tool, a tool for a specific problem and it solved it. But people want more and more functionality. Then you work on things you never wanted to do.
I think you've been a role model in how to build and maintain a popular software project while keeping the spirit of FOSS and promoting a positive community around it. I look forward to seeing what you get up to next.
Antirez, I look forward to seeing what you do next. I especially look forward to there being more software in the world that’s architected with your unique mindset—whether it be “useful” software or not. :)
Yeah, I don’t see how maintaining a project like that has any long-term appeal. You’re not the upstart anymore, you’re the government. You stand to lose more by mistakes that affect reliability than you stand to gain by changing or adding things.
I’m at a similar point in my life, though of course I’m much less influential than him. I’m getting to the end of the most stressful and most important part of my career, with no desire to do something similar again, without a clear idea of what’s next.
Redis has given me more than the occasional headache when it comes to its lax security defaults and how since it's going to be local then why bother changing them? But there's no denying that when it works, it works damnably well. So for that, I give you my thanks and good luck in whatever endeavors you find yourself involved in!