En el mundo de la tecnología, pocas decisiones son tan críticas como la de cambiar la columna vertebral de la infraestructura de mensajería de una empresa. Sin embargo, eso es exactamente lo que hizo DIVERSITY, una compañía cloud-native con presencia global y centros de datos en Europa y América. ¿La razón? Kafka, uno de los estándares del mercado, no cumplía con las expectativas de rendimiento de la compañía. Y el reemplazo, aunque menos conocido, demostró estar más alineado con su filosofía: NATS.

Para entender en profundidad este cambio estratégico, entrevistamos a Elena Alonso, directora de la unidad de desarrollo de negocio y márketing, y a Sergio Ceballos, CTO de DIVERSITY.

Elena Alonso: ¿Por qué decidisteis reconsiderar el uso de Kafka?

Sergio Ceballos: Kafka nos acompañó durante años en muchos despliegues. Pero con el tiempo, empezamos a notar que no respondía bien a nuestras necesidades de velocidad y eficiencia. Teníamos problemas de latencia en los flujos críticos, especialmente cuando los nodos alcanzaban picos de carga. Eso, para una compañía cloud-native como DIVERSITY, con servicios que dependen en tiempo real del streaming de eventos, no es aceptable.

“Kafka nos estaba frenando”

Elena Alonso: Sergio, en una organización cloud-native como la nuestra, cambiar un pilar tecnológico como Kafka no es una decisión menor. ¿Qué fue lo que impulsó esta revisión?

Sergio Ceballos: Lo que inicialmente parecía un tema de ajuste de recursos se convirtió en un problema estructural. Kafka nos estaba frenando. Teníamos latencias muy altas incluso en flujos internos, y su consumo de recursos estaba desalineado con nuestra visión de eficiencia. Eso, para una compañía cloud-native como DIVERSITY, con servicios que dependen en tiempo real del streaming de eventos, no es aceptable. Al hacer benchmarks internos con NATS, vimos mejoras reales: respuestas más rápidas, menos uso de CPU y memoria, y una arquitectura operativa mucho más simple.

Elena: ¿Y cuándo comenzó este análisis?

Sergio: Formalmente hace unos cuatro meses. El primer mes fue una prueba de concepto intensiva en entornos controlados. Vimos que no solo NATS era más eficiente, sino que también nos permitía rediseñar la infraestructura para alinearla aún más con Kubernetes. Nos topamos con NATS casi por curiosidad. Un par de arquitectos de sistemas lo estaban evaluando para un cliente. Lo que nos llamó la atención fue lo ligero que era y los resultados fueron sorprendentes, particularmente una curva de aprendizaje mucho más suave para nuestros equipos.

La prueba de concepto: NATS empieza a destacarse

Elena: ¿Qué te convenció en la prueba de concepto?

Sergio: Dos cosas: JetStream y la ligereza del sistema. JetStream, la capa de persistencia de NATS, demostró que podíamos tener retención sin incurrir en el alto consumo de disco que teníamos con Kafka. Y segundo, NATS encajaba mejor con nuestro enfoque cloud-native, sobre todo en Kubernetes.

De hecho, pasamos de tener Kafka desplegado en nodos bare-metal con configuraciones personalizadas, a tres pods de NATS orquestados por Kubernetes. Eso por sí solo nos dio más elasticidad y menos dependencia de infraestructura fija.

La migración: de lo físico a lo contenedorizado

Elena: ¿Cómo fue el proceso de migración? Suena ambicioso.

Sergio: Fue muy ágil, honestamente. Como no tenemos sistemas heredados, pudimos movernos rápido. En total, fueron tres meses desde la PoC hasta la producción. Un mes fue la prueba, y los siguientes dos la transición progresiva. Migramos varios pipelines internos, adaptamos las suscripciones de nuestros microservicios y diseñamos una nueva capa de observabilidad sobre Prometheus y Grafana adaptada a NATS.

Elena: ¿Y los desafíos?

Sergio: Básicamente, cambiar el chip mental del equipo. Veníamos con años de Kafka, sus particiones, brokers, zookeepers... NATS es otro mundo. Más simple, sí, pero también requiere entender bien los flujos de trabajo pub-sub modernos. El principal desafío fue cultural: cambiar la mentalidad del equipo. Muchos estaban acostumbrados a las herramientas y comandos de Kafka. Pero la documentación de NATS es excelente, y en dos semanas ya teníamos la mayoría del equipo operando con normalidad.

Resultados concretos: consumo, contenedores y sostenibilidad

Elena: ¿Y los resultados en producción? ¿Valió la pena?

Sergio: Totalmente. Vimos entre un 40% y 80% menos de uso promedio de CPU y RAM por nodo. Antes necesitábamos 10 nodos Kafka en bare-metal, ahora tenemos solo 3 nodos NATS en Kubernetes. Esto permitió contenerizar el sistema, y eso trajo varios beneficios:

• Redujimos el mantenimiento en un 30% para nuestros equipos SRE y DevOps.
• Simplificamos la seguridad usando certificados TLS mutuo (mTLS) client-server nativos de NATS.
• El consumo de IOPS y almacenamiento se redujo un 50%.
• Y quizás lo más significativo: al bajar la carga energética de nuestros servidores, redujimos nuestra huella de carbono en 2.5 toneladas por año.

La arquitectura actual: Kubernetes como núcleo

Elena: ¿Qué puedes contarnos de la arquitectura actual, sin comprometer detalles sensibles?

Sergio: Claro. Hoy tenemos una arquitectura 100% Kubernetes-native. Cada instancia de NATS corre como un contenedor dentro de un StatefulSet. JetStream opera en modo clustered, y usamos volúmenes persistentes proporcionados por un cluster de Ceph, que nos dan flexibilidad y resiliencia.

Además, montamos una capa de seguridad por tenant, con certificados únicos gestionados mediante nuestra plataforma de identidad cloud. Todo el sistema está conectado a nuestros microservicios internos de IA y procesamiento de eventos, lo que lo convierte en el backbone de nuestras soluciones event-driven.

¿Kafka sigue teniendo sentido para alguna empresa?

Elena: Muchos clientes usan Kafka como estándar. ¿Crees que NATS es para todos?

Sergio: No necesariamente. Kafka tiene casos de uso válidos, especialmente cuando se necesitan garantías estrictas de orden y reintento. Pero para empresas cloud-native, con foco en eficiencia, escalabilidad y simplicidad, NATS tiene una ventaja clara. Si empiezas desde cero, no hay razón para complicarte.

Lo que aprendimos como equipo técnico

Elena: ¿Qué aprendizaje te llevas como CTO?

Sergio: Que no hay que casarse con las tecnologías. Incluso los grandes nombres pueden volverse cuellos de botella. Y que una arquitectura flexible, basada en contenedores, te permite evolucionar más rápido. El cambio de Kafka a NATS fue una decisión técnica, pero también estratégica: nos permitió ser más ágiles, más sostenibles y más seguros. Vamos a seguir ampliando su uso, no solo en event streaming tradicional. Estamos explorando integraciones con sistemas de IA para procesamiento en tiempo real, y casos de edge computing para clientes con despliegues híbridos. Además, con NATS tenemos una base mucho más ágil para crear nuevos servicios nativos de la nube.

Una empresa cloud-native se reinventa constantemente

Elena: Para cerrar, ¿cómo se alinea este cambio con la visión de DIVERSITY?

Sergio: Completamente. En DIVERSITY buscamos constantemente optimizar, no solo para nosotros, sino también para nuestros clientes. Este tipo de migración nos permite ser más eficientes y transmitir ese beneficio en nuestras soluciones: desde nuestras plataformas de inteligencia artificial, hasta nuestra infraestructura cloud y bare-metal, pasando por nuestros servicios de consultoría y event streaming.

Kafka fue un gran aliado durante años, pero en esta etapa, NATS nos ofrece exactamente lo que buscamos: velocidad, simplicidad, seguridad y sostenibilidad.

¿Estás considerando modernizar tu infraestructura de eventos?

DIVERSITY ayuda a las organizaciones a escalar con confianza, ofreciendo una infraestructura en la nube segura y de alto rendimiento adaptada a cargas de trabajo modernas. Desde servidores GPU listos para IA hasta bases de datos totalmente gestionadas, te ofrecemos todo lo necesario para construir, conectar y crecer — todo en un solo lugar.

Tanto si estás migrando a la nube, optimizando tu stack con event streaming o inteligencia artificial, como si necesitas colocación empresarial y servicios de telecomunicaciones, nuestra plataforma está diseñada para ofrecer resultados.

Descubre potentes soluciones en la nube como Servidores Privados Virtuales, Redes Privadas, Almacenamiento de Objetos y MongoDB Gestionado o Redis. ¿Necesitas bare metal para cargas pesadas? Elige entre una gama de servidores dedicados, incluidos los optimizados para GPU o almacenamiento.