Flogo es la próxima novedad en el desarrollo de aplicaciones de manera nativa en la nube. Desde su fundación ha sido diseñado para cubrir todos los nuevos desafíos que necesitamos enfrentar al tratar con el nuevo desarrollo nativo en la nube. Así que, por favor, si tú o tu empresa están comenzando su movimiento hacia la nube, es el momento de echar un vistazo a lo que Flogo ofrece. Flogo es un Marco de Desarrollo de Aplicaciones de Código Abierto basado en los principios que se discutirán en las próximas sesiones.
Huella de memoria mínima
En el auge de la realidad del IoT, cuando necesitaremos que todos los dispositivos en nuestro entorno tengan capacidades de cómputo e integración, y también cuando la opción de optimizar costos en tu infraestructura en la nube es necesaria, necesitas hacer un uso óptimo de los recursos por los que estás pagando. Una disminución del 10-20% de la huella de memoria de tu servicio puede permitirte proporcionar el mismo rendimiento con tipos de máquinas más pequeñas con los ahorros que esto genera para toda la empresa. Flogo está basado en el lenguaje de programación Go y eso hace que el ejecutable binario que genera solo tenga los componentes exactos que necesitas para ejecutar tu lógica y nada más. Así que, no necesitas una capa intermedia con una máquina virtual, como un motor Javascript V8 para ejecutar tu aplicación de nodo o una JVM para ejecutar tus servicios Spring Boot, etc. No, solo tendrás en tu ejecutable las bibliotecas exactas que necesitas y eso genera mejoras impresionantes en la huella de memoria que podrías tener en tus desarrollos con Flogo. Ok, pero esto es demasiado genérico, así que déjame hacerlo más real para que puedas entender exactamente de qué estoy hablando: Bastante asombroso, ¿verdad? Pero podrías pensar… si puedes mantener todas las capacidades e integraciones que necesitas para poder usarlo en el trabajo real. Ok, esperemos hasta que discutamos todos los temas y puedas tener una opinión general al respecto.
Sabores de cero código y todo código
En TIBCO, el cero código ha sido nuestro buque insignia durante décadas para hacer posible que personas no técnicas construyan servicios óptimos e integren tecnologías sin la necesidad de manejar todos los detalles de esta integración. Si estás al tanto de nuestros productos de integración como TIBCO BusinessWorks o BusinessWorks Container Edition, el diseñador gráfico ha sido la principal forma en que toda la lógica del cliente se implementa de una manera fácil, más resiliente y más mantenible. Esto todavía existe en nuestra tecnología Flogo con el Web Studio que Flogo proporciona, tendrás una manera fácil de construir tus flujos como puedes ver aquí: Así que, podrás continuar usando nuestro enfoque de cero código con todos los ajustes, opciones y paletas necesarias para hacer toda tu lógica de una manera más mantenible. Pero hoy esto no es suficiente, así que incluso cuando todavía puedes hacerlo de esta manera que es la mejor opción para la mayoría de los clientes, todavía puedes confiar en tus programadores y desarrolladores para construir tus servicios, porque Flogo también permite construir tus servicios de una manera de todo código con desarrollo en Go-lang. Así que, tendrás la opción de abrir el IDE de tu elección y comenzar a codificar actividades de Flogo usando go-lang, como puedes ver en la imagen a continuación:
Listo para serverless
Puedes ejecutar tus aplicaciones de muchas maneras diferentes, puedes hacerlo en las instalaciones muy cerca del metal desnudo, generando aplicaciones compiladas para todos los sistemas operativos: Windows, MacOS y Linux (también para arquitectura ARM). O puedes ejecutarlo en una versión de contenedor generando una imagen de Docker con tus servicios para que puedas usarlo con cualquier sistema PaaS listo para producción que tengas o planees tener en tu empresa (Kubernetes, Openshift, Swarm, Mesos…) Pero, todavía puedes ejecutarlo en AWS Lambda si deseas adoptar un enfoque completamente serverless. Así que, este es un verdadero diseño de uno, ejecuta en todas partes, pero adaptado a las necesidades de hoy. Imagina eso, puedes tener el mismo servicio ejecutándose en un Raspberry Pi, un Windows Server 2018 y también una función AWS Lambda sin cambiar una línea de código o actividad en tu lienzo. ¿Qué tan genial es esto? Pero eso no es todo, ¿qué pasa si no quieres gestionar toda la infraestructura para tu nube y tampoco quieres manejar todo el asunto de lambda con Amazon? Ok, todavía tienes otra opción y es usar TIBCO Cloud Integration que se encargará de todo por ti y solo necesitas subir tu código de una manera fácil. También tienes diferentes sabores de Flogo, puedes mantenerlo en la opción de código abierto o puedes actualizar a la opción Enterprise, que te proporcionará acceso al soporte de TIBCO para plantear casos que te ayuden con tus desarrollos y también acceso anticipado a algunas nuevas características que se agregan a la plataforma de manera regular.
Integración de Código Abierto
Incluso cuando todas las opciones que tenemos en el enfoque de bloqueo de proveedor con soluciones como Logic Apps para Azure o incluso los AWS Workflows, algo que define las nuevas tecnologías que están liderando el camino en el movimiento nativo en la nube son las tecnologías de código abierto. Todo Flogo admite la mayoría de ellas de manera fluida en diferentes niveles:
Integración para tus flujos
Si estás familiarizado con TIBCO BusinessWorks, conoces nuestro concepto de «paleta», pero para aquellos que no están familiarizados con nuestro enfoque de desarrollador de cero código, permíteme explicarlo un poco mejor. Usualmente tenemos una actividad para cada una de las acciones que podrías hacer en tu flujo. Eso podría ser desde invocar un servicio REST o escribir un registro de seguimiento. Cada una de las actividades tiene su propio ícono para que puedas identificar fácilmente cuando lo ves en el flujo o cuando deseas seleccionar la actividad que quieres agregar al lienzo. Y el grupo de actividades que están relacionadas con el mismo ámbito, como por ejemplo integrar con Lambda, genera lo que se llama una Paleta que es solo un conjunto de actividades. Así que, proporcionamos muchas paletas que están listas para usar, el número de las que están disponibles para ti depende del sabor de Flogo que estés usando, que podría ser Flogo Open Source, Flogo Enterprise y Flogo ejecutándose en TCI, pero puedes encontrar al menos conexión a los siguientes servicios (esta no es una lista completa, solo para nombrar algunos). También muchos servicios para gestionar todos tus recursos de AWS, como los que se muestran en la tabla a continuación: Como puedes ver, hay una gran cantidad de opciones de integración que tienes para ser productivo desde el principio, pero, ¿qué pasa si necesitas conectarte a otro sistema? Ok, primero necesitamos buscar si alguien ha hecho esto, y podemos usar GitHub para buscar muchas nuevas paletas y puedes ver muchos repositorios diferentes con más actividades que puedes instalar en tu propio entorno. Solo para nombrar algunos:
Monitoreo de Aplicaciones Flogo Enterprise ahora proporciona soporte para Prometheus, un proyecto de código abierto bajo la Cloud Native Computing Foundation (CNCF). Esto te da la capacidad de configurar Prometheus para extraer y almacenar métricas de aplicaciones Flogo, usar características de Prometheus para monitoreo así como alertas, y también usar herramientas como Grafana para visualización. Además, estas APIs de métricas pueden usarse para integrarse con otras herramientas de terceros.
Service Mesh es una de las «nuevas grandes cosas» en nuestros entornos PaaS. No importa si estás trabajando con K8S, Docker Swarm, nube pura con EKS o AWS, has oído hablar y probablemente intentado saber cómo se puede usar esta nueva cosa que tiene tantas ventajas porque proporciona muchas opciones para manejar la comunicación entre componentes sin afectar la lógica de los componentes. Y si has oído hablar de Service Mesh, también has oído hablar de Istio, porque esta es la «opción insignia» en este momento, incluso cuando otras opciones como Linkerd o AWS App Mesh también son una gran opción, Istio es el Service Mesh más utilizado en este momento.
Probablemente hayas visto algunos ejemplos sobre cómo integrar Istio con tus desarrollos basados en código abierto, pero ¿qué pasa si tienes muchas aplicaciones BWCE o BusinessWorks… ¿puedes usar todo este poder? ¿O vas a ser excluido de este nuevo mundo?
¡No entres en pánico! Este artículo te va a mostrar lo fácil que puedes usar Istio con tu aplicación BWCE dentro de un clúster K8S. Así que, que comience el partido… ¡EMPIEZA!
Escenario
El escenario que vamos a probar es bastante simple. Es un enfoque simple de consumidor-proveedor. Vamos a usar un simple servicio web SOAP/HTTP expuesto por un backend para mostrar que esto puede funcionar no solo con API REST elegantes, sino incluso con cualquier tráfico HTTP que podamos generar a nivel de la aplicación BWCE.
Así que, vamos a invocar un servicio que va a solicitar una respuesta de su proveedor y nos dará la respuesta. Eso es bastante fácil de configurar usando BWCE puro sin nada más.
Todo el código relacionado con este ejemplo está disponible para ti en el siguiente repositorio de GitHub: ¡Ve a buscar el código!
Pasos
Paso 1 Instalar Istio dentro de tu Clúster de Kubernetes
En mi caso, estoy usando un clúster de Kubernetes dentro de mi instalación de Docker Desktop, así que puedes hacer lo mismo o usar tu clúster de Kubernetes real, eso depende de ti. El primer paso de todos modos es instalar istio. Y para hacer eso, nada mejor que seguir los pasos dados en el taller de istio que puedes encontrar aquí: https://polarsquad.github.io/istio-workshop/install-istio/ (ACTUALIZACIÓN: Ya no disponible)
Una vez que hayas terminado, vamos a obtener el siguiente escenario en nuestro clúster de kubernetes, así que por favor, verifica que el resultado sea el mismo con los siguientes comandos:
kubectl get pods -n istio-system
Deberías ver que todos los pods están en ejecución como puedes ver en la imagen a continuación:
kubectl -n istio-system get deployment -listio=sidecar-injector
Deberías ver que hay una instancia (CURRENT = 1) disponible.
kubectl get namespace -L istio-injection
Deberías ver que ISTIO-INJECTION está habilitado para el espacio de nombres predeterminado como se muestra en la imagen a continuación:
Paso 2 Construir Aplicaciones BWCE
Ahora, como tenemos toda la infraestructura necesaria a nivel de Istio, podemos comenzar a construir nuestra aplicación y para hacer eso no tenemos que hacer nada diferente en nuestra aplicación BWCE. Eventualmente, van a ser dos aplicaciones que se comunican usando HTTP como protocolo, así que nada específico.
Esto es algo importante porque cuando usualmente hablamos de Service Mesh e Istio con clientes, siempre surge la misma pregunta: ¿Es compatible Istio en BWCE? ¿Podemos usar Istio como un protocolo para comunicar nuestra aplicación BWCE? Así que, esperan que debería existir alguna paleta o algún complemento personalizado que deberían instalar para soportar Istio. Pero nada de eso es necesario a nivel de aplicación. Y eso se aplica no solo a BWCE sino también a cualquier otra tecnología como Flogo o incluso tecnologías de código abierto porque al final Istio (y Envoy es la otra parte necesaria en esta tecnología de la que usualmente evitamos hablar cuando hablamos de Istio) funciona en modo Proxy usando uno de los patrones más usuales en contenedores que es el «patrón sidecar«.
Así que, la tecnología que está exponiendo e implementando o consumiendo el servicio no sabe nada sobre toda esta «magia» que se está ejecutando en el medio de este proceso de comunicación.
Vamos a definir las siguientes propiedades como variables de entorno como lo haríamos en caso de que no estuviéramos usando Istio:
Aplicación del proveedor:
PROVIDER_PORT → Puerto donde el proveedor va a escuchar las solicitudes entrantes.
Aplicación del consumidor:
PROVIDER_PORT → Puerto donde el host del proveedor estará escuchando.
PROVIDER_HOST → Host o FQDN (también conocido como nombre del servicio K8S) donde se expondrá el servicio del proveedor.
CONSUMER_PORT → Puerto donde el servicio del consumidor va a escuchar las solicitudes entrantes.
Así que, como puedes ver si verificas que el código de la aplicación BWCE no necesitamos hacer nada especial para soportar Istio en nuestras aplicaciones BWCE.
NOTA: Solo hay un tema importante que no está relacionado con la integración de Istio, sino con cómo BWCE llena la propiedad BW.CLOUD.HOST que nunca se traduce a la interfaz de loopback o incluso 0.0.0.0. Así que es mejor que cambies esa variable por una personalizada o que uses localhost o 0.0.0.0 para escuchar en la interfaz de loopback porque es donde el proxy de Istio va a enviar las solicitudes.
Después de eso, vamos a crear nuestros Dockerfiles para estos servicios sin nada en particular, algo similar a lo que puedes ver aquí:
NOTA: Como requisito previo, estamos usando la imagen base de Docker de BWCE llamada bwce_base.2.4.3 que corresponde a la versión 2.4.3 de BusinessWorks Container Edition.
Y ahora construimos nuestras imágenes de docker en nuestro repositorio como puedes ver en la siguiente imagen:
Paso 3: Desplegar las Aplicaciones BWCE
Ahora, cuando todas las imágenes están siendo creadas, necesitamos generar los artefactos necesarios para desplegar estas aplicaciones en nuestro Clúster. Una vez más, en este caso, nada especial tampoco en nuestro archivo YAML, como puedes ver en la imagen a continuación, vamos a definir un servicio K8S y un despliegue K8S basado en la imagen que hemos creado en el paso anterior:
Algo similar sucede con el despliegue del consumidor, como puedes ver en la imagen a continuación:
Y podemos desplegarlos en nuestro clúster K8S con los siguientes comandos:
kubectl apply -f kube/provider.yaml
kubectl apply -f kube/consumer.yaml
Ahora, deberías ver los siguientes componentes desplegados. Solo para completar todos los componentes necesarios en nuestra estructura, vamos a crear un ingreso para hacer posible ejecutar solicitudes desde fuera del clúster a esos componentes y para hacer eso vamos a usar el siguiente archivo yaml:
kubectl apply -f kube/ingress.yaml
Y ahora, después de hacer eso, vamos a invocar el servicio dentro de nuestro proyecto SOAPUI y deberíamos obtener la siguiente respuesta:
Paso 4 — Recapitular lo que acabamos de hacer
Ok, está funcionando y piensas… mmmm puedo hacer que esto funcione sin Istio y no sé si Istio todavía está haciendo algo o no…
Ok, tienes razón, esto podría no ser tan genial como esperabas, pero, créeme, solo estamos yendo paso a paso… Veamos qué está realmente sucediendo en lugar de una simple solicitud desde fuera del clúster al servicio del consumidor y esa solicitud siendo reenviada al backend, lo que está sucediendo es un poco más complejo. Echemos un vistazo a la imagen a continuación:
La solicitud entrante desde el exterior está siendo manejada por un Controlador de Ingreso Envoy que va a ejecutar todas las reglas definidas para elegir qué servicio debe manejar la solicitud, en nuestro caso el único componente consumer-v1 lo va a hacer, y lo mismo sucede en la comunicación entre consumidor y proveedor.
Así que, estamos obteniendo algunos interceptores en el medio que PODRÍAN aplicar la lógica que nos va a ayudar a enrutar el tráfico entre nuestros componentes con el despliegue de reglas a nivel de tiempo de ejecución sin cambiar la aplicación, y esa es la MAGIA.
Paso 5 — Implementar Lanzamiento Canary
Ok, ahora apliquemos algo de esta magia a nuestro caso. Uno de los patrones más usuales que solemos aplicar cuando estamos implementando una actualización en algunos de nuestros servicios es el enfoque canary. Solo para hacer una explicación rápida de lo que es esto:
El lanzamiento canary es una técnica para reducir el riesgo de introducir una nueva versión de software en producción al implementar lentamente el cambio a un pequeño subconjunto de usuarios antes de implementarlo en toda la infraestructura y hacerlo disponible para todos.
Si quieres leer más sobre esto, puedes echar un vistazo al artículo completo en el blog de Martin Fowler.
Así que, ahora vamos a generar un pequeño cambio en nuestra aplicación del proveedor, que va a cambiar la respuesta para asegurarnos de que estamos apuntando a la versión dos, como puedes ver en la imagen a continuación:
Ahora, vamos a construir esta aplicación y generar la nueva imagen llamada provider:v2.
Pero antes vamos a desplegarla usando el archivo YAML llamado provider-v2.yaml, vamos a establecer una regla en nuestro Service Mesh de Istio de que todo el tráfico debe dirigirse a v1 incluso cuando otros se apliquen. Para hacer eso, vamos a desplegar el archivo llamado default.yaml que tiene el siguiente contenido:
Así que, en este caso, lo que le estamos diciendo a Istio es que incluso si hay otros componentes registrados en el servicio, siempre debe responder el v1, por lo que ahora podemos desplegar el v2 sin ningún problema porque no va a responder a ningún tráfico hasta que decidamos hacerlo. Así que, ahora podemos desplegar el v2 con el siguiente comando:
kubectl apply -f provider-v2.yaml
Y aunque ejecutemos la solicitud SOAPUI, todavía estamos obteniendo una respuesta v1 incluso si verificamos en la configuración del servicio K8S que el v2 todavía está vinculado a ese servicio.
Ok, ahora vamos a comenzar a hacer el lanzamiento y vamos a comenzar con el 10% a la nueva versión y el 90% de las solicitudes a la antigua, y para hacer eso vamos a desplegar la regla canary.yaml usando el siguiente comando:
kubectl apply -f canary.yaml
Donde canary.yaml tiene el contenido que se muestra a continuación:
Y ahora, cuando intentemos suficientes veces, vamos a obtener que la mayoría de las solicitudes (aproximadamente el 90%) van a responder v1 y solo el 10% va a responder desde mi nueva versión:
Ahora, podemos monitorear cómo está funcionando v2 sin afectar a todos los clientes y si todo va como se espera, podemos continuar aumentando ese porcentaje hasta que todos los clientes estén siendo respondidos por v2.
Si estás familiarizado con el mundo de la Integración Empresarial, seguro que conoces Kafka, uno de los proyectos más famosos de la Fundación Apache en los últimos años, y también si estás en el mundo de la Integración conoces TIBCO Software, y algunos de nuestros productos insignia como TIBCO ActiveMatrix BusinessWorks para integración, TIBCO Cloud Integration como nuestro iPaaS, TIBCO AMX BPM, TIBCO BusinessEvents… y podría continuar esa lista una y otra vez.. 🙂
Pero, probablemente no sepas sobre TIBCO(R) Messaging — Apache Kafka Distribution. Esta es una de las partes de nuestra solución de mensajería global llamada TIBCO Messaging y está compuesta por varios componentes:
TIBCO Enterprise Message Service (también conocido como TIBCO EMS) es nuestro servidor compatible con JMS 2.0, uno de nuestros estándares de mensajería durante más de una década.
TIBCO FTL es nuestra solución de mensajería lista para la nube, utilizando un sistema de comunicación pub-sub directo, no centralizado y muy eficiente.
TIBCO(R) Messaging — Apache Kafka Distribution está diseñado para la distribución eficiente de datos y el procesamiento de flujos con la capacidad de conectar aplicaciones Kafka a otras aplicaciones de TIBCO Messaging impulsadas por TIBCO FTL(R), TIBCO eFTL(TM) o TIBCO Enterprise Message Service(TM).
TIBCO(R) Messaging — Eclipse Mosquitto Distribution incluye un broker MQTT ligero y una biblioteca C para el cliente MQTT en el paquete Core y un componente para conectar clientes MQTT a aplicaciones TIBCO FTL en el paquete Bridge.
Me gustaría hacer esta publicación completamente técnica, pero voy a dejar un poco de información sobre la versión del producto que podrías encontrar interesante, porque tenemos una Edición Comunitaria de toda esta solución de Mensajería que podrías usar tú mismo.
El software TIBCO Messaging está disponible en una edición comunitaria y una edición empresarial.
TIBCO Messaging — Community Edition es ideal para comenzar con TIBCO Messaging, para implementar proyectos de aplicaciones (incluidos esfuerzos de prueba de concepto) para pruebas, y para desplegar aplicaciones en un entorno de producción. Aunque la licencia comunitaria limita el número de procesos de producción, puedes actualizar fácilmente a la edición empresarial a medida que tu uso de TIBCO Messaging se expande. La edición comunitaria está disponible de forma gratuita, con las siguientes limitaciones y exclusiones:
● Los usuarios pueden ejecutar hasta 100 instancias de aplicaciones o 1000 instancias web/móviles en un entorno de producción.
● Los usuarios no tienen acceso al soporte de TIBCO, pero pueden usar TIBCO Community como recurso (http://community.tibco.com).
TIBCO Messaging — Enterprise Edition es ideal para todos los proyectos de desarrollo de aplicaciones, y para desplegar y gestionar aplicaciones en un entorno de producción empresarial. Incluye todas las características presentadas en este conjunto de documentación, así como acceso al soporte de TIBCO.
Puedes leer esa información aquí, pero, por favor, tómate tu tiempo también para leer nuestro anuncio oficial que puedes encontrar aquí.
Así que, este va a ser el primero de algunos posts sobre cómo integrar Kafka en el ecosistema habitual de TIBCO y diferentes tecnologías. Esta serie va a asumir que ya conoces Apache Kafka, y si no lo haces, por favor, echa un vistazo a la siguiente referencia antes de continuar:
Así que, ahora vamos a comenzar instalando esta distribución en nuestra máquina, en mi caso voy a usar un objetivo basado en UNIX, pero tienes este software disponible para MacOS X, Windows o cualquier sistema operativo que estés usando.
El proceso de instalación es bastante simple porque la distribución se basa en las distribuciones de Linux más habituales, por lo que te proporciona un paquete deb, un paquete rpm o incluso un paquete tar para que puedas usar lo que necesites para tu distribución actual. En mi caso, como estoy usando CentOS, he optado por el paquete rpm y todo va muy bien.
Y después de eso, he instalado en mi carpeta /opt/tibco una distribución de Kafka bastante usual, así que para iniciarla necesitamos iniciar primero el servidor zookeeper y luego el servidor kafka en sí. Y eso es todo. ¡¡Todo está funcionando!!
Distribución de Apache Kafka en funcionamiento
Mmmm.. Pero, ¿cómo puedo estar seguro de ello? Kafka no proporciona una GUI para monitorear o supervisarlo, pero hay un montón de herramientas por ahí para hacerlo. En mi caso voy a usar Kafka Tool porque no necesita otros componentes como Kafka REST y demás, pero ten en cuenta que hay otras opciones con una interfaz de usuario más «bonita», pero esta va a hacer el trabajo perfectamente.
Así que, después de instalar Kafka Tool, solo proporcionamos los datos de dónde está escuchando zookeeper (si mantienes todo por defecto, va a estar escuchando en el 2181) y la versión de Kafka que estamos usando (en este caso es la 1.1), y ahora puedes estar seguro de que todo está en funcionamiento y trabajando como se espera:
Kafka Tool podría usarse para monitorear tus brokers de Kafka
Así que, ahora vamos a hacer solo una prueba rápida usando nuestro producto de integración insignia TIBCO AMX BusinessWorks que tiene un complemento de Kafka, para que puedas comunicarte con este nuevo servidor que acabamos de lanzar. Esto va a ser solo un Hola Mundo con la siguiente estructura:
El Proceso A va a enviar un ¡Hola! al Proceso B.
El Proceso B va a recibir ese mensaje y lo imprimirá en un registro.
Los procesos se van a desarrollar de la siguiente manera:
Proceso de Prueba del Remitente de KafkaProceso de Prueba del Receptor de Kafka
Y este es el resultado que obtenemos después de ejecutar ambos procesos:
Ejecución correcta usando TIBCO Business Studio
Y podemos ver que el tema de ejemplo que usamos para hacer la comunicación y la partición predeterminada se ha creado por defecto usando Kafka Tool:
El tema se ha creado bajo demanda
Como puedes ver, es muy fácil y directo tener todo configurado de manera predeterminada. Después de eso, continuamos profundizando en este nuevo componente en el mundo de TIBCO.
