Todos los que conocemos Kafka sabemos que es muy útil en el mundo de los flujos de datos y de los proyectos en tiempo real. Esto es gracias a su fiabilidad, baja latencia, capacidad de escalado y otras características que puedes ver en este post: ¿Dónde está el éxito de Kafka?
Pero, ¿alguna vez has pensado que Kafka puede ser un recurso más para tus productos, no sólo para tus proyectos?
Kafka como componente de productos
Me explico: las compañías de mayor éxito están construidas sobre productos, no sobre proyectos. Apple comenzó con un ordenador y ahora triunfa con un teléfono: productos. Microsoft con MS-DOS, Windows y la nube Azure. Coca-Cola con una bebida.
¿Quién puede decir que ha tenido el mismo éxito vendiendo proyectos?
Las compañías más exitosas de Fortune 500 son Walmart, Exxon Mobil, Berkshire, Apple y United Health group. Sólo la tercera y la quinta están dedicadas a los servicios. Ninguna del top 10 son empresas de desarrollo de software o consultoría.
Lo mismo le podría ocurrir a Kafka: en vez de usarse sólo para proyectos hemos visto una aproximación gradual al uso de Kafka como un componente. Como si fuera una base de datos o un servicio de seguridad.
Tres ejemplos de diferentes mundos
En la gestión de procesos: Appian BPM
Appian BPM es una solución de Business Process Management (BPM). Se puede usar en infraestructura tradicional o en la cloud de Appian. Un BPM es una herramienta en la que se puede modelar un proceso de negocio. Por ejemplo, venderle una tarjeta de crédito a un cliente. Este proceso de negocio incluye todos los pasos que involucren clientes, empleados y los sistemas requeridos para integrar y completar el proceso de venta de principio a fin. Este diseño es gráfico, multinivel (procesos y sub procesos), paralelo y con diferentes ramas. Algunos son muy complejos. Pueden evolucionar en el tiempo y algunas partes pueden ser a medida cada vez que se usa.
¿Qué tiene que ver esto con Kafka?
Appian usa Kafka para gestionar la mensajería interna de sus componentes. Esto significa que todas las acciones del Sistema serán enviadas y distribuidas por Kafka. Fiabilidad, velocidad, tolerancia a fallos y capacidad. Así, simplifica los problemas de comunicación entre componentes: menos puertos, menos protocolos, de nuevo K.I.S.S. 😉
Además, aunque Appian no ha hecho público el formato interno de los mensajes a los desarrolladores, es bastante obvio que este flujo de mensajes es la fuente de información ideal para KPIs.
¡Blockchain rescatado!
Hyperledger Fabric (HF) es uno de los sabores de Blockchain. Blockchain se ha hecho famoso en los últimos años por el alto precio y la especulación del Bitcoin. Además de por algunas noticias sobre el robo de electricidad para el minado de criptomonedas. Aham! Esto se pone interesante, antes de seguir: ¿sabes cuál es el origen real de Bitcoin y Blockchain?
Sí, pero… Blockchain va de criptomonedas, eso es tan solo la recompensa por computo realizado para las redes de Blockchain. El beneficio real del Blockchain es la capacidad de intercambio de dinero, bienes, información, ejecutar contratos y mucho más sin la necesidad de confiar en una autoridad central. En su lugar, una red Blockchain funciona como una gran cantidad de entidades en la que la confianza dice que la verdad es lo que dice la mayoría, por lo que cuanto más grande es la red más difícil es engañar a la red. Nota: esto es cierto para algunos tipos de redes de Blockchain, otros algoritmos de consenso funcionan de otros modos.
Volvamos a Kafka, ¿qué hace en este Sistema?
HF tiene un componente: el servicio Orderer usa Kafka para asegurar que todas las transacciones se han ejecutado en orden, porque cada cambio debe tenerse en cuenta para subsiguientes transacciones.
Es muy crítico porque la parte “chain” de Blockchain significa literalmente encadenar, es decir que cada transacción está conectada a la anterior. HF usa un tópico de Kafka por canal. Este es un concepto de Hyperledger, que relaciona todas las transacciones dentro de un grupo de actores y por tanto esas deben estar ordenadas entre ellas. Así, tendrá una única partición con un mínimo de cuatro réplicas. Las réplicas permiten que el sistema tenga un broker (de Kafka, es decir Orderer) caído y el sistema aún trabaje con sincronización. Una única partición garantiza el orden, independientemente del número de brokers/orderers en la red.
¿Obvio? No todo es lo que parece
IBM CDC/ Data Replication es un caso típico de flujo de datos, conocido como sistema de Change Data Capture (CDC), aunque hay otros similares: Attunity, AB Initio, etc.
Los productos de CDC funcionan escuchando los cambios en un sistema (típicamente una base de datos) y entonces transfieren los cambios a otros sistemas (otras bases de datos, HDFS, sistemas de ficheros, etc). Las tecnologías subyacentes son varias pero en los últimos años es bastante común almacenar en Kafka o usarlo como buffer.
Esto permite exprimir las capacidades de Kafka:
- Orden en los datos/mensajes si se usa una única partición como Hyperledger Fabric. No es obligatorio, algunos CDCs avanzados usan otras técnicas para mantener el orden, incluso en tópicos con varias particiones
- Alta capacidad
- Múltiples consumidores permiten distribución de información sencilla y barata a varios destinos
- El almacenamiento barato y el reprocesamiento permite su uso como fuente permanente de información (event sourcing)
- Alto rendimiento
- Múltiples brokers y múltiples topics pueden ayudar con múltiples fuentes/destinos
- Además, las ACL controlarán quién ve qué en entornos multi usuario
Soluciones que usan Kafka vs Nats
Hay una gran cantidad de productos y soluciones usando Kafka, ¿por qué no la tuya?
Y ya puestos a preguntar: ¿por qué Kafka? ¿No sería razonable usar alguna alternativa como Nats? ¿Cómo se compararía Nats con Kafka?
La respuesta es sencilla: Kafka tiene «más solera», más conocimiento, más reconocimiento. Al comenzar un proyecto de desarrollo suele haber dos maneras de hacer las cosas: una “usemos lo mejor, lo más moderno, lo más chulo, lo que cubre exactamente nuestras necesidades”. La otra es “usemos el producto con solera, conocido y certificado”. A la hora de crear un producto usando tecnologías de terceros se suele elegir siempre la segunda opción. Normalmente porque al final el producto ofrece soporte, algo que se vende junto con la licencia. Y cuanto mejor sea el producto y sus componentes, menos trabajo tendrá el equipo de soporte.
Hablamos de soporte, y Kafka gana
En este caso Kafka gana a Nats. Kafka va por la versión 2.2 y tiene ya 8 años. Es un software maduro que cuenta con soporte comercial por parte de varias compañías. Nats puede ser más ligero o incluso más rápido pero le falta la presencia e imagen que tiene Kafka y eso cuenta, por la buena reputación del producto y la tranquilidad de los equipos de soporte 😉
Juan Tavira
Universia
Especialista, arquitecto y friki multidisciplinar apasionado de todas las innovaciones. Esto es fácil de decir por uno mismo, pero cuando lo dicen mis compañeros informáticos, mis amigos geeks de los juegos e incluso mi mujer, algo de verdad tendrá ;-). Me gusta construir violines como hobby. En ocasiones veo código.
