RabbitMQ
Kubernetes
Docker
Java
Spring Boot
PostgreSQL
Kafka
Terraform
GitHub ActionsPattern
It is often not RabbitMQ itself
Many issues come from misunderstanding the default out-of-the-box configuration, whether it is a standalone install, a preconfigured Docker image or a Kubernetes deployment. Recurring themes are monitoring, management, high availability, quorum queues and performance characteristics.
Engagement
RabbitMQ and the application in the same pods
One company ran RabbitMQ in Kubernetes, co-resident in the same pods as its in-house application. We explained how sudden pod restarts, triggered whenever the application failed, could disrupt RabbitMQ and make recovery harder.
Simple changes to the deployments and networking were a quick win, and the team came away understanding how to run RabbitMQ properly in Kubernetes.
- Run the broker as its own workload, not inside the application's pods.
- Treat restarts as normal and plan for recovery.
- Monitor the broker separately from the application.
Modernization
Link to modernization
Moving workloads to containers changes failure behavior. Check it step by step, as in the 8 principles. See Application modernization services and the documented American National case study.