[heipei]

Personally I believe that even more important than picking boring technology is limiting the number of different technologies in your tech stack. That will allow you to collect more best practices, build better tooling and monitoring and develop operational experience in those few technologies than if it was spread across multiple similar stacks.

Example: React is great for starting with smaller and/or progressively enhanced websites, but if you were to develop a large monolithic SPA you might benefit more from something like Ember. However it would be better to use one stack which can cover both use-cases, so you should probably go with React for both, otherwise you'll forever be rewriting the same code for both stacks and figuring out build and tooling issues twice.

Another example: You might need a lightweight message queue for smaller background processing needs, and you might also need a proper distributed log. The former could be solved by any number of queues, while the latter calls for something like Kafka. If Kafka can also reasonably cover the first use-case you should try to use it for both.

[perrygeo]

Exactly. Choose boring technology, but more importantly choose technology that works within your org and keep it consistent.

Say your company chooses risky, bleeding edge tech and uses it everywhere. You'll build institutional knowledge that can be transferred across projects, lowering the risk.

If every single app or microservice uses a different "boring technology" - one team is using Python and Postgres, another team is using Ruby and MySQL, etc - the knowledge gets siloed quickly which increases risk, no matter how "boring" those individual choices may seem.