Enfoques

Generalmente Confluent suele ser el mejor servicio de Kafka SaaS. Tiene integración con varias herramientas, es bastante completo, vale la pena echarle un vistazo.

Sin embargo, si queremos instalar Kafka autogestionado, recomiendo fuertemente que se use Kafka dentro de Kubernetes. Aunque es posible la instalación bare metal con VMs, ¿por qué sufrir? ¿Quieres esa responsabilidad? ¿Quién lo va a mantener? Piensa en eso...

Requisitos:

• docker u otro container runtime
• kind o algún cluster con al menos 3 nodos workers
• kubectl
• helm

Zookeeper vs Kraft

El primer enfoque que debemos entender es si debemos o no utilizar Zookeeper para la coordinación del cluster que vamos a montar.

Primero debemos entender sobre Raft Consensus. Aquí en el sitio hay un artículo sobre Raft Consensus para ayudar a entender mejor el concepto.

Si quieres un artículo para entender por qué debemos utilizar kraft aquí está una buena idea de lectura.

Después de la lectura, debes haber entendido que Kafka Raft tiene mayor rendimiento, menos tolerancia a fallos y menos escritura. Entonces si estás hoy preparando una instalación para Kafka, utiliza el nuevo estándar Kafka Raft.

Autogestionado o SaaS

Si el cluster Kafka es muy grande, optar por una solución SaaS, como Confluent Cloud, puede tener sentido por algunos motivos:

• Escalabilidad Automática
  • Gestionar cientos o miles de tópicos y particiones manualmente es complejo.
  • Confluent Cloud escala automáticamente conforme la carga aumenta, sin necesidad de ajustar brokers o particiones manualmente.
• Menos Sobrecarga Operacional
  • En un cluster muy grande necesitamos un equipo dedicado para gestionar: Actualizaciones de versión de Kafka, Balanceo de carga, Configuración de seguridad (RBAC, ACLs, autenticación), Monitoreo y troubleshooting.
  • En SaaS, todo esto es gestionado por Confluent, reduciendo el esfuerzo del equipo.
• Alta Disponibilidad y Recuperación ante Desastres
  • Mantener un Kafka altamente disponible (HA) y con recuperación ante desastres exige múltiples clusters distribuidos y replicación entre regiones.
  • Confluent ya ofrece esto listo y gestionado, con SLAs garantizados.
• Seguridad y Cumplimiento
  • Empresas grandes necesitan garantizar seguridad end-to-end (encriptación, IAM, logs de auditoría).
  • Confluent Cloud ya viene con soporte para cumplimiento con GDPR, HIPAA, SOC 2, ISO 27001 etc.
• Costos vs. Equipo
  • Mantener un cluster Kafka grande en Kubernetes (Strimzi o CFK) exige muchos recursos: Infraestructura potente (varios brokers, storage), Equipo especializado para operar el cluster
• En SaaS, pagas por uso y eliminas costos operacionales, pudiendo enfocarte en el desarrollo de aplicaciones en lugar de gestionar la infraestructura.

¿Cuándo tiene sentido ir a SaaS?

• Si el cluster crece rápido y quieres evitar dolores operacionales.
• Si necesitas alta disponibilidad y recuperación ante desastres sin complicación.
• Si la empresa tiene requisitos de seguridad y cumplimiento rigurosos.
• Si quieres reducir el equipo de infraestructura y enfocarte solo en la aplicación.

Si tu infraestructura es pequeña o moderada, un cluster autogestionado aún vale la pena. Sin embargo, tiene sentido considerar una solución SaaS cuando el costo de mantener tu propio Kafka (equipo + infraestructura) se vuelve excesivo.

Cuando la operación crece demasiado, no estamos solo pagando por la conveniencia, sino también tercerizando los desafíos — y, de paso, teniendo a alguien para asumir la responsabilidad cuando algo salga mal!

Instalación en Kubernetes

Antiguamente la mejor manera que conocía de disponibilizar algo cercano a lo que Confluent ofrecía era ejecutar varios helm charts diferentes: un helm chart de bitnami para instalación de Kafka, un chart para ejecutar el servicio de schema-registry (también de bitnami), un servicio kafka UI que me daba un dashboard y varios otros servicios agregados a kafka que también eran instalados vía Helm chart y podían ser visualizados por la UI (ksql, connects, rest y control-center).

Afortunadamente hoy en día tenemos un proyecto en la CNCF llamado Strimzi que facilita bastante la instalación de un cluster kafka dentro de Kubernetes.

¿Cuál es la ventaja?

• Despliega y ejecuta clusters Kafka
• Gestiona componentes de Kafka
• Configura el acceso a Kafka
• Protege el acceso a Kafka
• Actualiza Kafka
• Gestiona los brokers
• Crea y gestiona tópicos
• Crea y gestiona usuarios
• Se enfoca en el control de Kafka no en las herramientas agregadas a él.

Aquí tenemos aquella arquitectura que ya conocemos del estudio, pero ahora tenemos algunas cositas más.

• El Kafka Bridge (Ya mencionado antes como Kafka Rest) proporciona una interfaz RESTful que permite que clientes basados en HTTP interactúen con un cluster Kafka. Ofrece las ventajas de una conexión HTTP API con Strimzi para que clientes produzcan y consuman mensajes sin necesidad de usar el protocolo nativo de Kafka.

• Kafka Exporter extrae datos para análisis como métricas de Prometheus, principalmente datos relacionados con offsets, grupos de consumidores, lag del consumidor y tópicos. El lag del consumidor es el retraso entre el último mensaje escrito en una partición y el mensaje que está siendo actualmente recolectado de esa partición por un consumidor.

• Kafka MirrorMaker (No usaremos) replica datos entre dos clusters Kafka, en el mismo data center o en lugares diferentes.

Un cluster Kafka está compuesto por varios nodos que operan como brokers que reciben y almacenan datos. Los tópicos se dividen por particiones, donde los datos son grabados. Las particiones son replicadas entre los brokers para tolerancia a fallos. Kafka suele ser la espina dorsal de todo cuando se utiliza, todo pasa por él, entonces pensemos en la redundancia.

Strimzi vs Confluent for Kubernetes (CFK)

Podemos instalar un cluster Kafka completo utilizando Strimzi o Confluent for Kubernetes (CFK). Ambos utilizan el concepto de Operators, que trabajan con Custom Resource Definitions (CRDs) en Kubernetes para facilitar la instalación y configuración de los componentes de Kafka.

Strimzi se enfoca exclusivamente en la gestión del cluster Kafka, ofreciendo soporte para brokers, Zookeeper, Kafka Connect y MirrorMaker. Sin embargo, no incluye directamente componentes como Schema Registry, KSQL e interfaces gráficas. Tal vez esto cambie en el futuro, pero actualmente estos recursos necesitan ser gestionados por separado.

Ya CFK gestiona todo el ecosistema Confluent, incluyendo Kafka, Schema Registry, KSQL y Control Center, todo bajo un único Operator. Sin embargo, tiene dos versiones:

• Community – gratuita, pero con funcionalidades limitadas.
• Enterprise – de pago, con recursos avanzados como RBAC, Multi-Tenancy y Observabilidad.

Si la intención es pagar, tal vez tenga más sentido utilizar el SaaS de Confluent, en lugar de desplegar todo en Kubernetes.

Aunque es posible usar solamente CFK para instalar Kafka, existen algunas desventajas en relación a Strimzi, que lo hacen una mejor opción:

• Kafka Open Source Puro
  • Strimzi sigue 100% Apache Kafka open-source, sin dependencia de un vendor específico.
  • CFK instala la versión Confluent de Kafka, que puede traer limitaciones en la versión Community y exigir licenciamiento para ciertas funcionalidades.
• Menos Dependencia de Software Propietario (Vendor Lock-in)
  • Con Strimzi, mantienes el control total de tu ambiente y puedes migrar o personalizar tu cluster Kafka sin restricciones.
  • CFK puede generar dependencia de Confluent, especialmente si necesitas funcionalidades que solo existen en la versión Enterprise.
• Ligereza y Eficiencia
  • Strimzi es más esbelto y enfocado exclusivamente en Kafka, sin traer dependencias innecesarias.
  • CFK, por otro lado, gestiona Kafka + Schema Registry + KSQL + Control Center, lo que puede ser un overkill caso solo quieras ejecutar Kafka.
• Mejor Integración con Kubernetes
  • Strimzi fue creado específicamente para Kubernetes, siguiendo patrones nativos de Operators y CRDs.
  • CFK también usa CRDs, pero su foco mayor es reproducir el ecosistema Confluent dentro de Kubernetes, lo que puede agregar complejidad innecesaria.
• Comunidad Activa e Independiente
  • Strimzi es un proyecto CNCF (Cloud Native Computing Foundation), con soporte de la comunidad y alineado al ecosistema Kubernetes.
  • CFK es mantenido por Confluent, y su desarrollo está más ligado a la estrategia comercial de la empresa.

A pesar de sus desventajas para gestionar Kafka, CFK facilita la instalación de Confluent Schema Registry, KSQL y Control Center dentro de Kubernetes si vas a utilizar alguno de estos recursos tiene sentido utilizarlo.

No vamos a utilizar ninguno de estos recursos de CFK por el siguiente motivo.

• Si utilizamos Confluent Schema Registry

Con este enfoque híbrido, conseguimos lo mejor de dos mundos:

• Strimzi para gestionar Kafka (ligero, flexible y sin lock-in).
• CFK apenas para Schema Registry y otros servicios (facilidad de despliegue).

De esta forma, evitamos dependencias innecesarias y mantenemos Kafka más ligero e independiente, mientras aún aprovechamos la facilidad de despliegue de los componentes adicionales de Confluent.

Schema Registry y KsqlDB

Ya que Strimzi no proporciona un Schema Registry nativo en su conjunto de funcionalidades es necesario optar por una herramienta externa.

No hablaremos sobre Avro o Protobuf aquí, solamente una herramienta que te posibilita registrar tus schemas para serializar y deserializar mensajes.

Si planeas usar el Schema Registry de Confluent internamente en tu empresa, sin ofrecer servicios que compiten con los productos SaaS de Confluent, entonces puedes usar estas herramientas sin pagar por una licencia.

Sin embargo, es importante notar que si necesitas funcionalidades avanzadas del Schema Registry, como seguridad o validación de esquemas, estas pueden exigir una licencia Confluent Enterprise. Pero para uso interno básico, el Schema Registry de Confluent puede ser utilizado sin costos adicionales. Lo mismo vale para KsqlDB (antiguo Ksql).

En otro momento me gustaría hablar más sobre schema registry y explorar otras alternativas, como por ejemplo Apicurio que aparentemente hasta ahora es el único schema registry en la CNCF. Como dije anteriormente, si el cluster Kafka crece demasiado al punto de valer la pena una migración a Confluent Cloud ya estaremos usando herramientas desarrolladas por ellos.