En el mundo tecnológico, pocas decisiones son tan críticas como cambiar la infraestructura de mensajería de una empresa

Y eso fue exactamente lo que decidió hacer DIVERSITY, una compañía cloud-native con presencia global y centros de datos en Europa y América. ¿La razón? Kafka, un estándar del mercado, ya no cumplía con las expectativas de rendimiento de la empresa. Y el reemplazo, aunque menos conocido, resultó estar mucho más alineado con su filosofía: NATS.

Para entender en profundidad este cambio estratégico, entrevistamos a Elena Alonso, directora de Desarrollo de Negocio y Marketing, y a Sergio Ceballos, CTO de DIVERSITY.

Elena Alonso: ¿Por qué decidiste replantearte el uso de Kafka?

Sergio Ceballos: Kafka nos sirvió bien durante años en muchos despliegues. Pero con el tiempo, comenzamos a notar que no satisfacía nuestras necesidades de velocidad y eficiencia. Tuvimos problemas de latencia en flujos críticos, especialmente cuando los nodos alcanzaban picos de carga. Para una empresa cloud-native como DIVERSITY, donde los servicios dependen del streaming de eventos en tiempo real, eso es inaceptable.

Kafka nos estaba frenando

Elena Alonso: Sergio, en una organización cloud-native como la nuestra, cambiar una tecnología fundacional como Kafka no es una decisión menor. ¿Qué motivó esta revisión?

Sergio Ceballos: Lo que al principio parecía un tema de ajuste de recursos, terminó siendo un problema estructural. Kafka nos estaba frenando. Teníamos latencias altas incluso en flujos internos, y su consumo de recursos no se alineaba con nuestra visión de eficiencia. Cuando hicimos pruebas internas con NATS, vimos mejoras reales: tiempos de respuesta más rápidos, menor uso de CPU y RAM, y una arquitectura operativa mucho más simple.

Elena: ¿Cuándo comenzó este análisis?

Sergio: Oficialmente, hace unos cuatro meses. El primer mes fue una prueba de concepto intensiva en entornos controlados. Vimos que NATS no solo era más eficiente, sino que también nos permitía rediseñar nuestra infraestructura para alinearla mejor con Kubernetes. Descubrimos 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 liviano que era, y los resultados fueron sorprendentes, especialmente por la curva de aprendizaje mucho más suave para nuestros equipos.

La prueba de concepto: NATS destaca

Elena: ¿Qué los convenció durante la prueba de concepto?

Sergio: Dos cosas: JetStream y la ligereza del sistema. JetStream, la capa de persistencia de NATS, nos mostró que podíamos tener retención sin el alto uso de disco que experimentábamos con Kafka. Y en segundo lugar, NATS encajaba mucho mejor con nuestro enfoque cloud-native, especialmente en Kubernetes.

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

La migración: del físico al contenerizado

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

Sergio: Honestamente, fue muy ágil. Como no tenemos sistemas legacy, pudimos movernos rápido. En total tomó tres meses desde la PoC hasta producción. Un mes para la PoC, y los dos siguientes para una 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 para NATS.

Elena: ¿Y los desafíos?

Sergio: Principalmente, el cambio de mentalidad del equipo. Teníamos años de experiencia con Kafka—sus particiones, brokers, zookeepers… NATS es otro mundo. Más simple, sí, pero requiere un buen entendimiento de los flujos modernos de pub-sub. El mayor 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, la mayoría del equipo ya operaba con comodidad.

Resultados tangibles: consumo, contenedores y sostenibilidad

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

Sergio: Absolutamente. Vimos una reducción del 40% al 80% en el uso promedio de CPU y RAM por nodo. Pasamos de 10 nodos de Kafka en bare-metal a solo 3 nodos de NATS en Kubernetes. Esto nos permitió contenerizar el sistema, lo que trajo varios beneficios:

  • Reducimos el mantenimiento en un 30% para nuestros equipos de SRE y DevOps.
  • Simplificamos la seguridad usando certificados TLS mutuos nativos de NATS.
  • Redujimos el uso de IOPS y almacenamiento en un 50%.
  • Y quizá lo más importante: al reducir el consumo energético de los servidores, disminuimos nuestra huella de carbono en 2.5 toneladas por año.

Arquitectura actual: Kubernetes como núcleo

Elena: ¿Puedes compartir algo sobre la arquitectura actual, sin revelar información sensible?

Sergio: Por supuesto. Hoy tenemos una arquitectura 100% nativa en Kubernetes. Cada instancia de NATS corre como contenedor en un StatefulSet. JetStream opera en modo clúster y usamos volúmenes persistentes desde un clúster Ceph, lo que nos da flexibilidad y resiliencia.

También implementamos seguridad por tenant, con certificados únicos gestionados por nuestra plataforma de identidad en la nube. Todo el sistema se conecta con nuestros microservicios internos de IA y procesamiento de eventos, siendo el núcleo de nuestras soluciones orientadas a eventos.

¿Sigue teniendo sentido Kafka para algunas empresas?

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 donde se requieren garantías estrictas de orden y reintentos. Pero para empresas cloud-native centradas en eficiencia, escalabilidad y simplicidad, NATS tiene una ventaja clara. Si empiezas desde cero, no hay razón para complicarse.

Lecciones aprendidas como equipo técnico

Elena: ¿Qué te deja esta experiencia como CTO?

Sergio: No te cases con la tecnología. Incluso los grandes nombres pueden volverse cuellos de botella. Y 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, sostenibles y seguros. Seguiremos ampliando su uso—no solo en streaming tradicional. Estamos explorando integraciones con sistemas de IA para procesamiento en tiempo real y escenarios de edge computing para clientes con despliegues híbridos. Además, con NATS ahora tenemos una base mucho más ágil para construir nuevos servicios cloud-native.

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 siempre buscamos optimizar—no solo para nosotros, sino también para nuestros clientes. Migraciones como esta nos permiten ser más eficientes y trasladar ese valor a nuestras soluciones: desde nuestras plataformas de IA, hasta nuestra infraestructura en la nube y bare-metal, y nuestros servicios de consultoría y event streaming.

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

¿Estás considerando modernizar tu infraestructura de eventos?