Alexandre Vazquez, Author at Alexandre Vazquez

Configuración de TIBCO BW Hashicorp Vault: Más Potente y Mejor Protegida en 3 Pasos

2026-04-212022-09-01 por Alexandre Vazquez

Tabla de contenidos

Introducción
Definición de la Aplicación BW
Despliegue en Kubernetes

Introducción

Este artículo tiene como objetivo mostrar la Configuración de TIBCO BW Hashicorp Vault para integrar su aplicación TIBCO BW con los secretos almacenados en Hashicorp Vault, principalmente para la externalización y gestión de recursos de contraseñas y credenciales.

Como probablemente sepa, en la aplicación TIBCO BW, la configuración se almacena en Propiedades a diferentes niveles (propiedades de Módulo o Aplicación). Puede leer más sobre ellas aquí. Y el propósito principal de esas propiedades es proporcionar flexibilidad a la configuración de la aplicación.

Estas propiedades pueden ser de diferentes tipos, como String, Integer, Long, Double, Boolean y DateTime, entre otros recursos técnicos dentro de TIBCO BW, como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Tipos de Propiedades BW

La integración de TIBCO BW Hashicorp Vault afectará solo a aquellas propiedades de tipo Contraseña (al menos hasta la versión 2.7.2/6.8.1 de BW). La razón detrás de esto es que esas propiedades son el tipo de datos relevantes para la información que es sensible y necesita ser segura. Otros conceptos pueden ser gestionados a través de componentes estándar de Kubernetes como ConfigMaps.

Definición de la Aplicación BW

Vamos a comenzar con una aplicación sencilla, como puede ver en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Ejemplo de Propiedad

Solo un temporizador simple que se ejecutará una vez e insertará la hora actual en la base de datos PostgreSQL. Usaremos Hashicorp Vault para almacenar la contraseña del usuario de la base de datos para poder conectarnos a ella. El nombre de usuario y la cadena de conexión residirán en un ConfigMap.

Omitiremos la parte de la configuración relacionada con el despliegue de los Contenedores de la aplicación TIBCO BW y enlazaremos a un ConfigMap. Tiene un artículo que cubre eso en detalle en caso de que necesite seguirlo, y nos centraremos solo en el tema relacionado con la integración de TIBCO BW Hashicorp Vault.

Así que necesitaremos decirle a TIBCO BW que la contraseña del Recurso Compartido JDBC estará vinculada a la configuración de Hashicorp Vault, y para hacer eso, lo primero es haber vinculado la Contraseña de los Recursos Compartidos a una Propiedad de Módulo como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Contraseña vinculada a Propiedad de Módulo

Ahora, necesitamos decirle a esta Propiedad de Módulo que está vinculada a Hashicorp Vault, y lo haremos en la Vista de Propiedades de la Aplicación, seleccionando que esta propiedad está vinculada a una Solución de Gestión de Credenciales como se muestra en la imagen a continuación:

Configuración de TIBCO BW Hashicorp Vault: Configuración de Gestión de Credenciales para Propiedad

Y es ahora cuando establecemos la relación de TIBCO BW Hashicorp Vault. Necesitamos hacer clic directamente en el signo más verde, y tendremos una ventana modal que nos pedirá la tecnología de gestión de credenciales que vamos a usar y los datos necesarios para cada una de ellas, como puede ver en la siguiente imagen:

Seleccionaremos Hashicorp Vault como el proveedor. Luego necesitaremos proporcionar tres atributos que ya comentamos en el artículo anterior cuando comenzamos a crear secretos en Hashicorp Vault:

Nombre del Secreto: este es el nombre del secreto después de la ruta raíz del elemento.
Clave del Secreto: Esta es la clave dentro del propio secreto
Ruta de Montaje: Esta es la ruta raíz del secreto

Para obtener más detalles sobre estos tres conceptos, por favor, consulte nuestro artículo sobre cómo crear secretos en Hashicorp Vault.

Así que con todo esto, tenemos prácticamente todo lo que necesitamos para conectarnos a Hashicorp Vault y obtener el secreto, y desde el lado de TIBCO BW BusinessStudio, todo está hecho; podemos generar el archivo EAR y desplegarlo en Kubernetes porque aquí está la última parte de nuestra configuración.

Despliegue en Kubernetes

Hasta este momento, ya hemos proporcionado la siguiente información:

Proceso BW que tiene el inicio de sesión para conectarse a la Base de Datos e insertar información
Enlace entre la propiedad de contraseña utilizada para conectar y la definición del Secreto de Hashicorp

Así que, prácticamente todo está ahí, pero falta un concepto. ¿Cómo se conectará el Pod de Kubernetes a Hashicorp una vez que el pod esté desplegado? Hasta este punto, no proporcionamos la ubicación del servidor de Hashicorp Vault del método de autenticación para conectarse a él. Esta es la parte que falta de la integración de TIBCO BW Hashicorp Vault y será parte del archivo YAML de Despliegue de Kubernetes.

Lo haremos usando las siguientes propiedades de entorno en este ejemplo:

Configuración de TIBCO BW Hashicorp Vault: Variables de Entorno de Hashicorp

HASHICORP_VAULT_ADDR: Esta variable apuntará a donde se encuentra el servidor de Hashicorp Vault
HASHICORP_VAULT_AUTH: Esta variable indicará qué opciones de autenticación se utilizarán. En nuestro caso, usaremos la de token como usamos en el artículo anterior
HASHICORP_VAULT_KV_VERSION: Esta variable indica qué versión de la solución de almacenamiento KV estamos usando y será dos por defecto.
HASHICORP_VAULT_TOKEN: Este será solo el valor del token para poder autenticarse contra el servidor de Hashicorp Vault

Si está utilizando otros métodos de autenticación o simplemente quiere saber más sobre esas propiedades, por favor, eche un vistazo a esta documentación de TIBCO.

Con todo eso agregado a las propiedades de entorno de nuestra aplicación TIBCO BW, podemos ejecutarla, y obtendremos una salida similar a esta, que muestra que la integración de TIBCO BW Hashicorp Vault se ha realizado y la aplicación pudo iniciarse sin ningún problema

Configuración de TIBCO BW Hashicorp Vault: Ejecución de ejemplo

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Crea Secretos en Hashicorp Vault Usando 2 Formas Fáciles

2026-04-212022-08-29 por Alexandre Vazquez

Introducción

Crear secretos en Hashicorp Vault es una de las cosas más importantes y relevantes que puedes hacer una vez que has instalado Hashicorp Vault en tu entorno, probablemente recuperando y obteniendo estos secretos de los componentes que los necesitan. Pero en el artículo de hoy, nos centraremos en la primera parte para que puedas aprender lo fácil que es crear secretos en Hashicorp Vault.

En artículos anteriores comentamos la importancia de Hashicorp Vault y el proceso de instalación, como puedes leer aquí. Por lo tanto, en este punto, ya tenemos nuestra bóveda lista para comenzar a trabajar con ella completamente inicializada y desbloqueada para poder comenzar a atender solicitudes.

Crear Secretos en Hashicorp Vault usando Comandos CLI de Hashicorp Vault

Todos los comandos que realizaremos usarán un componente crítico llamado Hashicorp Vault CLI, y notarás eso porque todos nuestros comandos comenzarán con vault. Para ser honesto, ya comenzamos con eso en el artículo anterior; si recuerdas, ya ejecutamos algunos de estos comandos para inicializar o desbloquear la bóveda, pero ahora este será nuestro componente principal para interactuar.

Lo primero que necesitamos hacer es poder iniciar sesión en la bóveda, y para hacer eso; vamos a usar el token raíz que se nos proporcionó cuando inicializamos la bóveda; vamos a almacenar esta bóveda en una variable de entorno para que sea fácil trabajar con ella. Todos los comandos que vamos a ejecutar ahora estarán dentro del pod del servidor del agente de la bóveda, como se muestra en la imagen a continuación:

Crear Secretos en Hashicorp Vault: Detectando Pod del Servidor de la Bóveda

Una vez que estemos dentro, vamos a hacer el comando de inicio de sesión con la siguiente sintaxis:

 vault login

Y obtendremos una salida similar a esta:

Crear Secretos en Hashicorp Vault: Iniciando sesión en Hashicorp Vault

Si no proporcionamos el token de antemano, la consola pedirá que se escriba el token posteriormente, y se ocultará automáticamente, como puedes ver en la imagen a continuación:

Crear Secretos en Hashicorp Vault: Iniciando sesión sin Token proporcionado

Después de este punto, ya estamos conectados a la bóveda, por lo que podemos comenzar a escribir comandos para crear secretos en Hashicorp Vault. Comencemos con ese proceso.

Para comenzar con nuestro proceso de creación de secretos en Hashicorp Vault, primero necesitamos hacer o ser más precisos con la sintaxis de Hashicorp Vault para habilitar una ruta de secreto que puedes pensar como la ruta raíz a la que estarán relacionados todos tus secretos. Si estamos hablando de tener secretos para diferentes aplicaciones, cada ruta puede ser cada una de las aplicaciones, pero la organización de los secretos puede ser diferente dependiendo del contexto. Cubriremos eso con mucho más detalle en los siguientes artículos.

Para habilitar la ruta de secreto para comenzar la creación de secretos en Hashicorp Vault, escribiremos el siguiente comando:

 vault secrets enable -path=internal kv-v2

Eso habilitará un almacén de secretos del tipo kv-v2 (almacén de clave-valor en su v2), y la ruta será “internal,” por lo que todo lo que creemos después de eso estará bajo esta ruta raíz “internal.”

Y ahora, vamos a hacer la creación del secreto en Hashicorp Vault, y como estamos usando un almacén de clave-valor, la sintaxis también está relacionada con eso porque vamos a “poner” un secreto usando el siguiente comando:

 vault kv put internal/database/config username="db-readonly-username" password="db-secret-password"

Eso creará dentro de la ruta interna una ruta hija /database/config donde almacenará dos claves:

username que tendrá el valor db-readonly-username
password que tendrá el valor db-secret-password

Como puedes ver, es bastante fácil crear nuevos secretos en la Bóveda vinculados a la ruta, y si deseas recuperar su contenido, también puedes hacerlo usando el CLI de la Bóveda, pero esta vez usando el comando get como se muestra en el fragmento a continuación:

 vault kv get internal/database/config

Y la salida será similar a la que se muestra a continuación:

Crear Secretos en Hashicorp Vault: Recuperando Secretos de la Bóveda

Esto te ayudará a interactuar con el contenido de tu almacén para recuperar, agregar o actualizar lo que ya tienes allí. Una vez que tengas todo listo allí, podemos pasar al lado del cliente para configurarlo para recopilar todos estos datos como parte de su flujo de trabajo de ciclo de vida.

Crear Secretos en Hashicorp Vault usando REST API

El CLI de Hashicorp Vault simplifica la interacción con el servidor de la bóveda, pero toda la interacción entre el CLI y el servidor ocurre a través de una REST API que el servidor expone y el cliente CLI consume. Proporciona una sintaxis simplificada al usuario y traduce los parámetros proporcionados en solicitudes REST al servidor, pero también puedes usar solicitudes REST para ir directamente al servidor. Por favor, consulta este artículo en la documentación oficial para obtener más detalles sobre la REST API.

Instalación de Hashicorp Vault en Kubernetes: Rápida y Sencilla en 3 Pasos Fáciles

2026-04-212022-08-22 por Alexandre Vazquez

Tabla de contenidos

Introducción
Métodos de Instalación
Chart de Helm para Hashicorp Vault
Proceso de Instalación de Hashicorp Vault

Introducción

En este artículo, vamos a cubrir la instalación de Hashicorp Vault en Kubernetes. Hashicorp Vault se ha convertido en uno de los estándares de la industria cuando hablamos de gestionar secretos y datos sensibles en entornos de producción, y esto cubre implementaciones en la nube y no nativas de la nube. Pero especialmente en Kubernetes, este es un componente crítico. Ya hemos comentado que los Secretos de Kubernetes no están muy seguros por defecto, por lo que HashiCorp Vault resuelve ese problema.

Métodos de Instalación

Hashicorp Vault proporciona muchos métodos de instalación diferentes que puedes leer en su página oficial aquí; la mayoría todavía se centra en un entorno tradicional. Pero en resumen, estos son los que tienes disponibles:

Instalar desde el gestor de paquetes
Instalar desde un binario preexistente
Instalar desde el código fuente
Helm para Kubernetes

Como puedes imaginar, el camino que seguiremos aquí es el de Helm. Supongo que ya estás familiarizado con Helm, pero si no, echa un vistazo aquí, y si también estás en el proceso de crear charts de helm, este otro también puede ayudarte.

Chart de Helm para Hashicorp Vault

Para el propósito de este artículo, vamos a lo que se llama una instalación de hashicorp vault independiente, por lo que no vamos a crear en este post una arquitectura con Alta Disponibilidad (HA) que esté lista para producción, sino algo que pueda ayudarte a comenzar a jugar con la herramienta y ver cómo esta herramienta puede integrarse con otras que pertenecen al mismo entorno nativo de la nube. Para obtener más información sobre cómo implementar Hashicorp Vault en una configuración lista para producción, consulta el siguiente enlace.

Primero necesitamos instalar el chart de helm en nuestro entorno local, pero debemos tener mucho cuidado con la versión de helm que tenemos. Al escribir este artículo, la instalación de Hashicorp Vault requiere una versión de Helm 3.7+, por lo que primero debes verificar la versión que tienes instalada.

En caso de que estés ejecutando una versión anterior, obtendrás el siguiente error:

 Error: parse error at (vault/templates/_helpers.tpl:38): unclosed action

Puedes obtener más detalles sobre este problema de GitHub.

Al momento de escribir este artículo, la última versión de Helm es 3.9, pero esta versión genera un problema con AWS EKS con este error:

 Error: Kubernetes cluster unreachable: exec plugin: invalid apiVersion "client.authentication.k8s.io/v1alpha1."
Failed installing **** with helm

Puedes obtener más detalles sobre este problema de GitHub.

Entonces, en ese caso, la mejor manera de asegurarse de que no habrá un problema con la instalación de Hashicorp Vault es degradar a 3.8, y podrás implementar el chart de helm sin ningún problema.

Proceso de Instalación de Hashicorp Vault

Para proceder con la instalación de Hashicorp Vault, necesitamos ejecutar los siguientes comandos:

helm repo add hashicorp https://helm.releases.hashicorp.com
helm install vault hashicorp/vault

Esto instalará dos componentes diferentes: un único servidor de vault como parte de un StatefulSet y un vault-agent-injector para gestionar la inyección de la configuración de vault en los diversos componentes e implementaciones en los otros espacios de nombres.

Para que los pods se ejecuten, necesitamos inicializar y desellarlo antes de estar listos para usar. Para hacer eso, necesitamos entrar dentro del pod del servidor de vault y ejecutar los siguientes comandos:

 vault operator init

Esto generará varias cosas esenciales:

Generará las claves para poder desellar el vault y comenzar a usarlo. Mostrará un número diferente de claves, en nuestro ejemplo 5, y necesitarás al menos 3 de ellas para poder desellar el vault.
También generará un token raíz para poder iniciar sesión en la CLI e interactuar con el servidor para poder leer y escribir secretos.

Después de eso, necesitaremos ejecutar el siguiente comando al menos tres veces, proporcionando cada uno de ellos con una clave de desellado diferente:

 Vault operator unseal

Después de ese punto, todos los componentes están en ejecución y listos, y podemos concluir nuestra instalación de Hashicorp Vault y comenzar a interactuar con el vault para crear tus secretos.

Instalación de Hashicorp Vault: Todos los Componentes Listos

Bucles de Helm: Truco de Helm #1

2026-01-272022-08-16 por Alexandre Vazquez

Tabla de contenidos

Introducción
Introducción a los Bucles de Helm
¿Cómo crear un Bucle de Helm?
¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

Introducción

Descubre cómo agregar bucles de Helm a tus helm charts para proporcionar un comportamiento más dinámico a tus Helm Charts.

Los Helm Charts se están convirtiendo en la solución predeterminada de facto cuando deseas empaquetar tu implementación de Kubernetes para poder distribuirla o instalarla rápidamente en tu sistema.

Definido varias veces como el apt para Kubernetes por su similitud con el antiguo gestor de paquetes de distribuciones GNU/Linux similares a Debian, parece seguir creciendo en popularidad cada mes en comparación con otras soluciones similares incluso más integradas en Kubernetes como Kustomize, como puedes ver en la imagen de Google Trends a continuación:

Pero crear estos helm charts no es tan fácil como parece. Si ya has estado trabajando en ello, probablemente te hayas atascado en algún punto, o hayas pasado mucho tiempo tratando de hacer algunas cosas. Si es la primera vez que estás creando uno o intentando hacer algo avanzado, espero que todos estos trucos te ayuden en tu camino. Hoy vamos a cubrir uno de los trucos más importantes, y esos son los bucles de Helm.

Introducción a los Bucles de Helm

Si ves cualquier helm chart, seguro que tendrás muchos bloques condicionales. Prácticamente todo está cubierto bajo una estructura if/else basada en los archivos values.yml que estás creando. Pero esto se vuelve un poco complicado cuando hablamos de bucles. Pero lo bueno es que tendrás la opción de ejecutar un bucle de helm dentro de tus helm charts usando la primitiva range.

¿Cómo crear un Bucle de Helm?

El uso de la primitiva range es bastante simple, ya que solo necesitas especificar el elemento que deseas iterar, como se muestra en el fragmento a continuación:

{{- range .Values.pizzaToppings }}
- {{ . | title | quote }}
{{- end }}

Este es un ejemplo bastante simple donde el yaml iterará sobre los valores que has asignado a la estructura pizzaToppings en tu values.yml.

Hay algunos conceptos a tener en cuenta en esta situación:

Puedes acceder fácilmente a todo dentro de esta estructura que estás recorriendo. Entonces, si el ingrediente de la pizza tiene campos adicionales, puedes acceder a ellos con algo similar a esto:

{{- range.Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }}
{{- end }}

Y esto accederá a una estructura similar a esta en tu values.yml:

 pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3

Lo bueno es que puedes acceder a su atributo subyacente sin replicar toda la jerarquía principal hasta llegar a la estructura de bucle porque dentro de la sección de rango, el alcance ha cambiado. Nos referiremos a la raíz de cada elemento que estamos iterando.

¿Cómo acceder a elementos principales dentro de un Bucle de Helm?

En la sección anterior, cubrimos cómo podemos acceder fácilmente al atributo interno dentro de la estructura de bucle debido al cambio de alcance, lo que también tiene un problema. En caso de que quiera acceder a algún elemento en el padre de mi archivo values.yml o en algún lugar fuera de la estructura, ¿cómo puedo acceder a ellos?

Lo bueno es que también tenemos una gran respuesta para eso, pero puedes llegar allí. Necesitamos entender un poco sobre los alcances en Helm.

Como se comentó, . se refiere al elemento raíz en el alcance actual. Si nunca has definido una sección de rango u otra primitiva que cambie el contexto, . siempre se referirá a la raíz de tu values.yml. Es por eso que cuando ves un helm chart, ves todas las estructuras con la siguiente forma de trabajar: .Values.x.y.z, pero ya hemos visto que cuando tenemos una sección range, esto está cambiando, por lo que esta no es una buena manera.

Para resolver eso, tenemos el contexto $ que se refiere constantemente a la raíz del values.yml sin importar cuál sea el alcance actual. Así que eso significa que si tengo el siguiente values.yml:

base:
	- type: slim 
pizzaToppings:
	- ingredient:
		name: Piña
		weight: 3
	- ingredient:
		name: Manzana
		weight: 3

Y quiero referirme al tipo base dentro de la sección de rango similar a antes, puedo hacerlo usando el siguiente fragmento:

{{- range .Values.pizzaToppings }}
- {{ .ingredient.name | title | quote }} {{ $.Values.base.type }}
{{- end }}

Eso generará la siguiente salida:

 - Piña slim
 - Manzana slim

¡Así que espero que este truco de helm chart te ayude con la creación, modificación o mejora de tus helm charts mejorados en el futuro utilizando bucles de helm sin ninguna preocupación adicional!

Operador de Registro de BanzaiCloud en Kubernetes Simplificado en 5 minutos

2026-01-182022-08-08 por Alexandre Vazquez

En el artículo anterior, describimos qué capacidad proporciona BanzaiCloud Logging Operator y sus características principales. Así que hoy vamos a ver cómo podemos implementarlo.

Lo primero que necesitamos hacer es instalar el operador en sí, y para hacerlo, tenemos un chart de helm a nuestra disposición, así que lo único que necesitaremos hacer son los siguientes comandos:

 helm repo add banzaicloud-stable https://kubernetes-charts.banzaicloud.com
helm upgrade --install --wait --create-namespace --namespace logging logging-operator banzaicloud-stable/logging-operator

Eso creará un namespace de logging (en caso de que aún no lo tengas), y desplegará los componentes del operador en sí, como puedes ver en la imagen a continuación:

Así que, ahora podemos empezar a crear los recursos que necesitamos usando el CRD que comentamos en el artículo anterior, pero para hacer un resumen. Estos son los que tenemos a nuestra disposición:

logging – El recurso de logging define la infraestructura de logging para tu clúster que recoge y transporta tus mensajes de log. También contiene configuraciones para Fluentd y Fluent-bit.
output / clusteroutput – Define una Salida para un flujo de logging, donde se envían los mensajes de log. output será basado en namespace, y clusteroutput será basado en clúster.
flow / clusterflow – Define un flujo de logging usando filtros y salidas. El flujo dirige los mensajes de log seleccionados a las salidas especificadas. flow será basado en namespace, y clusterflows serán basados en clúster.

Así que, primero que nada, vamos a definir nuestro escenario. No quiero hacer algo complejo; deseo que todos los logs que mis cargas de trabajo generen, sin importar en qué namespace estén, sean enviados a una instancia de Grafana Loki que también he instalado en ese clúster de Kubernetes en un endpoint específico usando la configuración Simple Scalable para Grafana Loki.

Así que, comencemos con los componentes que necesitamos. Primero, necesitamos un objeto de Logging para definir mi infraestructura de Logging, y lo crearé con el siguiente comando.

kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: Logging
metadata:
  name: default-logging-simple
spec:
  fluentd: {}
  fluentbit: {}
  controlNamespace: logging
EOF

Mantendremos la configuración predeterminada para fluentd y fluent-bit solo por el bien del ejemplo, y más adelante en próximos artículos, podemos hablar sobre un diseño específico, pero eso es todo.

Una vez que el CRD se procese, los componentes aparecerán en tu namespace de logging. En mi caso, que estoy usando un clúster de 3 nodos, veré 3 instancias de fluent-bit desplegadas como un DaemonSet y un solo ejemplo de fluentd, como puedes ver en la imagen a continuación:

Así que, ahora necesitamos definir la comunicación con Loki, y como me gustaría usar esto para cualquier namespace que pueda tener en mi clúster, usaré la opción ClusterOutput en lugar de la normal Output que está basada en namespace. Y para hacer eso, usaremos el siguiente comando (por favor asegúrate de que el endpoint sea el correcto; en nuestro caso, este es loki-gateway.default ya que está ejecutándose dentro del clúster de Kubernetes:

kubectl -n logging apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
 name: loki-output
spec:
 loki:
   url: http://loki-gateway.default
   configure_kubernetes_labels: true
   buffer:
     timekey: 1m
     timekey_wait: 30s
     timekey_use_utc: true
EOF

Y prácticamente tenemos todo; solo necesitamos un flujo para comunicar nuestra configuración de Logging al ClusterOutput que acabamos de crear. Y nuevamente, iremos con el ClusterFlow porque nos gustaría definir esto a nivel de Clúster y no de manera basada en namespace. Así que usaremos el siguiente comando:

 kubectl -n logging  apply -f - <<"EOF"
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
  name: loki-flow
spec:
  filters:
    - tag_normaliser: {}
  match:
    - select: {}
  globalOutputRefs:
    - loki-output
EOF

Y después de un tiempo para recargar la configuración (1-2 minutos más o menos), comenzarás a ver en los rastros de Loki algo como esto:

Y eso indica que ya estamos recibiendo el envío de logs de los diferentes componentes, principalmente el elemento fluentd que configuramos en este caso. Pero creo que es mejor verlo gráficamente con Grafana:

¡Y eso es todo! Y cambiar nuestra configuración de logging es tan simple como cambiar el componente CRD que definimos, aplicando coincidencias y filtros, o enviándolo a un nuevo lugar. De manera sencilla, tenemos esto completamente gestionado.

📚 Want to dive deeper into Kubernetes? This article is part of our comprehensive Kubernetes Architecture Patterns guide, where you’ll find all fundamental and advanced concepts explained step by step.

Potencia la agregación de registros en Kubernetes con BanzaiCloud Logging Operator

2026-04-212022-08-01 por Alexandre Vazquez

Potenciar la Agregación de Logs en Kubernetes con BanzaiCloud Logging Operator (Foto por Markus Spiske en Unsplash)

Ya hemos hablado sobre la importancia de la Agregación de Logs en Kubernetes y por qué el cambio en el comportamiento de los componentes lo convierte en un requisito obligatorio para cualquier nueva arquitectura que implementemos hoy.

Para resolver esa parte, tenemos muchas pilas diferentes de las que probablemente hayas oído hablar. Por ejemplo, si seguimos el camino tradicional de Elasticsearch, tendremos la pila ELK pura de Elasticsearch, Logstash y Kibana. Ahora esta pila se ha ampliado con los diferentes «Beats» (FileBeat, NetworkBeat, …) que proporcionan un reenviador de logs ligero para ser añadido a la tarea.

Además, puedes cambiar Logstash por un componente de CNCF como Fluentd del que probablemente hayas oído hablar, y en ese caso, estamos hablando de una pila EFK siguiendo el mismo principio. Y también, tener la vista de Grafana Labs usando promtail, Grafana Loki, y Grafana para paneles de control siguiendo una perspectiva diferente.

Luego puedes cambiar y modificar cualquier componente por el de tu preferencia, pero al final, tendrás tres tipos diferentes de componentes:

Reenviador: Componente que escuchará todas las entradas de logs, principalmente la salida stdout/stderr de tus contenedores, y lo enviará a un componente central.
Agregador: Componente que recibirá todos los rastros del reenviador, y tendrá algunas reglas para filtrar algunos de los eventos, formatear y enriquecer los recibidos antes de enviarlos al almacenamiento central.
Almacenamiento: Componente que recibirá los rastros finales para ser almacenados y recuperados por los diferentes clientes.

Para simplificar la gestión de eso en Kubernetes, tenemos un gran Operador de Kubernetes llamado BanzaiCloud Logging Operator que intenta seguir ese enfoque de manera declarativa / política. Así que veamos cómo funciona, y para explicarlo mejor, usaré su diagrama central de su sitio web:

Este operador utiliza las mismas tecnologías de las que estábamos hablando. Cubre principalmente los dos primeros pasos: Reenvío y Agregación y la configuración para ser enviada a un Almacenamiento Central de tu elección. Para hacer eso, trabaja con las siguientes tecnologías, todas ellas parte del Paisaje CNCF:

Fluent-bit actuará como un reenviador desplegado en modo DaemonSet para recopilar todos los logs que hayas configurado.
Fluentd actuará como un agregador definiendo los flujos y reglas de tu elección para adaptar el flujo de rastros que estás recibiendo y enviando a la salida de tu elección.

Y como este es un Operador de Kubernetes, esto funciona de manera declarativa. Definiremos un conjunto de objetos que definirán nuestras políticas de registro. Tenemos los siguientes componentes:

logging – El recurso de logging define la infraestructura de registro para tu clúster que recopila y transporta tus mensajes de log. También contiene configuraciones para Fluentd y Fluent-bit.
output / clusteroutput – Define una Salida para un flujo de registro, donde se envían los mensajes de log. output será basado en el espacio de nombres, y clusteroutput será basado en el clúster.
flow / clusterflow – Define un flujo de registro usando filtros y salidas. El flujo dirige los mensajes de log seleccionados a las salidas especificadas. flow será basado en el espacio de nombres, y clusterflows será basado en el clúster.

En la imagen a continuación, verás cómo estos objetos están «interactuando» para definir tu arquitectura de registro deseada:

Y aparte del modo de política, también incluye muchas características geniales como:

Aislamiento de espacio de nombres
Selectores de etiquetas nativos de Kubernetes
Comunicación segura (TLS)
Validación de configuración
Soporte para múltiples flujos (multiplicar logs para diferentes transformaciones)
Soporte para múltiples salidas (almacenar los mismos logs en múltiples almacenamientos: S3, GCS, ES, Loki, y más…)
Soporte para múltiples sistemas de registro (múltiples despliegues de Fluentd, Fluent Bit en el mismo clúster)

En próximos artículos hablaremos sobre cómo podemos implementar esto para que puedas ver todos los beneficios que este enfoque basado en CRD y políticas puede proporcionar a tu arquitectura.

Grafana Loki y MinIO: ¡Una combinación perfecta!

2026-01-182022-07-25 por Alexandre Vazquez

Grafana Loki se está convirtiendo en uno de los estándares de facto para la agregación de logs en cargas de trabajo de Kubernetes hoy en día, y hoy vamos a mostrar cómo podemos usar juntos Grafana Loki y MinIO. Ya hemos cubierto en varias ocasiones las capacidades de Grafana Loki que han surgido como la principal alternativa al liderazgo de Elasticsearch en los últimos 5-10 años para la agregación de logs.

Con un enfoque diferente, más ligero, más nativo de la nube, más enfocado en las cosas buenas que Prometheus ha proporcionado pero para logs y con el patrocinio de una gran empresa como Grafana Labs con las herramientas de paneles como líder de un stack de herramientas cada día más enorme en el mundo de la observabilidad.

Y también, ya hemos cubierto MinIO como un almacén de objetos que se puede implementar en cualquier lugar. Es como tener tu servicio S3 en cualquier nube que te guste o en las instalaciones. Así que hoy, vamos a ver cómo ambos pueden trabajar juntos.

Grafana Loki principalmente admite tres modelos de despliegue: monolítico, simple-escalable y distribuido. Prácticamente todo excepto el monolítico tiene el requisito de tener una solución de Almacenamiento de Objetos para poder trabajar en un modo escalable distribuido. Entonces, si tienes tu implementación en AWS, ya estás cubierto con S3. Además, Grafana Loki admite la mayoría de las soluciones de Almacenamiento de Objetos para el ecosistema en la nube de los principales proveedores. Aún así, el problema surge cuando deseas confiar en Grafana Loki para una instalación en la nube privada o en las instalaciones.

En ese caso, es donde podemos confiar en MinIO. Para ser honesto, puedes usar MinIO también en el mundo de la nube para tener una solución más flexible y transparente y evitar cualquier dependencia con un proveedor de nube. Aún así, para las instalaciones, su uso se ha vuelto obligatorio. Una de las grandes características de MinIO es que implementa la API de S3, por lo que prácticamente cualquier cosa que admita S3 funcionará con MinIO.

En este caso, solo necesito adaptar algunos valores en el gráfico de helm de Loki en el modo simple-distribuido como se muestra a continuación:

 loki:
  storage:
    s3:
      s3: null
      endpoint: http://minio.minio:9000
      region: null
      secretAccessKey: XXXXXXXXXXX
      accessKeyId: XXXXXXXXXX
      s3ForcePathStyle: true
      insecure: true

Simplemente estamos apuntando al endpoint de nuestro inquilino de MinIO, en nuestro caso, también implementado en Kubernetes en el puerto 9000. También estamos proporcionando las credenciales para conectar y finalmente mostrando que necesita s3ForcePathSyle: true es necesario para que el endpoint se transforme a minio.minio:9000/bucket en lugar de bucket.minio.minio:9000, por lo que funcionará mejor en un ecosistema de Kubernetes.

Y eso es prácticamente todo; tan pronto como lo inicies, comenzarás a ver que los buckets comienzan a poblarse como lo harían en caso de que estuvieras usando S3, como puedes ver en la imagen a continuación:

MinIO mostrando buckets y objetos de la configuración de Loki

Ya cubrimos los modelos de implementación de MinIO. Como se muestra aquí, puedes usar su gráfico de helm o el operador de MinIO. Pero, la integración con Loki es aún mejor porque los gráficos de helm de Loki ya incluyen MinIO como un sub-gráfico para que puedas implementar MinIO como parte de tu implementación de Loki basado en la configuración que encontrarás en el values.yml como se muestra a continuación:

 # -------------------------------------
# Configuración para el gráfico hijo `minio`
# -------------------------------------
minio:
  enabled: false
  accessKey: enterprise-logs
  secretKey: supersecret
  buckets:
    - name: chunks
      policy: none
      purge: false
    - name: ruler
      policy: none
      purge: false
    - name: admin
      policy: none
      purge: false
  persistence:
    size: 5Gi
  resources:
    requests:
      cpu: 100m
      memory: 128Mi

¡Así que con un solo comando, puedes tener ambas plataformas implementadas y configuradas automáticamente! Espero que esto sea tan útil para ti como lo fue para mí cuando descubrí e hice este proceso.

Aprende a Escribir Manifiestos YAML de Kubernetes de Manera Más Eficiente

2026-01-142022-07-18 por Alexandre Vazquez

Cuando todos estamos en este nuevo entorno nativo de la nube donde Kubernetes es el rey indiscutible, necesitas aprender a manejar los manifiestos YAML de Kubernetes todo el tiempo. Te convertirás en un experto en secciones de sangría para asegurarte de que esto pueda ser procesado, etc. Pero debemos admitir que es tedioso. Todos los beneficios del despliegue de Kubernetes hacen que el esfuerzo valga la pena, pero incluso con eso, es bastante complejo poder manejarlo.

Es cierto que, para simplificar esta situación, se han lanzado muchos proyectos, como Helm para gestionar plantillas de manifiestos YAML de Kubernetes relacionados o Kustomize diferentes enfoques para llegar al mismo lugar o incluso soluciones específicas para una distribución de Kubernetes como las Plantillas de Openshift. Pero al final, nada de esto puede resolver el problema a nivel primario. Así que necesitas escribir esos archivos manualmente tú mismo.

¿Y cuál es el proceso ahora? Probablemente estés siguiendo uno diferente, pero te contaré mi enfoque. Dependiendo de lo que estoy tratando de crear, trato de encontrar una plantilla disponible para el Manifiesto YAML de Kubernetes que quiero hacer. Esta plantilla puede ser algún recurso previo que ya he creado. Por lo tanto, uso eso como base, podría ser algo generado para alguna carga de trabajo que ya está desplegada (¡qué bueno que Lens ha existido para simplificar la gestión de cargas de trabajo de Kubernetes en ejecución! Si no conoces Lens, por favor echa un vistazo a este artículo) o si no tienes nada a mano, buscas en Google algo similar probablemente en la documentación de Kubernetes, stack overflow o el primer recurso razonable que Google te proporcione.

Y después de eso, el enfoque es el mismo. Vas a tu Editor de Texto, VS Code en mi caso. Tengo muchos plugins diferentes para hacer este proceso menos doloroso. Muchos linters diferentes validan la estructura del Manifiesto YAML de Kubernetes para asegurarse de que todo esté correctamente sangrado, que no haya etiquetas repetidas o que no falten etiquetas obligatorias en la última versión del recurso, etc.

Las cosas se complican un poco si estás creando un Helm Chart porque en ese caso los linters para YAML no funcionan tan bien y detectan algunos falsos positivos porque no entienden realmente la sintaxis de Helm. También completas tu configuración con algunos linters más para Helm, y eso es todo. Luchas error tras error y cambio tras cambio para tener tu deseado Manifiesto YAML de Kubernetes.

Pero, ¿debería haber una mejor manera de hacer eso? Sí, debería, y esto es lo que herramientas como Monokle intentan proporcionar una mejor experiencia de ese proceso. Veamos cómo funciona. Comenzando con las palabras de su contribuyente:

Monokle es tu amigable interfaz de usuario de escritorio para gestionar manifiestos de Kubernetes. Monokle te ayuda a obtener rápidamente una vista de alto nivel de tus manifiestos y sus recursos contenidos, editar recursos fácilmente sin tener que aprender la sintaxis yaml, comparar recursos con tu clúster, previsualizar y depurar recursos generados con kustomize o Helm, y más.

Monokle te ayuda de las siguientes maneras. En primer lugar, presenta al inicio de tu trabajo un conjunto de plantillas para crear tus Manifiestos YAML de Kubernetes, como puedes ver en la imagen a continuación:

Cuando seleccionas una plantilla, puedes completar los valores requeridos gráficamente sin necesidad de escribir código YAML tú mismo, como puedes ver en la imagen a continuación:

También admite el reconocimiento de recursos de Helm Chart y Kustomize, por lo que verás rápidamente tus gráficos, y puedes editarlos de una manera más moderna incluso gráficamente para algunos de los recursos también:

Permite una buena integración de varias maneras, en primer lugar con OPA para que pueda validar todas las reglas y mejores prácticas que has definido y también puedes conectarte a un clúster en ejecución para ver los recursos desde allí y también ver la diferencia entre ellos si existe para simplificar el proceso y proporcionar más agilidad en el proceso de creación de Manifiestos YAML de Kubernetes

Además de todo eso, Monokle es un componente certificado por la fundación CNCF, por lo que estarás utilizando un proyecto respaldado por la misma fundación que se encarga de Kubernetes en sí, entre otras tareas:

Si deseas descargar Monokle, pruébalo y puedes hacerlo desde su página web: https://monokle.kubeshop.io/ y estoy seguro de que tu rendimiento escribiendo Manifiestos YAML de Kubernetes te lo agradecerá pronto!

Módulos TIBCO BW: 3 cosas que necesitas saber para tener éxito

2026-04-212022-07-15 por Alexandre Vazquez

Los módulos de TIBCO BW son uno de los contenidos más relevantes en tus desarrollos de TIBCO BW. Aprende todos los detalles sobre los diferentes módulos de TIBCO BW disponibles y cuándo usar cada uno de ellos.

TIBCO BW ha evolucionado de varias maneras y se ha adaptado a los últimos cambios de arquitectura. Debido a eso, desde la concepción de la última versión principal, ha introducido varios conceptos que es importante dominar para poder desatar todo el poder que esta notable herramienta te proporciona. Hoy vamos a hablar sobre los módulos.

Cada aplicación de TIBCO BW está compuesta por diferentes módulos que son los componentes que alojan toda la lógica que puedes crear, y eso es lo primero que hay que anotar: Todo tu código y todo lo que haces en tu aplicación pertenecerá a un módulo de TIBCO BW.

Si pensamos en la jerarquía normal de los componentes de TIBCO BW, será algo como la imagen a continuación:

En el nivel superior, tendremos la aplicación; en el segundo nivel, tendremos los módulos, y después de eso, tendremos los paquetes y finalmente, los componentes técnicos como Procesos, Recursos, Clases, Esquemas, Interfaces, etc. Aprende más sobre esto aquí.

Clasificación de Módulos de TIBCO BW

Hay varios tipos de módulos y cada uno de ellos proporciona un caso de uso específico y tiene algunas características asociadas con él.

Módulo de Aplicación: Es el tipo de módulo más importante porque sin él no puedes tener una aplicación. Es el módulo maestro y solo puede haber uno por aplicación. Es donde residirá toda tu lógica principal para esa aplicación.
Módulo Compartido: Es el otro único módulo nativo de BW y su propósito principal, como muestra el nombre, es alojar todo el código y componentes que pueden ser compartidos entre varias aplicaciones. Si tienes experiencia con versiones anteriores de TIBCO BW, puedes pensar en este módulo de TIBCO BW como un reemplazo de una Biblioteca de Tiempo de Diseño (también conocida como DTL) o si tienes experiencia con un lenguaje de programación, una biblioteca que se importa al código. Debido a eso, no tiene una restricción en el número de aplicaciones que pueden usar un módulo compartido y no hay limitación en el número de módulos compartidos que una aplicación de TIBCO BW puede tener.
Módulo OSGI: Este módulo es el que no es nativo de BW y no va a incluir objetos de BW como Procesos, Recursos, etc., y están principalmente concebidos para tener clases Java. Y nuevamente, es más como un módulo auxiliar que también puede ser compartido según sea necesario. Los escenarios habituales para usar este tipo de módulo son definir funciones XPath personalizadas, por ejemplo, o tener código Java compartido entre varias aplicaciones.

Tanto los módulos compartidos como los módulos OSGI pueden definirse como dependencias de Maven y usar el proceso de Maven para publicarlos en un repositorio de Maven y también para ser recuperados de él según la declaración.

Eso proporciona una forma muy eficiente para la distribución y control de versiones de estos componentes compartidos y, al mismo tiempo, ofrece un proceso similar para otros lenguajes de programación como Java, de modo que disminuirá la curva de aprendizaje para ese proceso.

Limitaciones de los Módulos de TIBCO BW

Como ya comentamos, hay algunas limitaciones o características especiales que cada módulo tiene. Debemos ser muy conscientes de ello para ayudarnos a distribuir adecuadamente nuestro código utilizando el tipo correcto de módulos.

Como se comentó, una aplicación solo puede tener un módulo de aplicación de TIBCO BW. Aunque técnicamente es posible tener el mismo módulo de aplicación de BW en más de una aplicación, eso no tiene sentido porque ambas aplicaciones serán las mismas ya que su código principal será el mismo.

Los módulos compartidos de TIBCO BW, por otro lado, no pueden tener componentes de inicio o procesos de activación como parte de su declaración y todos ellos deben residir en el módulo de aplicación de TIBCO BW.

Tanto el módulo de aplicación de TIBCO BW como el módulo compartido de TIBCO BW pueden tener código Java, pero por otro lado, el módulo OSGI puede solo tener código Java y ningún otro recurso de TIBCO BW.

Los módulos compartidos de TIBCO BW pueden exportarse de dos maneras diferentes, como módulos regulares (archivo ZIP con el código fuente) y en formato binario, para ser compartidos entre otros desarrolladores pero no permitiéndoles cambiar o cambiar su vista de los detalles de implementación. Esto todavía se admite por razones de legado, pero la forma recomendada hoy en día para distribuir el software es usando Maven, como se discutió anteriormente.

Casos de Uso de los Módulos de TIBCO BW

Como se comentó, hay diferentes casos de uso para cada uno de los módulos que debido a eso te ayudará a decidir qué componente funciona mejor para cada escenario:

Los módulos compartidos de TIBCO BW cubren todos los componentes estándar necesarios para todas las aplicaciones. Aquí, el caso de uso principal son los componentes del marco o patrones principales que simplifican el desarrollo y homogeneizan. Esto ayuda a controlar capacidades estándar como manejo de errores, auditoría, registro, o incluso comunicación interna, por lo que los desarrolladores solo necesitan centrarse en la lógica de negocio para su caso de uso.
Otro caso de uso para el módulo compartido de TIBCO BW encapsula cualquier cosa compartida entre aplicaciones, como recursos, para conectarse a un backend, por lo que todas las aplicaciones que necesitan conectarse a ese backend pueden importar y evitar la necesidad de rehacer esa parte.
El módulo OSGi es para tener código Java que tiene una relación débil con el código BW, como un componente para realizar una actividad como firmar un documento PDF o integrar con un elemento usando una API nativa de Java para que podamos mantenerlo y evolucionarlo separado del código de TIBCO BW.
Otro caso para el módulo OSGI es definir las funciones XPath personalizadas que necesitarás como parte de tu módulo compartido o tu módulo de aplicación.
El módulo de aplicación de TIBCO BW, por otro lado, solo debe tener código que sea específico para el problema de negocio que estamos resolviendo aquí, moviendo todo el código que pueda ser utilizado para más de una aplicación a un módulo compartido.

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.

Aprende ahora 2 maneras de configurar la reconexión de TIBCO BW EMS

2026-04-212022-06-30 por Alexandre Vazquez

En este artículo vamos a cubrir cómo funciona la reconexión de TIBCO BW EMS y cómo puedes aplicarla en tu aplicación, así como los pros y contras de las diferentes opciones disponibles.

Uno de los principales problemas que todos hemos enfrentado al trabajar en una integración de TIBCO BW y EMS es la parte de la reconexión. Aunque esto es algo que necesitamos en ocasiones mínimas debido a la extrema fiabilidad del servidor TIBCO EMS, puede tener consecuencias graves si no lo tenemos bien configurado.

Pero antes de empezar a hablar sobre las opciones, necesitamos hacer una pequeña explicación de fondo para entender completamente la situación.

Normalmente, hay dos formas que podemos usar para conectar nuestra aplicación TIBCO BW a nuestro servidor TIBCO EMS: Directa y JNDI. Y basado en eso, esto cambiará cómo y dónde necesitamos configurar nuestras propiedades de reconexión.

TIBCO BW + EMS: Conexión Directa

Esto es, como suena, una conexión directa de la aplicación TIBCO BW al servidor EMS en sí, con el listener usado para enviar y recibir mensajes. No hay un componente en el medio, y puedes detectarlo porque en los Recursos de Conexión JMS, se mostrará como “Directo”, y la URL siempre será de la siguiente manera: tcp://servidor: puerto como puedes ver en la imagen a continuación:

TIBCO BW + EMS: Conexión JNDI

Esta es un tipo de conexión diferente, y tiene un componente central comparado con el enlace Directo, como puedes imaginar. En este escenario, en el momento de la conexión, la aplicación TIBCO BW realiza una primera conexión al servidor JNDI que está dentro del servidor TIBCO EMS y busca los detalles de la conexión basándose en una “Fábrica de Conexiones”. Esta fábrica de conexiones tendrá su URL de conexión y propiedades de conexión. La aplicación TIBCO BW recibirá esa información y comenzará a conectarse a ese servidor EMS.

Sabrás que estás usando una Conexión JNDI porque el Tipo de Fábrica de Conexiones ahora mostrará JNDI. Además, requerirás un nombre de recurso adicional, recurso JNDI, y tu URL de conexión será algo como esto tibjmsnaming://servidor:puerto.

Propiedades de Reconexión de TIBCO EMS

Diferentes propiedades gestionan el proceso de reconexión. Esas propiedades afectarán el comportamiento de la biblioteca cliente EMS que reside en la aplicación cliente, en este caso, la aplicación TIBCO BW. Las propiedades controlarán los siguientes aspectos: el número de intentos de conexión, intervalos de tiempo entre ellos y el tiempo de espera del intervalo para considerarlo un intento fallido.

Y tendrás cada una de estas propiedades para el proceso de reconexión y el proceso de conexión. La principal diferencia es que el proceso de conexión solo actuará cuando estés estableciendo una conexión por primera vez (al inicio de la aplicación TIBCO BW). Las configuraciones de reconexión se aplicarán cuando pierdas una conexión previamente establecida.

Las propiedades concretas son las siguientes:

tibco.tibjms.reconnect.attemptcount/tibco.tibjms.connect.attemptcount: Definirá el número de intentos que realizarás cuando se detecte un escenario de reconexión.
tibco.tibjms.reconnect.attemptdelay/tibco.tibjms.connect.attemptdelay: Definirá el intervalo de tiempo entre dos intentos de reconexión.
tibco.tibjms.reconnect.attempts/tibco.tibjms.connect.attempts: Servirá como una combinación de attemptcount y attemptdelay en una versión separada por comas.
tibco.tibjms.reconnect.attempt.timeout/tibco.tibjms.connect.attempt.timeout: Definirá el tiempo de espera para cada uno de los intentos de reconexión, y si se alcanza ese tiempo, la reconexión no se establece; se detectará como un intento fallido.

¿Dónde Configurar las Propiedades de Reconexión?

En el caso de que estemos hablando de una conexión Directa, estas propiedades deben especificarse en la aplicación TIBCO BW, y estas propiedades se establecerán como propiedades JVM.

Por lo tanto, dependiendo de tu modelo de implementación, estas propiedades deberán agregarse al archivo AppNode TRA o a las variables de entorno BW_JAVA_OPS si estamos hablando de una implementación en contenedores.

Por otro lado, si hablamos de una conexión JNDI, estas propiedades se establecerán a nivel de EMS como parte de las propiedades de reconexión de la Fábrica de Conexiones. Esto se puede hacer usando el componente CLI tibemsadmin, poniéndolo directamente en el archivo factories.conf, o incluso usando una herramienta gráfica como gEMS usando la sección de Fábricas para actualizar eso, como se muestra en la imagen a continuación:

Dependiendo del enfoque que sigas, las propiedades se aplicarán en tiempo de ejecución (enfoque gEMS o tibemsadmin) o en el próximo reinicio (factories.conf)

Pros y Contras

Hay diferentes pros y contras al usar un modo de conexión. Basado en las propiedades de reconexión, usar una forma centralizada como el modelo JNDI asegura que todos los componentes que usan esa conexión tendrán las mismas propiedades de reconexión. Si necesitas cambiarlo, no necesitas cambiar todas tus aplicaciones TIBCO BW. Eso puede ser un número de hasta cientos.

Pero, al mismo tiempo, el uso de una forma centralizada proporciona menos flexibilidad que la conexión directa donde puedes decidir los valores específicos para cada aplicación o incluso cuáles necesitan configuración de reconexión y cuáles no.

Supongamos que estás buscando simplicidad y facilidad de gestión. En ese caso, siempre optaré por la conexión basada en JNDI porque proporciona más beneficios en esos aspectos, y la falta de flexibilidad generalmente no se requiere en absoluto.

Si quieres profundizar más en el ecosistema TIBCO, consulta nuestra Guía completa de la plataforma de integración TIBCO donde cubrimos patrones, mejores prácticas y guía de producción.