I always wince when I hear teams bragging about the number of datastores/frameworks/languages that they use.
“No big deal. We keep our relational data in Postgres, our non-relational data in Mongo, any sets that we might have in redis and obviously we use good ol’ memcached when we need it. We use rails for our web workers, but it’s not async so we use node for our background workers. We make sure we use the right tool for the job.”
When it’s not mere self-indulgence, adding “the right tool” is usually a premature optimization. If you’ve chosen a decent stack, odds are that whatever benefits an additional tool might have are outweighed by the complexity it adds to your project.
Be aware of the maintenance cost of adding a new tool to your stack. For example, if you’re adding a new datastore, do you have a way of setting it up in your development, and staging environments? Do you have a plan for testing it? Can you scale it? Does your backup system work? Can you allot time to teach every current and future teammate how it works? If you don’t have an answer to any of these, you’re adding risk to your startup.
Even if you’re rigorous in properly installing your new tool, adding it to your stack increases your complexity. When complexity increases, so does the risk that something will fall apart.
Use tools that fail together
Counterintuitively, putting all of your eggs in one basket is often good for stability. Imagine that you’re choosing between two stacks for a Python app with Postgres and Redis.
- Google AppEngine
- Heroku Postgres
- RedisCloud cluster on Rackspace
- Heroku Postgres
- OpenRedis Addon
Let’s say that each of the services have 99.9% uptime. You might think that both stacks would have the same uptime. The thing is, all the services in Stack B are served on EC2, so when they fail, they fail at the same time. All the services in Stack A are in different datacenters. This means that they’re likely to each fail at different times, and in total, the stack will be down three times as often as Stack B.*
When is “the right tool” the right tool?
Pick your risks. When you start a project you’re not going to choose to implement a new product using a new framework in a new language backed by a new database. Instead, choose something to experiment with and work on a branch.
At Grouper we like to use small projects to test out new tools. For example, we tested ember.js on a simple embedded questions game before using it for our mission-critical admin pages.
- Tom Brown - find me on Twitter here.