Estamos viviendo en una era donde las tecnologías están cambiando estándares todo el tiempo. Olvidas leer Medium/Stackoverflow/Reddit y descubres que hay al menos cinco (5) nuevos estándares de la industria que están reemplazando a los existentes que conoces (aquellos que han sido lanzados hace algo así como un año 🙂 ).
¿Todavía recuerdas los viejos tiempos cuando SOAP era el formato imbatible? ¿Cuánto tiempo pasamos construyendo nuestros Servicios SOAP en nuestras empresas? REST lo reemplazó como el nuevo estándar… pero solo unos pocos años y estamos de vuelta en una nueva batalla solo por la comunicación sincrónica: gRPC, GraphQL, están aquí para conquistar todo de nuevo. Es una locura, ¿eh?
Pero la situación es similar para la comunicación asincrónica. La comunicación asincrónica ha estado aquí por mucho tiempo. Incluso, mucho antes de que los términos Arquitectura Orientada a Eventos o Streaming fueran realmente un término “cool” o algo de lo que estuvieras al tanto.
Hemos estado usando estos patrones durante tanto tiempo en nuestras empresas. Las grandes empresas han estado usando este modelo en sus integraciones empresariales durante mucho tiempo. Protocolos y tecnologías basados en Pub/Sub como TIBCO Rendezvous se han estado usando desde finales de los 90, y luego también incorporamos enfoques más estándar como JMS usando diferentes tipos de servidores para tener todas estas comunicaciones basadas en eventos.
Pero ahora con la revolución nativa de la nube, la necesidad de computación distribuida, más agilidad, más escalabilidad, las soluciones centralizadas ya no son válidas, y hemos visto una explosión en el número de opciones para comunicarse basadas en estos patrones.
Podrías pensar que esta es la misma situación que estábamos discutiendo al principio de este artículo con respecto a la predominancia de REST y las nuevas tecnologías de vanguardia tratando de reemplazarlo, pero esto es algo bastante diferente. Porque la experiencia nos ha dicho que una sola talla no sirve para todos.
No puedes encontrar una sola tecnología o componente que pueda proporcionar todas las necesidades de comunicación que necesitas para todos tus casos de uso. Puedes nombrar cualquier tecnología o protocolo que desees: Kafka, Pulsar, JMS, MQTT, AMQP, Thrift, FTL, y así sucesivamente.
Piense en cada uno de ellos y probablemente encontrará algunos casos de uso en los que una tecnología funciona mejor que las otras, por lo que no tiene sentido tratar de encontrar una solución tecnológica única para cubrir todas las necesidades. Lo que se necesita es más un enfoque políglota cuando tienes diferentes tecnologías que funcionan bien juntas y usas la que mejor funciona para tu caso de uso (el enfoque de la herramienta adecuada para el trabajo adecuado) como estamos haciendo para las diferentes tecnologías que estamos desplegando en nuestro clúster.
Probablemente no vamos a usar la misma tecnología para hacer un Microservicio basado en Aprendizaje Automático, que una Aplicación de Streaming, ¿verdad? El mismo principio se aplica aquí.
Pero el problema aquí cuando intentamos hablar sobre diferentes tecnologías trabajando juntas es sobre la estandarización. Si pensamos en REST, gRPC o GraphQL, aunque son diferentes, juegan basados en algunos fundamentos comunes. Se basan en el mismo protocolo HTTP para un estándar, por lo que es fácil soportar todos ellos en la misma arquitectura.
Pero esto no es cierto con las tecnologías sobre Comunicación Asincrónica. Y me gustaría centrarme en la estandarización y especificación hoy. Y eso es lo que la Iniciativa AsyncAPI está tratando de resolver. Y para definir qué es AsyncAPI me gustaría usar sus propias palabras de su sitio web oficial:
AsyncAPI es una iniciativa de código abierto que busca mejorar el estado actual de las Arquitecturas Orientadas a Eventos (EDA). Nuestro objetivo a largo plazo es hacer que trabajar con EDA sea tan fácil como trabajar con APIs REST. Eso va desde la documentación hasta la generación de código, desde el descubrimiento hasta la gestión de eventos. La mayoría de los procesos que aplicas a tus APIs REST hoy en día también serían aplicables a tus APIs orientadas a eventos/asincrónicas.
Entonces, su objetivo es proporcionar un conjunto de herramientas para tener un mundo mejor en todas esas arquitecturas EDA que todas las empresas tienen o están comenzando a tener en este momento y todo gira en torno a una cosa: La Especificación OpenAPI.
Similar a la especificación OpenAPI, nos permite definir una interfaz común para nuestras Interfaces EDA y la parte más importante es que esto es multicanal. Así que la misma especificación puede ser utilizada para tu API basada en MQTT o tu API de Kafka. Veamos cómo se ve esta Especificación AsyncAPI:
Como puedes ver, es muy similar a OpenAPI 3.0 y ya lo han hecho con el propósito de facilitar la transición entre OpenAPI 3.0 y AsyncAPI y también para tratar de unir ambos mundos: Se trata más de solo API, no importa si son sincrónicas o asincrónicas y proporcionar los mismos beneficios con respecto al ecosistema de una a otra.
¡Muéstrame el código!
Pero dejemos de hablar y comencemos a codificar y para hacer eso me gustaría usar una de las herramientas que en mi opinión tiene el mayor soporte para AsyncAPI, y eso es Project Flogo.
Probablemente recuerdes algunas de las diferentes publicaciones que he hecho con respecto a Project Flogo y TIBCO Flogo Enterprise como una gran tecnología para usar en el desarrollo de tus microservicios (enfoque de bajo código/todo código, basado en Golang, muchos conectores y extensiones de código abierto también).
Pero hoy vamos a usarlo para crear nuestro primer microservicio compatible con AsyncAPI. Y vamos a confiar en eso porque proporciona un conjunto de extensiones para apoyar la iniciativa AsyncAPI como puedes ver aquí:
Así que lo primero que vamos a hacer es crear nuestra definición AsyncAPI y para hacerlo más simple, vamos a usar la muestra que tenemos disponible en el OpenAsync API con un simple cambio: Vamos a cambiar del protocolo AMQP al protocolo Kafka porque esto es genial en estos días, ¿no? 😉
asyncapi: '2.0.0'
info:
title: Aplicación Hola Mundo
version: '0.1.0'
servers:
production:
url: broker.mycompany.com
protocol: kafka
description: Este es el broker de "Mi Empresa".
security:
- user-password: []
channels:
hello:
publish:
message:
$ref: '#/components/messages/hello-msg'
goodbye:
publish:
message:
$ref: '#/components/messages/goodbye-msg'
components:
messages:
hello-msg:
payload:
type: object
properties:
name:
type: string
sentAt:
$ref: '#/components/schemas/sent-at'
goodbye-msg:
payload:
type: object
properties:
sentAt:
$ref: '#/components/schemas/sent-at'
schemas:
sent-at:
type: string
description: La fecha y hora en que se envió un mensaje.
format: datetime
securitySchemes:
user-password:
type: userPasswordComo puedes ver, algo simple. Dos operaciones “hello” y “goodbye” con carga útil sencilla:
- name: Nombre que vamos a usar para el saludo.
- sentAt: La fecha y hora en que se envió un mensaje.
Así que lo primero que vamos a hacer es crear una Aplicación Flogo que cumpla con esa especificación AsyncAPI:
git clone https://github.com/project-flogo/asyncapi.git cd asyncapi/ go install
Ahora tenemos el instalador del generador, así que solo necesitamos ejecutar y proporcionar nuestro YML como entrada en el siguiente comando:
asyncapi -input helloworld.yml -type flogodescriptor
Y crearemos una aplicación HelloWorld para nosotros, que necesitamos ajustar un poco. Solo para que puedas estar en funcionamiento rápidamente, solo estoy compartiendo el código en mi repositorio de GitHub que puedes tomar de allí (Pero realmente te animo a que te tomes el tiempo para echar un vistazo al código para ver la belleza del Desarrollo de Aplicaciones Flogo 🙂 )
https://github.com/project-flogo/asyncapi
Ahora, que ya tenemos la aplicación, tenemos solo una aplicación simple que nos permite recibir el mensaje que cumple con la especificación, y en nuestro caso solo registrar la carga útil, lo que puede ser nuestro punto de partida para construir nuestros nuevos Microservicios Orientados a Eventos compatibles con AsyncAPI.
Así que, probémoslo, pero para hacerlo, necesitamos algunas cosas. Primero que nada, necesitamos un servidor Kafka en funcionamiento y para hacerlo de manera rápida vamos a aprovechar el siguiente archivo docker-compose.yml:
version: '2'
services:
zookeeper:
image: wurstmeister/zookeeper:3.4.6
expose:
- "2181"
kafka:
image: wurstmeister/kafka:2.11-2.0.0
depends_on:
- zookeeper
ports:
- "9092:9092"
environment:
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181
Y para ejecutar eso solo necesitamos lanzar el siguiente comando desde la misma carpeta donde tenemos este archivo llamado docker-compose.yml:
docker-compose up -d
Y después de hacer eso, solo necesitamos una aplicación de muestra y qué mejor que usar Flogo nuevamente para crearla, pero esta vez, usemos el Visor Gráfico para crearla de inmediato:
Así que solo necesitamos configurar la actividad Publicar Kafka para proporcionar el broker (localhost:9092), el tema (hello) y el mensaje :
{
"name": "hola mundo",
"sentAt": "2020-04-24T00:00:00"
}
¡Y eso es todo! ¡Ejecutémoslo!:
Primero iniciamos el Microservicio Flogo AsyncAPI:
Y luego solo lanzamos el probador, que va a enviar el mismo mensaje cada minuto, como puedes ver en la imagen a continuación:
Y cada vez que enviamos ese mensaje, va a ser recibido en nuestro Microservicio Flogo AsyncAPI:
Así que, espero que esta primera introducción al mundo AsyncAPI haya sido de tu interés, pero no olvides echar un vistazo a más recursos en su propio sitio web:
