My (minimal) criteria is it has to be packaged in Debian.
A couple years ago I considered both MongoDB and CouchDB immature for that reason. The recent confusion of CouchDB/Couchbase etc. shows that was a reasonable view.
I'm not sure when they started, but 10gen now packages and distributes their own MongoDB Debian and Redhat packages. It seems like the right move, so that they're not beholden to the update schedule of the distros.
Yes!!!
The development cycle of software like MongoDB, RabbitMQ and so on, is much faster than that of Debian or any other Linux distro. The Debian package is fine for dabbling or low volume use, but for any serious app, you MUST go direct to the developers and use their latest stable release. That is what they support best on their mailing lists, and that is where most bugs are already fixed.
A lot of software development teams are releasing their own RPM and .DEB Linux binary packages for just that reason, to encourage people to use up to date packages instead of the stale OS distro packages.
In a way, it's rather like security updates. Who would refuse to install security updates because it's not part of the Ubuntu 10.4 LTS release? Almost nobody even thinks of doing that. So why would you use old obsolete releases of mission critical software?
> why would you use old obsolete releases of mission critical software?
"If it ain't broke, don't fix it"
Because it's mission critical, and you can't afford for it to break. Once you hit a certain complexity, upgrades almost always break something:
APIs change. Undefined behavior changes. New bugs are introduced. A feature critical to your app starts performing worse. The above changes break something else you depend on (libraries, proxies, etc.)
Upgrading to a significantly changed version of a mission-critical app/library/language is a lot of work, and is sometimes impossible: many projects couldn't be reasonably ported to Python 3 if they wanted to; a lot of important libraries don't work on Python 3.
This is exactly why bug and security fixes are often backported into old versions. Python 2.5 is still receiving security patches. Apache 1.3 was maintained for years after 2.0 was considered stable.
Yes, especially with a database you can't just pull in new updates and expect them to work. It involves reading the release notes and doing a lot of testing. (much of it is automated)
Equally APIs are backwards compatible, behaviour is defined, bugs are fixed, performance is improved and software becomes more compatible with other software.
I have a feeling that Javascript based NoSQL backed web development is going to be just fine in two years. Quite possibly the standard stack for a large percentage of projects.
I have the opposite feeling. I understand very well the reasons some are pushed away from relational data and data normalization, and set theory formalism. Some are need for change. Some are fears of over engineering. Some are because the trend is to Twitter-like blobs. A big reason is because doing things right is a pain in the...
And come the only valid reason, from my POV: We have to denormalize and avoid using the powers of relational data sometime because we do not know how to store (read and write) conveniently huge amounts of relational data; yet. Notice the "yet"? Well, I think it is a technical problem, that may not be so far to find its solution.
One example of a solution showing its nose recently: "Google plus with your world". It do strike me that the fact that any query I make to the closest Google server respond /instantly/ to any random word with a join on a very possibly monstruous matrix of all the likes of all my circled users.
I don't know how they do store this, where and how they denormalize, but in any case it seems to me to be just "relational data as usual".
So in two years, if there is a "bigreldata" software allowing to have a Postgres sitting happily on 1000 T of relational data with instant reads and writes, I would certainly use that with a layer of python glue on the server feeding a slim client than a blob datastore with NoSQL handcuffs and a fat client with 20 libs of third party Javascript code.
I may be wrong, however, and would love more insights on this.
Google is not using a RDBMS to get Google Plus content on SERPs. What makes you think they are? It works just like the rest of Google on their leading edge kit: bigtable, GFS, etc. Amazon is able to personalize their site for each customer quite a bit more than Google is and relies on similarly horizontally scalable architecture.
Google talked a little about how personalized search works in a paper about BigTable, it's worth a review:
> Personalized Search stores each user's data in Bigtable. Each user has a unique userid and is assigned a row named by that userid. All user actions are stored in a table. A separate column family is reserved for each type of action (for example, there is a column family that stores all web queries). Each data element uses as its Bigtable timestamp the time at which the corresponding user action occurred. Personalized Search generates user profiles using a MapReduce over Bigtable. These user profiles are used to personalize live search results.
Regardless, even in your scenario with the perfect RDBMS, the future web stack wouldn't change much. You still have the same issues with blocking and different languages for client and server. As a developer myself, it doesn't matter at all to me if my call to a method is backed by a relational, document or key/value database. It's all an abstraction somewhere. It just needs to come back quickly and be easy to scale up.
The big change we're seeing is the client becoming primarily JS driven and the server more or less relegated to sending/receiving JSON. It's a much richer experience, but a pain when the toolsets on either end are completely different.
This is how I read it. He was saying it's alright to go with bleeding-edge technologies, even if they're a little shaky now. As long as they have a good dev community behind them, they'll get better.
This is one of those remarks that is obvious to someone who knows what it means but mysterious to someone who doesn't. So what does it really mean?
- Don't use a technology that, no matter how good, is just too niche for widespread adoption?
- Don't use a technology that we'll have trouble finding programmers to support?
- Look for stuff that will take better advantage of impending improvements in hardware and communications?
- Avoid frameworks for which support may wane?
- Avoid technology that we may have to support ourselves?
- Avoid anything proprietary whose owner may disappear?
- Make sure that whatever you choose, it will work well on mobile technologies, even as native apps?
- Choose technologies abstract enough to minimize our costs but not too abstract to be inefficient?
- Any combination of the above?
- What considerations have I missed?