Alexandre Vazquez, Author At Alexandre Vazquez

Instalación de extensiones Flogo

2026-01-272019-05-27 por Alexandre Vazquez

En publicaciones anteriores, hemos hablado sobre las capacidades de Flogo y cómo construir nuestra primera aplicación Flogo, así que en este momento, si has leído ambos, tienes un conocimiento claro sobre lo que Flogo ofrece y lo fácil que es crear aplicaciones en Flogo.

Pero en esas capacidades, hemos hablado de que una de las fortalezas de Flogo es lo fácil que es extender las capacidades predeterminadas que Flogo ofrece. Las Extensiones de Flogo permiten aumentar las capacidades de integración del producto así como las capacidades de cómputo y se construyen usando Go. Puedes crear diferentes tipos de extensiones:

Disparadores: Mecanismo para activar un flujo de Flogo (generalmente conocidos como Iniciadores)
Actividades/Acciones: Lógica de implementación que puedes usar dentro de tus flujos de Flogo.

Existen diferentes tipos de extensiones dependiendo de cómo se proporcionan y el alcance que tienen.

Conectores Empresariales de TIBCO Flogo: Estos son los conectores proporcionados directamente por TIBCO Software para los clientes que están usando TIBCO Flogo Enterprise. Se lanzan usando TIBCO eDelivery como todos los demás productos y componentes de TIBCO.
Extensiones de Código Abierto de Flogo: Estas son las extensiones desarrolladas por la Comunidad y que generalmente se almacenan en repositorios de GitHub o cualquier otro sistema de control de versiones que esté públicamente disponible.
Extensiones Personalizadas de TIBCO Flogo Enterprise: Estas son las extensiones equivalentes a las Extensiones de Código Abierto de Flogo pero construidas para ser usadas en TIBCO Flogo Enterprise o TIBCO Cloud Integration (iPaaS de TIBCO) y que siguen los requisitos definidos por la Documentación de Flogo Enterprise y proporcionan un poco más de opciones de configuración sobre cómo se muestra esto en la interfaz de usuario.

Instalación usando la Interfaz Web de TIBCO

Vamos a cubrir en este artículo cómo trabajar con todos ellos en nuestro entorno y vas a ver que el procedimiento es prácticamente el mismo, pero la principal diferencia es cómo obtener el objeto desplegable.

Necesitamos instalar alguna extensión y para nuestro caso, vamos a usar ambos tipos de extensiones posibles: Un conector proporcionado por TIBCO para conectar a GitHub y una actividad de código abierto construida por la comunidad para gestionar las operaciones de archivos.

Primero, vamos a comenzar con el conector de GitHub y vamos a usar el Conector de Flogo para GitHub, que se va a descargar a través de TIBCO eDelivery como lo hiciste con Flogo Enterprise. Una vez que tengas el archivo ZIP, necesitas agregarlo a tu instalación y para hacer eso, vamos a ir a la página de Extensiones

Y vamos a hacer clic en Subir y proporcionar el archivo ZIP que hemos descargado con el conector de GitHub

Hacemos clic en el botón «Subir y compilar» y esperamos hasta que el proceso de compilación termine y después de eso, deberíamos notar que tenemos un disparador adicional disponible como puedes ver en la imagen a continuación:

Así que, ya tenemos nuestro disparador de GitHub, pero necesitamos nuestras actividades de Archivo y ahora vamos a hacer el mismo ejercicio pero con un conector diferente. En este caso, vamos a usar una actividad de código abierto que está alojada en el repositorio de GitHub de Leon Stigter. Y vamos a descargar el repositorio completo de flogo-components y subir ese archivo ZIP a la página de Extensiones como lo hicimos antes:

Vamos a extraer el repositorio completo e ir a la ruta de actividad y generar un archivo zip desde la carpeta llamada «writetofile» y ese es el archivo ZIP que vamos a subir a nuestra página de Extensiones:

La estructura del repositorio es prácticamente la misma para todos estos tipos de repositorios de código abierto, generalmente tienen el nombre flogo-components y dentro tienen dos carpetas principales:

actividad: Carpeta que agrupa todas las diferentes actividades que están disponibles en este repositorio.
disparador: Carpeta que agrupa todos los diferentes disparadores que están disponibles en este repositorio.

Cada una de estas carpetas va a tener una carpeta para cada una de las actividades y disparadores que se están implementando en este repositorio como puedes ver en la imagen a continuación:

Y cada una de ellas va a tener la misma estructura:

activity.json: Que va a describir el modelo de la actividad (nombre, descripción, autor, configuraciones de entrada, configuraciones de salida)
activity.go: Contiene todo el código de programación en Go para construir la capacidad que la actividad expone.
activity_test.go: Contiene todas las pruebas que la actividad debe tener listas para ser usadas por otros desarrolladores y usuarios.

NOTA: Las extensiones para TIBCO Flogo Enterprise tienen un archivo adicional llamado activity.ts que es un archivo TypeScript que define las validaciones de la interfaz de usuario que se deben realizar para la actividad.

Y una vez que tengamos el archivo, podemos subirlo de la misma manera que lo hicimos con la extensión anterior.

Usando CLI para Instalar

Además, si estamos usando el CLI de Flogo, aún podemos instalarlo usando directamente la URL a la carpeta de actividad sin necesidad de proporcionar el archivo zip. Para hacer eso, necesitamos habilitar el Administrador de Instalación usando el siguiente comando:

<FLOGO_HOME>/tools/installmgr.bat

Y eso va a construir una imagen de Docker que representa una herramienta CLI con los siguientes comandos:

Instalar: Instalar Flogo Enterprise, Conectores de Flogo, Servicios, etc. en el directorio de instalación actual.
Desinstalar: Desinstalar Flogo Enterprise, Conectores de Flogo, Servicios del directorio de instalación actual.

Y este proceso se puede usar con un Conector oficial así como con una Extensión OSS

Sondas de Kubernetes para una aplicación de TIBCO BusinessWorks Container Edition

2026-01-272019-05-20 por Alexandre Vazquez

Introducción

Las sondas son cómo podemos decirle a Kubernetes que todo dentro del pod está funcionando como se espera. Kubernetes no tiene forma de saber qué está sucediendo dentro a nivel detallado y no tiene forma de saber para cada contenedor si está saludable o no, por eso necesitan ayuda del propio contenedor.

Imagina que eres el controlador de Kubernetes y tienes como ocho pods diferentes, uno con una aplicación por lotes de Java, otro con alguna instancia de Redis, otro con una aplicación de nodejs, otro con un microservicio de Flogo (Nota: ¿Aún no has oído hablar de TIBCO Flogo? Tómate unos minutos para conocer una de las próximas novedades que puedes usar ahora para construir tus aplicaciones nativas en la nube), otro con una base de datos Oracle, otro con algún servidor web jetty y finalmente otro con una aplicación de BusinessWorks Container Edition. ¿Cómo puedes saber que cada componente está funcionando bien?

Primero, puedes pensar que puedes hacerlo con el componente de punto de entrada de tu Dockerfile ya que solo especificas un comando para ejecutar dentro de cada contenedor, así que verifica si ese proceso está en ejecución, ¿y eso significa que todo está saludable? Ok… bastante justo…

Pero, ¿esto es siempre cierto? ¿Un proceso en ejecución a nivel de SO/contenedor significa que todo está funcionando bien? Pensemos en la base de datos Oracle por un minuto, imagina que tienes un problema con la memoria compartida y se mantiene en un estado de inicialización para siempre, K8S va a verificar el comando, va a encontrar que está en ejecución y le dice a todo el clúster: ¡Ok! ¡No te preocupes! La base de datos está funcionando perfectamente, ¡adelante y envía tus consultas a ella!

Esto podría suceder con componentes similares como un servidor web o incluso con una aplicación en sí, pero es muy común cuando tienes servidores que pueden manejar implementaciones en él, como BusinessWorks Container Edition en sí. Y por eso esto es muy importante para nosotros como desarrolladores e incluso más importante para nosotros como administradores. ¡Así que empecemos!

Lo primero que vamos a hacer es construir una aplicación de BusinessWorks Container Edition, como este no es el propósito principal de este artículo, vamos a usar las mismas que he creado para la Integración de BusinessWorks Container Edition — Istio que puedes encontrar aquí.

Entonces, esta es una aplicación bastante simple que expone un servicio web SOAP. Todas las aplicaciones en BusinessWorks Container Edition (así como en BusinessWorks Enterprise Edition) tienen su propio estado, por lo que puedes preguntarles si están en ejecución o no, eso es algo que el «motor» interno de BusinessWorks Container (NOTA: Vamos a usar la palabra motor para simplificar cuando hablamos de los internos de BWCE. En detalle, el componente que conoce el estado de la aplicación es el AppNode interno que inicia el contenedor, pero mantengámoslo simple por ahora)

Sondas de Kubernetes

En Kubernetes, existe el concepto de «sonda» para realizar verificaciones de salud a tu contenedor. Esto se realiza configurando sondas de vivacidad o sondas de preparación.

Sonda de vivacidad: Kubernetes utiliza sondas de vivacidad para saber cuándo reiniciar un contenedor. Por ejemplo, las sondas de vivacidad podrían detectar un bloqueo, donde una aplicación está en ejecución, pero no puede avanzar.
Sonda de preparación: Kubernetes utiliza sondas de preparación para saber cuándo un contenedor está listo para comenzar a aceptar tráfico. Un pod se considera listo cuando todos sus contenedores están listos. Un uso de esta señal es controlar qué pods se utilizan como backends para los servicios. Cuando un pod no está listo, se elimina del balance de carga del servicio

Incluso cuando hay dos tipos de sondas para BusinessWorks Container Edition, ambas se manejan de la misma manera, la idea es la siguiente: Mientras la aplicación esté en ejecución, puedes comenzar a enviar tráfico y cuando no esté en ejecución necesitamos reiniciar el contenedor, por lo que eso lo hace más simple para nosotros.

Implementación de Sondas

Cada aplicación de BusinessWorks Container Edition que se inicia tiene una forma predeterminada de saber si está saludable o no. Esto se hace mediante un endpoint especial publicado por el propio motor:

http://localhost:7777/_ping/

Entonces, si tenemos una aplicación normal de BusinessWorks Container Edition desplegada en nuestro clúster de Kubernetes como la que teníamos para la integración de Istio, tenemos registros similares a estos:

Como puedes ver, los registros dicen que la aplicación está iniciada. Entonces, como no podemos lanzar una solicitud curl desde dentro del contenedor (ya que no hemos expuesto el puerto 7777 al exterior aún y curl no está instalado en la imagen base), lo primero que vamos a hacer es exponerlo al resto del clúster.

Para hacer eso, cambiamos nuestro archivo Deployment.yml que hemos usado a este:

Ahora, podemos ir a cualquier contenedor en el clúster que tenga «curl» instalado o cualquier otra forma de lanzar una solicitud como esta con el código HTTP 200 y el mensaje «La aplicación está en ejecución».

NOTA: Si olvidas la última / e intentas invocar _ping en lugar de _ping/ vas a obtener un código HTTP 302 Found con la ubicación final como puedes ver aquí:

Ok, veamos qué pasa si ahora detenemos la aplicación. Para hacer eso vamos a entrar en el contenedor y usar la consola OSGi.

Para hacer eso, una vez que estés dentro del contenedor, ejecutas el siguiente comando:

ssh -p 1122 equinox@localhost

Va a pedir credenciales y usa la contraseña predeterminada ‘equinox’. Después de eso, te dará la oportunidad de crear un nuevo usuario y puedes usar las credenciales que te funcionen. En mi ejemplo, voy a usar admin / adminadmin (NOTA: La longitud mínima para una contraseña es de ocho (8) caracteres.

Y ahora, estamos dentro. Y esto nos permite la opción de ejecutar varios comandos, como este no es el tema principal de hoy voy a omitir toda la explicación, pero puedes echar un vistazo a este enlace con toda la información sobre esta consola.

Si ejecutamos frwk:la va a mostrar las aplicaciones desplegadas, en nuestro caso la única, como debería ser en la aplicación de BusinessWorks Container Edition:

Para detenerla, vamos a ejecutar el siguiente comando para listar todos los paquetes OSGi que tenemos en este momento en ejecución en el sistema:

frwk:lb

Ahora, encontramos los paquetes que pertenecen a nuestra aplicación (al menos dos paquetes (1 por módulo BW y otro para la aplicación)

Y ahora podemos detenerlo usando felix:stop <ID>, así que en mi caso, necesito ejecutar los siguientes comandos:

stop “603”

stop “604”

Y ahora la aplicación está detenida

Entonces, si ahora intentamos lanzar el mismo comando curl que ejecutamos antes, obtenemos la siguiente salida:

Como puedes ver, un error HTTP 500 que significa que algo no está bien. Si ahora intentamos iniciar nuevamente la aplicación usando el comando de inicio de paquete (equivalente al comando de detención de paquete que usamos antes) para ambos paquetes de la aplicación, verás que la aplicación dice que está en ejecución nuevamente:

Y el comando tiene la salida HTTP 200 como debería tener y el mensaje «La aplicación está en ejecución»

Entonces, ahora, después de saber cómo funciona el endpoint _ping/ solo necesitamos agregarlo a nuestro archivo deployment.yml de Kubernetes. Así que modificamos nuevamente nuestro archivo de implementación para que sea algo como esto:

NOTA: Es bastante importante la presencia del parámetro initialDelaySeconds para asegurarse de que la aplicación tenga la opción de iniciarse antes de comenzar a ejecutar la sonda. En caso de que no pongas este valor, puedes obtener un bucle de reinicio en tu contenedor.

NOTA: El ejemplo muestra el puerto 7777 como un puerto exportado, pero esto solo es necesario para los pasos que hemos hecho antes y no será necesario en un entorno de producción real.

Así que ahora desplegamos nuevamente el archivo YML y una vez que tengamos la aplicación en ejecución, vamos a intentar el mismo enfoque, pero ahora como tenemos las sondas definidas tan pronto como detenga la aplicación, los contenedores se reiniciarán. ¡Veamos!

Como puedes ver en la imagen de arriba, después de que la aplicación se detiene, el contenedor se ha reiniciado y debido a eso, hemos sido expulsados de dentro del contenedor.

Así que eso es todo, espero que te ayude a configurar tus sondas y en caso de que necesites más detalles, por favor echa un vistazo a la documentación de Kubernetes sobre sondas httpGet para ver toda la configuración y opciones que puedes aplicarles.

Creando tu Primera Aplicación Flogo

2026-01-272019-05-13 por Alexandre Vazquez

En la publicación anterior, presentamos la tecnología Flogo como una de las cosas en la industria del desarrollo nativo en la nube y ahora vamos a construir nuestra primera aplicación Flogo e intentar cubrir todas las opciones que describimos en la publicación anterior.

NOTA .- Si eres nuevo en Flogo y no leíste la publicación anterior sobre las capacidades de Flogo, por favor tómate unos minutos para leerla antes de continuar.

TIBCO Flogo Introduction

Flogo is the next new thing in the developing applications in a cloud-native way. Since its foundation has been designed to cover all the new challenges that we need to face when dealing with new cloud-native development. So, please, if you or your enterprise is starting its movement to the cloud it’s the moment to […]

A partir de este momento, voy a usar Flogo Enterprise, que es el producto de núcleo abierto basado en el código abierto Project Flogo, y la versión actual es 2.5.0 como puedes ver aquí: https://docs.tibco.com/products/tibco-flogo-enterprise

Primero que nada, me gustaría presentar el escenario, este va a ser un escenario simple que muestra de la manera más sencilla los conceptos dentro de una aplicación Flogo, así que vamos a crear una aplicación Hola Mundo que va a ser expuesta usando el protocolo HTTP/JSON para comunicarse. Así que, el escenario va a ser como la imagen mostrada a continuación:

Entonces, lo primero que necesitamos hacer es lanzar la interfaz web de Flogo, así que vamos a nuestra carpeta donde tenemos nuestra instalación de TIBCO Flogo Enterprise y ejecutamos el comando desde el directorio bin

./run-studio.bat

Ahora, podemos ir a la ubicación http://localhost:8090 y vemos algo similar a esto:

Ahora, vamos a crear nuestra primera aplicación, así que hacemos clic en el botón “Crear” y proporcionamos un nombre para la aplicación, en nuestro caso la vamos a llamar “HelloWorldREST”

Ahora, entraremos en la página principal de una aplicación que es la que se muestra a continuación:

Es importante notar que los servicios Flogo se basan en flujos, por lo que puedes crear uno o más flujos que van a orquestar la lógica que necesitas implementar. Así que, lo primero que necesitamos hacer es crear un flujo, y lo vamos a hacer haciendo clic en el botón “Crear un flujo” y proporcionar un nombre para el flujo, en nuestro caso, como esta va a ser una aplicación simple, vamos a usar “main” como nombre del flujo que vamos a crear:

Y se te llevará al lienzo vacío de tu nuevo flujo “main”:

Hay dos conceptos importantes en un flujo Flogo:

Disparador: Esta es la forma en que este flujo va a ser iniciado, hay varias maneras de iniciar un flujo Flogo, por ejemplo, con una solicitud HTTP o un temporizador, o una fuente de eventos AWS Lambda, un tema de Kafka o un mensaje MQTT, etc. Puedes tener uno o más disparadores en tu aplicación y deberías tener uno si este es un flujo principal (en lugar de un subflujo que discutiremos en una publicación diferente). Los disparadores se muestran a la izquierda del lienzo como pequeños iconos cuadrados como puedes ver en la imagen a continuación:

Actividades: Son las que van a decidir qué lógica se va a ejecutar. Cada actividad tiene una acción que realizar que podría ser una interna como un registro de trazas o una externa como invocar un servicio REST o algo similar, y vamos a usar el resto del lienzo para construir el flujo lógico.

Entonces, lo primero que necesitamos hacer es configurar el Disparador de este flujo, y para hacer eso hacemos clic en el icono de más en el área de Disparadores y seleccionamos el disparador HTTP REST:

Y lo vamos a configurar como la imagen mostrada a continuación:

Método: GET
Ruta del recurso: /hello/{name}

Y hacemos clic en Continuar y en la siguiente ventana seleccionamos “Copiar Esquema”, para copiar el Esquema de Salida del Disparador al Esquema de Entrada del Flujo. Ahora, hemos añadido el disparador pero necesitamos configurar cómo se van a transferir los datos a las actividades del flujo. Para hacer esto, hacemos clic en la “Configuración del Disparador” porque necesitamos mapear los datos del disparador a la entrada del flujo, así que en caso de que tengamos más de un disparador podemos tener diferentes mapeos de cada uno de los disparadores a la entrada del flujo.

Ahora, vamos a la pestaña de Salida y seleccionamos “name” bajo el objeto pathParams y lo mapeamos al mismo atributo (name bajo pathParams del objeto $trigger).

Así que ahora este nombre va a ser transferido a la entrada del flujo y podemos usarlo en la lógica del flujo. Ahora es el momento de construir la lógica del flujo. En este caso va a ser muy fácil, ya que ya tenemos una actividad de retorno que se añade por defecto, solo vamos a añadir una actividad de Registro para imprimir los nombres que estamos recibiendo.

Para hacer eso hacemos clic en el botón de más en el lienzo y seleccionamos dentro de la Sección General la actividad Registrar Mensaje:

Y necesitamos configurarlo como muestra la imagen a continuación:

Así que, hacemos clic en la sección de Entrada y en este caso la actividad por defecto solo tiene un parámetro llamado “mensaje” que es el mensaje de registro que se va a imprimir, y creamos una estructura basada en la concatenación de un valor constante “Recibe solicitud con nombre: “ y el nombre que fue previamente mapeado en la configuración del disparador.

Como puedes ver, siempre tienes visibles todas las funciones que tienes disponibles agrupadas en diferentes categorías y también todos los datos de la tubería que puedes usar que están siendo generados por la ejecución de todas las actividades dentro del flujo

Así que, lo último que necesitamos hacer es configurar la actividad de retorno. Para hacer eso hacemos clic en la actividad de retorno y mapeamos los atributos código (a constante 200) y mensaje a la estructura mostrada a continuación:

Y eso es todo. Estamos listos. Así que ahora podemos comenzar a probar el servicio simple que hemos creado. Para hacer eso, Flogo Studio proporciona un Motor de Pruebas capaz de verificar que la lógica que has construido está funcionando bien. Este Motor de Pruebas va a probar la lógica del flujo, no los disparadores, así que comienza desde la primera actividad y no incluye la interacción con el disparador.

Para hacer eso solo necesitas hacer clic en el botón Iniciar Pruebas y proporcionar valores de entrada a tu flujo.

En nuestro caso, como la mayor parte de la lógica se basa en el disparador, no tiene sentido hacer ese paso, pero volveremos al Motor de Pruebas en próximas publicaciones sobre el Desarrollo Flogo. Así que, en lugar de hacer eso, vamos a construir el servicio directamente. Para hacer eso salimos del lienzo del flujo y volvemos a la página principal de la aplicación y vamos a hacer clic en el botón Construir y seleccionar la arquitectura que vas a usar para probar tu aplicación, en mi caso será Windows

Y eso va a generar un archivo ejecutable, en mi caso una aplicación EXE que tiene mi lógica que solo necesitamos ejecutar para ejecutar nuestro servicio

Así que, ahora, lo lanzamos y obtendremos una salida similar a esta:

Para probar la aplicación vamos a abrir una nueva pestaña en nuestro navegador y escribir la siguiente URL:

http://localhost:9999/hello/bob

Y obtenemos una respuesta como esta:

Introducción a TIBCO Flogo

2022-05-092019-05-06 por Alexandre Vazquez

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:

Flogo-contrib: https://github.com/TIBCOSoftware/flogo-contrib
Retgits flogo-components: https://github.com/retgits/flogo-components
Jvanderl flogo-components: https://github.com/jvanderl/flogo-components
Mmussett flogo-components: https://github.com/mmussett/flogo-components
Ayh20 flogo-components: https://github.com/ayh20/flogo-components

APIs de Gestión

Además, Flogo expone algunas APIs para poder integrarse con herramientas de terceros como por ejemplo las siguientes:

Integración con Sistemas de Gestión de Configuración como Consul, Zookeeper o Spring Cloud Config usando la información proporcionada aquí: https://github.com/TIBCOSoftware/flogo/wiki/Application-Properties
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.

Integración de Istio con aplicaciones BWCE

2022-05-072019-04-22 por Alexandre Vazquez

Introducción

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.

Comenzando con TIBCO(R) Messaging — Distribución de Apache Kafka (I) Visión general e instalación

2022-09-152018-09-17 por Alexandre Vazquez

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:

Documentación Oficial de Apache Kafka: https://kafka.apache.org/documentation/
Arquitectura de Kafka: https://dzone.com/articles/kafka-architecture

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!!

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:

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:

Y este es el resultado que obtenemos después de ejecutar ambos procesos:

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:

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.

¿Quieres ser un mejor administrador de sistemas? ¡Aprende a programar!

2022-05-092018-03-18 por Alexandre Vazquez

Estamos viviendo tiempos en los que se escucha hablar de DevOps en todas partes, cómo se deben eliminar las barreras entre estos dos mundos como Desarrollo y Operaciones, pero todos estos discursos se basan en el punto de vista del desarrollador y del negocio, pero nunca desde el punto de vista del Administrador.

Venimos de una época en la que los equipos de operaciones estaban divididos en varios niveles de escalamiento donde cada nivel debía estar menos poblado y más capacitado que el anterior. Así que tenemos un primer nivel con personas con conocimientos básicos que trabajan 24×7 cubriendo cualquier tipo de incidente que pudiera ocurrir. En caso de que ocurra algo, intentan resolverlo con el conocimiento (generalmente más documento que conocimiento…) y en caso de que algo no funcione como se espera, lo derivan a un segundo nivel con más conocimiento sobre la plataforma donde probablemente sean un equipo de guardia para manejar eso y vamos a tener tantos niveles como se desee. ¿Cómo encaja todo esto con DevOps, CI & CD y demás…? Ok, bastante fácil…

El Nivel 1 hoy en día no existe: Las herramientas de monitoreo, CI & CD y demás, hacen innecesario este primer nivel, porque si puedes crear un documento con los pasos a seguir cuando algo sale mal, estás escribiendo código pero dentro de un Documento, así que nadie te detiene para entregar una herramienta automatizada para hacer eso. Entonces, en inglés sencillo, los operadores de primer nivel de ayer ahora son scripts. Pero todavía necesitamos nuestros equipos de operaciones, nuestro servicio 24×7 y demás… seguro, porque de vez en cuando (más a menudo de lo que nos gustaría) sucede algo fuera de lo normal y eso necesita ser gestionado.

Entonces, la automatización nunca va a reemplazar a L2 & L3, así que vas a necesitar personas capacitadas para manejar incidentes, tal vez podrías tener un equipo más pequeño a medida que automatizas más procesos, pero nunca puedes deshacerte de la parte del conocimiento, ese no es el punto. Aquí, podemos discutir si este equipo podría ser el equipo de desarrollo o un equipo mixto de ambos mundos, y eso podría ser correcto. Cualquier enfoque es válido con esto. Así que, hemos implementado todos nuestros nuevos y elegantes procesos de CI & CD, herramientas de monitoreo y las plataformas parecen estar funcionando sin ninguna ayuda y soporte hasta que algo realmente extraño sucede. Entonces, ¿qué hacer con esa gente? Por supuesto, enseñar las habilidades para ser valiosos como L2 & L3, así que tienen que ser mejores operadores / administradores de sistemas / cualquier palabra que más te guste. ¿Y cómo pueden hacer eso?

Como dije antes, estamos pasando de un mundo donde los equipos de Operaciones trabajan basados en procedimientos escritos y tienen su imaginación limitada para mirar más allá de su protocolo aprobado, pero eso ya no es la forma en que L2 & L3 trabaja. Cuando te enfrentas a un incidente, el procedimiento es bastante similar a cazar un error, o si escapamos del mundo de TI, es como resolver un crimen. ¿Cuáles son las similitudes entre resolver un crimen y gestionar una plataforma? Ok, enumerémoslas:

– ¿Qué? — ¿Qué le pasó a mi sistema? Comienzas con las consecuencias del problema, probablemente un rastro de error en el registro, probablemente otro sistema llamándote porque tu sistema no está disponible… Ok, aquí lo tienes, este es tu cadáver.
¿Cuándo? — Cuando sabes que algo salió mal, comienzas a encontrar la causa raíz, y comienzas a buscar rastros de registros para encontrar el primero que generó el problema, incluso descartas los rastros de registros que son consecuencias del primero, y tratas de encontrar cuándo todo comenzó a fallar. Para hacer eso, necesitas buscar evidencias sobre el fallo y demás… Así que ahora, estás investigando, buscando evidencias, hablando con testigos (sí, tus rastros de registros son los testigos más confiables que vas a encontrar, rara vez mienten. Es como si estuvieran en el estrado frente a un juez)
….. ¿Y ahora? ¿Cómo & Por qué? — Y ese es el punto difícil, cómo & por qué, son los siguientes pasos como lo haces en una caza de errores, pero la principal diferencia aquí, es cuando el equipo de desarrollo está cazando un error, pueden correlacionar las evidencias que recopilan en el paso dos, con el código fuente que construyeron para saber cómo y por qué todo salió mal… Pero en tu caso, como administrador de sistemas probablemente te enfrentas a un sistema propietario o no tienes acceso al código o cómo enfrentarlo incluso si fuera de código abierto… y probablemente ni siquiera tienes acceso al código fuente del equipo de desarrollo… Entonces, ¿cómo resuelves esto?

Ok, probablemente la mayoría de ustedes están pensando algo como: Conocer el producto y tu plataforma. Ser un operador certificado del producto que estás gestionando, conocer todo el manual del producto, y demás… Y eso podría ser útil, porque eso significa que sabes mejor cómo funcionan las cosas a un nivel alto… pero… seamos claros: ¿Alguna vez encontraste en un curso de certificación, o examen o documentación o lo que sea, información de tan bajo nivel que podría ayudarte en el caso específico que estás enfrentando…? En caso de que la respuesta a mi pregunta sea sí, tal vez no estás enfrentando un error difícil, sino un error de configuración principal…
Entonces… ¿qué podemos hacer? Como dice el título: Aprende a programar. Pero probablemente estás pensando, ¿cómo puede estar relacionado saber programar con cazar un error cuando no tengo acceso al código ni siquiera para echar un vistazo? Y… ¿aprender a programar en qué lenguaje? ¿en los componentes que se gestionan en mi plataforma? ¿en java? ¿en Go? ¿En node.js? ¿En C++? ¿En x86? ¿Todos ellos? Ok… tienes razón, tal vez la pregunta no es simplemente aprender a programar, pero esa es la idea: Aprende a programar, aprende a diseñar, aprende a arquitectar soluciones… ¿Quieres saber por qué? Ok, veamos. En toda mi carrera he estado trabajando con muchos productos diferentes, diferentes enfoques, diferentes paradigmas, diferentes lenguajes base, todo diferente, pero todos comparten una cosa, que todos los sistemas hoy en día comparten: Están construidos por personas.

Sí, cada pieza de software, cada servidor, cada programa, cada página web, cada todo está construido por una persona, como tú y como yo…

Si piensas que todos los productos y piezas de software están hechos por genios, estás equivocado. ¿Eres consciente de cuántas piezas de software están disponibles? ¿Crees que existen tantos genios en todo el mundo? Por supuesto, son personas capacitadas y algunas de ellas son realmente brillantes, y es por eso que generalmente siguen el sentido común para arquitectar, diseñar y construir sus soluciones.

Y ese es el punto que podemos usar para resolver nuestro caso y resolver nuestro asesinato, porque con las evidencias que tenemos y las ideas de construir soluciones, tenemos que pensar: Ok, ¿cómo habría construido esto si yo fuera el encargado de esta pieza de software? Y vas a ver que tienes razón casi todo el tiempo…

Pero me falta otro punto importante que dejamos sin respuesta antes… ¿Aprender a programar en qué lenguaje? En el que tu plataforma está basada: Si estás gestionando una plataforma basada en OSGi, aprende mucho sobre desarrollo en java y desarrollo y arquitectura OSGI, vas a encontrar que todos los problemas son lo mismo… Una dependencia entre dos módulos OSGI, y una sentencia Import-package que debería estar allí… la otra en la que alguien carga los paquetes o alguna sentencia Export-Package que debería estar allí…

Lo mismo, si estás ejecutando una aplicación de escritorio .NET, aprende mucho sobre desarrollo .NET y serás lo suficientemente capacitado para no necesitar un documento para saber qué hacer, porque sabes cómo debería funcionar esto… y eso te llevará a por qué está sucediendo esto.

Y con todas esas preguntas respondidas, solo queda una cosa. Necesitas poner en marcha un plan para mitigar o resolver el problema, para que el problema nunca vuelva a suceder. Y con todo eso, presentamos nuestra orden de arresto al incidente.

Finalmente estás en la parte del juicio, cuando presentas tus evidencias, tu teoría sobre cómo y por qué sucedió esto (el motivo :P) y deberías poder convencer al jurado (el cliente) más allá de una duda razonable, y finalmente terminas con la sentencia que pediste para el error/fallo/incidente que es el plan de mitigación, y tu plataforma es un mundo mejor con un incidente menos caminando libre.

Lo que describimos aquí es cómo hacer un análisis post-mortem y probablemente para la mayoría de ustedes esto es algo diario que hacen, pero todo el tiempo en los clientes cuando trabajamos en colaboración con el equipo de operaciones, notamos que no siguen este enfoque, por lo que están atascados porque no tienen un documento que nos diga cómo hacer (paso a paso) en estas situaciones extrañas.

Así que, me gustaría terminar con un himno para resumir todo esto: Cuando te enfrentas a un incidente: «Mantén la calma, aplica el sentido común y comienza a leer los rastros de registros!!»

Microservicios en el mundo SOA y las integraciones empresariales

2022-05-072017-11-02 por Alexandre Vazquez

Microservicios

En los últimos dos años, todos están hablando de Microservicios y quieren aplicarlos en cualquier lugar.

Es la misma historia con los contenedores y docker (y antes lo fue con el Enfoque en la Nube e incluso antes con SOA, BPM, EDA…).

Cualquier cosa que tenga suficiente ruido de la comunidad, resulta en que todos los clientes (y «todo tipo» de clientes) intentan aplicar la «nueva moda» sin importar qué. Debido a eso, todos los Integradores de Sistemas intentan buscar un lugar donde encaje (o incluso si no encaja…) para aplicar esta «nueva cosa» porque es «lo que tenemos que hacer ahora». Es como el negocio de la moda. ¿Qué está de moda hoy? ¿Eso? Ok, hagámoslo.

No me malinterpreten, esta publicación no va a estar en contra de los microservicios porque me encanta el concepto y me encantan las ventajas que trae consigo y lo bueno que es ir hacia este tipo de modelo.

Pero, me gustaría hablar sobre algunos aspectos específicos que no estaban en la charla común y la experiencia con este tipo de tecnología. Este patrón, modelo o paradigma, es genial y es un éxito comprobado.

Puedes ver cualquier charla de Adrian Cockcroft sobre su experiencia en Netflix para estar seguro de que esto no es solo una palabra de moda (#NoSoloUnaPalabraDeModa) pero, ¿es capaz de usarse en todos los casos?

Cuando usualmente vemos una charla sobre microservicios, siempre es la misma historia: microservicios vs aplicación monolítica, especialmente aplicaciones web siguiendo algún tipo de patrón cliente-servidor o incluso un patrón MVC o algo similar. Y para ese tipo de aplicaciones es genial, simple y claro.

Pero, ¿qué pasa con las Aplicaciones Empresariales donde en las últimas décadas seguimos un Enfoque SOA: ¿Es aplicable aquí?

Por supuesto, hay muchas diferencias entre el Enfoque de Microservicios (el puro, el que Martin Fowler usó en su artículo) y el Paradigma SOA. No comparten los mismos principios, pero al final están más cerca que los concursantes habituales que ves en todas las charlas (aplicación web monolítica vs microservicios).

Los microservicios hablan de romper el monolito y eso es fácil para una aplicación web, pero ¿qué pasa con una Arquitectura SOA? En este caso, ni siquiera es posible seguir ese camino.

Si alguna vez has trabajado en Integración Empresarial, has visto algunos silos y es obligatorio no tocarlos y mantenerlos de esa manera. Es algo que no está abierto a discusión.

Existen diferentes razones para esa decisión: Podría ser porque son tan antiguos que nadie sabe sobre ellos, sobre cómo hacen lo que hacen, o podría ser porque son tan críticos que nadie va a seguir ese camino o solo porque no hay un caso de negocio para justificar reemplazar este tipo de silos.

Entonces, ¿qué pasa ahora? ¿Podemos seguir el camino de los Microservicios o deberíamos quedarnos con el enfoque SOA? Los microservicios no solo se tratan de romper los silos, pero es algo muy importante, así que no, no podemos seguir el camino de los Microservicios para Integraciones Empresariales, pero podemos reunir todas las otras ventajas que incluyen los Microservicios e intentar aplicarlas a nuestra capa de integración (ahora, no estaríamos hablando de Arquitectura SOA porque la mayoría de estas ventajas están en contra de algunos de los principios de SOA).

La Ola de Microservicios también se trata de Ágil y DevOps, de ser más rápido, de estar automatizado, de ser mejor, de reducir tu tiempo de comercialización. Se trata de la nube (no en el término de nube pública, sino en el término de no estar atado a tu infraestructura). Se trata de todas esas cosas también.

Entonces, los Microservicios se tratan de tantas cosas que podríamos aplicar incluso si no pudiéramos ir al 100% sobre esto. Hay varios nombres para este enfoque como Arquitectura Basada en Servicios, pero me gusta mucho más el enfoque de micro-servicios (con guion en el medio, hablando de servicios que son micro) porque creo que explica mejor el enfoque.

Así que, nos gustaría hacer servicios más pequeños para ser más flexibles, para poder aplicar todas estas cosas de DevOps, y allí podemos aplicar todas las otras cosas relacionadas con la Ola de Microservicios.

Y eso no es algo nuevo, eso no es algo que esté comenzando ahora o en los últimos años.

Es algo que he visto desde el principio en mi carrera (hace una década) cuando comencé a trabajar con TIBCO AMX BusinessWorks que te da la oportunidad de decidir tú mismo el alcance de tus servicios y dependiendo de las necesidades podrías crear «Aplicaciones Empresariales» o podrías optar por «Servicios Empresariales» o «Servicios Pequeños» que trabajaban juntos para hacer el trabajo.

Y ese camino ha sido seguido no solo por TIBCO sino por algunas otras compañías también, con la evolución del concepto ESB para adaptarse a la nueva era, que eran más como PaaS donde te permitían ejecutar tus servicios en un mundo «algo» containerizado.

Por ejemplo, la Plataforma TIBCO AMX (desde 2006) podías desarrollar tus servicios y aplicaciones usando varios tipos de lenguajes y opciones como el Editor Gráfico para Mediaciones o Java, C/C++, .NET, Spring y así sucesivamente usando el estándar SCA y ejecutándose en una plataforma elástica basada en OSGI donde puedes gestionarlos a todos de la misma manera (suena similar, ¿verdad? 🙂 )

¿Qué pasa con la reutilización? El paradigma SOA tiene estándares muy altos para asegurar la reutilización de los servicios y el registro y repositorio empresarial… y el microservicio está (al principio) en contra de la reutilización, deberías duplicar en lugar de reutilizar para poder ser autónomo y más libre. Pero, los últimos avances en Microservicios incluyen una capa de Orquestación, cosas como Conductor que están siguiendo el camino de la reutilización y la orquestación. Así que, podemos encontrar un lugar intermedio, cuando necesitas reutilizar si es posible pero no detener tu agilidad para asegurar el 100% de reutilización de las oportunidades disponibles. El tiempo de comercialización es el factor crítico aquí para todos ahora, y todos los «principios» tienen que adaptarse a eso.

¿Qué pasa con DevOps y la Nube? No hay problema, aquí podrías incluir las mismas técnicas para este caso como lo estabas haciendo anteriormente. Infraestructura como Código, Contenedores, Integración y Despliegue Continuo, etc.

¿Qué pasa con los estándares ágiles REST/JSON y demás? Tampoco hay problemas aquí.

En resumen, puedes adoptar e implementar la mayoría de los sabores y componentes del movimiento de Microservicios, pero también necesitas comprometerte con otros, y no vas a usar «Microservicios puros», vas a usar otra cosa, y eso no es malo. Siempre tienes que adaptar cualquier paradigma a tu caso de uso específico.