Se você não conhece nenhuma dessas soluções, vou fazer um breve apanhado sobre as capacidades de cada uma delas.

Redis ( http://redis.io/ )

Redis é um Key-Value Storage. Basicamente um tipo de NoSQL baseado em chave-valor. Nele armazenamos objetos complexos. É uma solução muito útil para cache, entre outras abordagens. Se você já usou SharedCache, Memcached, e outras soluções de cache, sabe muito bem do que estou falando. Para você que nunca usou, pense que quando a descoberta de um dado é relativamente custosa, armazenar esse dado em um cache é uma das primeiras estratégias para garantir carga em seu site ou aplicação. Com um cache server você armazena seus objetos, determina um tempo de expiração para o objeto que está armazenando, e na medida que a aplicação vai sendo utilizada, cada vez mais você deixa de executar aquele longo processamento para entregar dados já processados que estão no cache. Já vi pessoas dizendo que o esforço para ir a um cache de rede e entregar um resultado a partir dele possa parecer infundado, mas quando você recebe milhares de requisições por segundo, processar algumas queries a cada request te custam caro, muito caro.

MongoDB ( https://www.mongodb.org/ )

Não há quem não tenha lido sobre NoSQL que não tenha ouvido falar nele. MongoDB é uma das soluções NoSQL mais conhecidas e usadas pelo mercado. Mas admito considerar que nossa relação esteja por um fio. De qualquer forma, se você pode usar um document store em seu ambiente de produção, MongoDB é sempre uma solução a se pensar.

Existem diversos fatores que te fazem pensar em NoSQL, seja por flexibilidade, performance, e capacidade de lidar com volumes dados realmente grandes. MongoDB sempre terá seu espaço. Mas considere o Couchbase como alternativa, eu venho olhando para o produto com um olhar muito benevolente nos últimos meses.

RabbitMQ ( https://www.rabbitmq.com/ )

Nessa área, embora o RabbitMQ tenha se mostrado uma das melhores soluções do mercado, existem diversas alternativas. O principal motivador para usar filas, invariavelmente é pensar em modelos assíncronos e escaláveis de processamento. A adoção do RabbitMQ se dá pela implementação do standard AMQP, esse sim merece muito sua atenção. Se você ainda usa MSMQ, principalmente! MSMQ está fadado ao fracasso e a tendência é que a Microsoft ofereça um serviço AMQP fora do Azure. Acredito que o Service Bus for Windows Server já esteja compatível com AMQP, mas a adoção de AMQP no Azure é o principal sinal de que todo o mercado, inclusive a Microsoft, estão convergindo para padrões universais, inclusive no quesito message broker.

Sentry ( https://getsentry.com/ )

O Sentry me foi apresentado por um rapaz que trabalha comigo, e admito nunca ter sequer chegado perto dessa solução antes disso. Já conhecia o LogEntries e ao conhecê-lo adito ter me frustrado muito, principalmente por estar planejando um produto exatamente assim. Fato que criei o LogEngine, que por sua vez tinha uma performance muito boa se comparado a estes, mas me faltou braço para criar a interface Web. O Sentry vem como uma solução centralizada para armazenamento e visualização de eventos de aplicação, servindo para que você tenha um console completo com tudo o que acontece com sua aplicação.

E o Linux?

O que todas essas soluções trazem de interessante é que foram concebidas para performar melhor em ambiente linux, mas nem por isso, soluções baseadas em tecnologia Microsoft não podem se valer do grande benefício que esses serviços nos prestam. Ter um parque heterogêneo não é fácil, mas podemos usar o melhor que cada mundo tem a nos oferecer!

Enfim sem bairrismo, use aquilo que te ajuda a te entregar mais, com menos!

E você, está usando outros serviços hospedados em servidores linux que podem ajudar aplicações .net? Quais?