Yesterday I've written about our experience with RabbitMQ and our reasons why have we decided to introduce a new piece of technology to our stack. This can serve as a good introduction to a wider question what should (and shouldn't) be deciding factors in choosing a particular technology. The first consideration when introducing new technology should be that sufficient number of other people use it. You really do not want to be a crash test dummy when it comes to new technology. Every new piece of technology has not only benefits, but also lot of side effects and hidden defects. It takes lots of time and resources to root them out or, more commonly, to circumvent defects in some ingenious way. I've heard that banks have a rule that no new technology should be introduced which is not battle tested for at least three years. Of course, business processes of banks are much more well-defined and understood than business processes at startups, so we cannot enjoy the privilege of using so well-tested technologies in startups. But we should remind ourselves constantly that, just like core business of banks is trading money, the core business of startups is searching for a repeatable and scalable business model and not playing with unreliable technology.
The second consideration when introducing new technology should be if the new technology solves a real and pernicious problem. If you have a problem that no established technology is capable of solving, then you should first contemplate whether you are really so special or you just like to think of yourself as something special. Quite often the most effective solution of a problem is changing your process to fit the existing technology, and not finding the technology that would perfectly fit to idiosyncrasies of your process.
With regards to which factors shouldn't be deciding when choosing a new technology, you should read the following article:
Today, software developers are faced with a great abundance of options when choosing how to design and implement systems. We are constantly bombarded with choice and are used to dealing with buzzwords like NoSQL, the cloud, REST, Map-Reduce and so on.