Cómo migrar de Apache Kafka open source a Confluent sin detener la operación

Muchas organizaciones de la región llegaron a Apache Kafka por el camino correcto: un equipo con criterio lo levantó para resolver un problema concreto, funcionó, y se fue convirtiendo en infraestructura crítica sin que nadie tomara la decisión formal de que lo fuera.

El punto de quiebre llega cuando ese clúster que empezó como un proyecto de un equipo sostiene procesos que no pueden caerse, y la organización se da cuenta de que la operación depende de dos o tres personas que saben cómo funciona.

Ahí es donde aparece la conversación de migrar a una plataforma gestionada. Y ahí es donde la mayoría de los planes se rompen, porque se plantean como un corte.

Por qué no funciona la ventana de mantenimiento

El instinto natural es programar un fin de semana, mover todo y volver el lunes. Con una base de datos a veces se puede. Con una plataforma de eventos, casi nunca.

La razón es que Kafka no es un almacén, es un flujo con estado distribuido en muchos consumidores. Migrar significa mover no solo los datos sino la posición de lectura de cada aplicación consumidora, y hacerlo de forma que ninguna reprocese lo que ya procesó ni se salte lo que no.

Con cinco aplicaciones puede salir bien. Con cuarenta, la probabilidad de que las cuarenta queden exactamente donde deben estar en la misma ventana es baja. Y el modo de falla no es un error visible: es un consumidor que quedó atrasado y nadie lo nota hasta que aparece una diferencia en una conciliación tres días después.

Convivencia en lugar de corte

El enfoque que aplicamos es distinto: los dos clústeres operan en paralelo durante la migración, y los dominios se mueven de uno a otro cuando cada uno está listo.

La pieza que lo hace posible es la replicación entre clústeres. Los topics se replican del origen al destino de forma continua, incluyendo la posición de los consumidores. Eso convierte un evento único e irreversible en una serie de decisiones pequeñas y reversibles.

El orden que nos ha funcionado:

Primero se replica, sin mover a nadie. El clúster destino recibe todo y no lo consume nadie. Aquí se valida el rendimiento, la retención, los esquemas y el dimensionamiento real, con tráfico de producción y sin riesgo.

Después se mueven los consumidores, no los productores. Un consumidor que lee del destino en lugar del origen es un cambio de configuración reversible. Si algo sale mal, vuelve a apuntar al origen y sigue operando. Se empieza por los consumidores menos críticos.

Al final se mueven los productores, dominio por dominio. Este es el paso que hace irreversible el corte para ese dominio, y por eso es el último. Cuando un productor escribe en el destino, sus consumidores ya llevan tiempo leyendo de ahí sin incidentes.

El origen se apaga cuando ya no lo usa nadie, no cuando el plan decía que tocaba.

Lo que se descubre por el camino

Una migración de streaming casi siempre destapa cosas que estaban escondidas. Conviene esperarlas en lugar de que sorprendan.

Topics que nadie consume. Es normal encontrar que una parte de lo que se está publicando no lo lee nadie desde hace meses. Migrar es una buena oportunidad para dejar de pagar por moverlos.

Esquemas que en realidad no existen. Muchos clústeres open source operan sin registro de esquemas, con el contrato viviendo en la cabeza del equipo que lo escribió. Al pasar a una plataforma con registro de esquemas aparecen las incompatibilidades que estaban latentes. Es mejor que aparezcan en la migración que en un incidente.

Configuraciones de retención heredadas. Retenciones de siete días puestas por defecto hace tres años, sobre topics donde el negocio necesitaría treinta, o al revés.

Consumidores que dependen del orden sin saberlo. Aplicaciones que funcionan porque las particiones les llegaron en cierto orden y nadie lo documentó.

Lo que hay que tener antes de empezar

Antes de replicar el primer topic conviene tener tres cosas resueltas.

Un inventario real de productores y consumidores, no el diagrama de arquitectura sino quién está conectado hoy. Casi siempre difieren.

Un criterio de dominio para decidir qué se mueve junto. Mover por orden alfabético de topic garantiza problemas; mover por dominio de negocio, no.

Una definición explícita de qué significa que un dominio quedó migrado, acordada antes y no negociada durante. Sin eso, cada corte se convierte en una discusión.

Cuánto toma

Depende casi por completo del número de aplicaciones productoras y de qué tan acoplado esté el consumo, no del volumen de datos. Un clúster con mucho tráfico y pocas aplicaciones se migra rápido. Un clúster mediano con decenas de aplicaciones de equipos distintos toma bastante más, porque el trabajo real es de coordinación, no técnico.

Lo que sí se puede afirmar con seguridad es lo contrario del instinto inicial: no hace falta detener la operación. Si el plan de migración requiere una ventana de indisponibilidad para una plataforma de eventos, probablemente el plan esté mal.