Alexandre Vazquez, Author At Alexandre Vazquez

Los 4 principales beneficios inesperados de mi vida como corredor

2022-01-252021-02-14 por Alexandre Vazquez

Permíteme guiarte a través de los beneficios

Nunca he sido corredor en mi vida hasta hace poco. Siempre fui un chico de deportes de equipo. Siempre disfruto de la competencia y el trabajo en equipo, así que correr no era lo mío, pero en algún momento, necesitaba hacer algo para cambiar mi vida.

La razón de eso es clara, después de ganar más de 20 kg en mis días de universidad y vida adulta, estaba afectando mi salud tanto física como mentalmente.

Ahora, después de dos maratones, varias medias maratones y muchas carreras de 10k, puedo contarte mi experiencia y especialmente algunos de los beneficios inesperados después de unirme a este movimiento que probablemente no conoces aún si no estás en esto o si ya lo estás, espero que leer esto pueda poner una sonrisa en tu cara.

#1 Tendrás Tu Propio Momento Para Encontrarte A Ti Mismo

Correr es un deporte que puedes practicar por ti mismo y prácticamente en cualquier lugar. Lo único que necesitas para empezar es un par de zapatillas y tu motivación para salir y empezar a correr.

Eso significa que es cuando estás solo en un momento privado con tu propia mente. Descubrí que este es un gran momento para organizar mi cabeza. No solo para liberar todo el estrés de mi vida diaria y abrazar este momento mío para ser más feliz, sino también para ser más saludable.

No tengo una rutina clara respecto a este tema o alguna técnica de meditación que haga. Depende de lo que necesite en cada momento.

Algunos días necesito escuchar música para liberar todo después de un mal día en el trabajo o para cargar mis baterías para comenzar mi día completamente, o necesito escuchar mis podcasts de una manera íntima en la que pueda concentrarme mucho más en su contenido de lo que probablemente pueda hacer en mi vida normal.

Pero otros días, uso ese tiempo para concentrarme en resolver un problema que tengo en el trabajo (cómo resolver este problema de producción, cómo implementar esta característica que no tenía clara, cómo enfocar esta presentación que necesito hacer…) o incluso para pensar en mi vida y metas para el futuro.

#2 Serás Parte De Una Comunidad

Los corredores son parte de la misma comunidad, y nadie puede cambiar eso. Incluso personas como yo que siempre corren solas y no son parte de ningún club de corredores que se reúnen para hacer el entrenamiento definido pertenecen a esta hermandad.

Es una experiencia extraña cuando te levantas para hacer nuestra carrera matutina, y te encuentras por unos segundos con otra persona haciendo lo mismo que tú. Es una conexión extraña que sientes con esa persona. Probablemente incluso lo/la saludes aunque no lo/la conozcas solo porque ambos saben que son parte del mismo club secreto y comparten algo en común.

Esto es aún mejor si te unes a otras comunidades de corredores como Publicaciones de Corredores, Podcast o Club de Corredores, como estaba diciendo. No importa el ritmo que tengas o cuántas maratones hayas hecho. Tan pronto como te pongas las zapatillas y salgas a la carretera, eres parte del club. Te has unido a la fuerza.

#3 Sentirás El Espíritu De Competencia

No hay nada comparable con la sensación de correr en un gran evento. Tuve la oportunidad de hacer dos maratones hasta que la pandemia nos detuvo a todos, y fue en Madrid 2019 y Valencia 2019, y la experiencia fue la mejor de mi vida. Todo el público apoyándote todo el camino, todos los otros corredores sufriendo contigo y al mismo tiempo disfrutando cada uno de los km desde el inicio hasta el final.

Toda la gente que encuentras cada 10 km te encuentras cada domingo por la mañana cuando el resto de la gente apenas se está levantando y preparando su café, y tú estás en la carretera tratando de superar tu mejor marca personal.

Porque cada vez que corres, estás tratando de superarte. Estás tratando de ser la mejor versión de ti mismo, lo que te ayuda en todos los aspectos de tu vida.

#4 Encontrarás Otra Forma De Descubrir La Ciudad

Usualmente hago dos tipos de sesiones de entrenamiento dependiendo de mi horario y lo que mi cuerpo y mente están demandando para esa sesión. Algunas de ellas que son entrenamientos específicos (series, fartlek, etc.) requieren hacerse en un lugar específico, pero la mayoría del tiempo, solo corro sin la necesidad de estar en un lugar específico y me ayuda a descubrir la ciudad de una manera muy diferente.

Sigo lo que llamo “el camino de las luces verdes”, así que empiezo sin un itinerario específico en mente. Sigo las “luces verdes” en el paso de peatones porque odio detenerme cuando estoy corriendo, así que eso me hace correr por calles en las que nunca he estado (es increíble lo poco que conoces de una ciudad en la que vives) o si estás en otra ciudad por razones de ocio o negocios, es una manera increíble de descubrir una ciudad de una manera muy diferente para abrazarla completamente y conectarte con ella y sentir su alma de una manera muy diferente.

Resumen

Espero que estos puntos destacados siembren dentro de ti si estabas pensando en darle una oportunidad a la Vida de Corredor, y probablemente en este momento estás mirando las zapatillas que tienes en tu armario esperando ser parte de tu rutina desde ahora. Y si ya eres un Corredor, espero que disfrutes y tal vez estés de acuerdo con algunos de estos como los grandes beneficios que usualmente no se mencionan cuando leemos sobre los beneficios de correr.

3 herramientas inusuales para aumentar tu productividad como desarrollador

2022-09-152021-01-21 por Alexandre Vazquez

Una lista no-VS Code para ingenieros de software

Este no va a ser uno de esos artículos sobre herramientas que pueden ayudarte a desarrollar código más rápido. Si estás interesado en eso, puedes revisar mis artículos anteriores sobre extensiones de VS Code, linters y otras herramientas que hacen tu vida como desarrollador más fácil.

Mi trabajo no solo trata sobre desarrollo de software, sino también sobre resolver problemas que tienen mis clientes. Aunque sus problemas pueden estar relacionados con el código, pueden ser un error de operación o incluso un problema de diseño.

Usualmente tiendo a definir mi rol como un llanero solitario. Salgo sin saber a qué me enfrentaré, y necesito estar listo para adaptarme, resolver el problema y hacer felices a los clientes. Esta experiencia me ha ayudado a desarrollar una cadena de herramientas que es importante para hacer ese trabajo.

¡Vamos a sumergirnos!

1. MobaXterm

MobaXterm free Xserver and tabbed SSH client for Windows

The ultimate toolbox for remote computing – includes X server, enhanced SSH client and much more!

Esta es la mejor herramienta para gestionar diferentes conexiones a diferentes servidores (acceso SSH para un servidor Linux, RDP para un servidor Windows, etc.). Aquí están algunas de sus características clave:

Reenvío de puertos SSH gráfico para esos casos en los que necesitas conectarte a un servidor al que no tienes acceso directo.
Gestión de identidades fácil para guardar las contraseñas de los diferentes servidores. Puedes organizarlas jerárquicamente para facilitar el acceso, especialmente cuando necesitas acceder a tantos servidores para diferentes entornos e incluso diferentes clientes.
Conexión automática SFTP cuando te conectas a un servidor SSH. Te permite descargar y subir archivos tan fácilmente como arrastrar archivos allí.
Reenvío X11 automático para que puedas lanzar aplicaciones gráficas desde tus servidores Linux sin necesidad de configurar nada o usar otros servidores X como XMing.

2. Beyond Compare

Scooter Software: Home of Beyond Compare

Beyond Compare is a multi-platform utility that combines directory compare and file compare functions in one package. Use it to manage source code, keep directories in sync, compare program output, etc.

Hay tantas herramientas para comparar archivos, y creo que he usado todas ellas — desde aplicaciones independientes como WinMerge, Meld, Araxis, KDiff, y otras hasta extensiones para editores de texto como VS Code y Notepad++.

Sin embargo, ninguna de ellas puede compararse con la única e inigualable Beyond Compare.

Conocí Beyond Compare cuando comencé a trabajar en ingeniería de software en 2010, y es una herramienta que me acompaña en cada proyecto que tengo. La uso todos los días. Entonces, ¿qué hace que esta herramienta sea diferente del resto?

Es simplemente la mejor herramienta para hacer cualquier comparación porque no solo compara texto y carpetas. Lo hace perfectamente, pero al mismo tiempo, también compara archivos ZIP mientras navega por el contenido, archivos JAR, y así sucesivamente. Esto es muy importante cuando queremos verificar si dos archivos JAR que se suben en DEV y PROD son la misma versión de la herramienta o saber si un archivo ZIP tiene el contenido correcto cuando se sube.

Beyond Compare en acción — Beyond Compare 4

3. Editor Vi

welcome home : vim online

Vim is rock stable and is continuously being developed to become even better.
Among its features are:

Este es el más importante — el mejor editor de texto de todos los tiempos — y está disponible prácticamente en cada servidor.

Es un editor de texto de línea de comandos con una gran cantidad de atajos que te permiten ser muy productivo cuando estás dentro de un servidor revisando registros y archivos de configuración para ver dónde está el problema.

Durante mucho tiempo, he tenido una hoja de trucos de Vi impresa para asegurarme de poder dominar los atajos más importantes y así aumentar mi productividad mientras lucho dentro de las líneas enemigas (los servidores del cliente).

Editor de texto Vi — VIM — Vi mejorado, el editor de texto definitivo.

#TIBFAQS: Error al leer el perfil desde [/tmp/tmp/pcf.substvar]

2022-09-152021-01-18 por Alexandre Vazquez

Este es otro post de la serie #TIBFAQS y solo para recordarte de qué se trata todo esto es que puedes enviar tus preguntas sobre problemas o dudas de desarrollo de TIBCO y trato de proporcionar una respuesta aquí para intentar ayudar a la comunidad de desarrolladores de TIBCO allá afuera.

Así que hoy voy a comenzar con uno de los que creo que son los problemas más comunes cuando trabajamos con BusinessWorks Container Edition y estamos desplegando en nuestro entorno objetivo y es un rastro similar a este:

¿Cuál es la causa de este error?

Este error significa que el runtime de BusinessWorks no puede leer y procesar el archivo de propiedades para iniciar la aplicación. Así que eso significa que tu error está relacionado con la configuración de la aplicación y no con la aplicación en sí. Así que, la buena noticia aquí: tu código parece estar bien en este punto.

Como probablemente sabes, todas las aplicaciones de TIBCO BW usan desde hace mucho tiempo un archivo XML para tener los valores de configuración para comenzar. Este es el archivo que en el caso de BusinessWorks Container Edition se almacena en /tmp/tmp/pcf.substvar y se llena de varias fuentes dependiendo de cómo manejes tu configuración.

Como sabes, tienes varias opciones para manejar tu configuración en entornos basados en la nube: Variables de entorno, Mapas de Configuración, Sistemas de Gestión de Configuración como Spring Cloud Config o Consul… Así que es importante que tengas una comprensión clara de lo que estás usando.

Así que el error es que el archivo tiene algo en su contenido que no es válido, porque está mal o porque no puede entenderlo.

Situaciones que pueden provocar este error

Veamos ahora la situación que puede provocar este error y cómo podemos solucionarlo.

1.- Incompatibilidad entre versiones de BW-runtime y EAR

Normalmente, los archivos EAR son compatibles con diferentes runtimes de BusinessWorks, pero esto es cierto cuando el runtime es más actual que el EAR. Así que quiero decir, si genero mi aplicación con BWCE 2.5.0 puedo ejecutarla con runtime 2.5.0, o 2.5.3 o 2.6.0 sin ningún problema, pero si intento ejecutarla con una versión más antigua como 2.4.2 puedo obtener este error porque el archivo EAR tiene algunas «cosas nuevas» que el runtime no puede entender.

Así que es importante validar que la versión del runtime que estás usando es la esperada y actualizarla si ese no es el caso.

2.- Caracteres especiales de XML que necesitan ser escapados

Esta situación solo es cierta en versiones anteriores a la 2.5.0, pero en caso de que estés ejecutando una versión más antigua, también puedes obtener este error porque el valor de tu propiedad tiene un carácter XML que necesita ser escapado. Caracteres como ‘<’ o ‘&’ son los más utilizados para generar este error. Si estás usando una versión más actualizada no necesitas escaparlos porque se escapan automáticamente.

Así que dependiendo de la versión que estés usando, actualiza el valor de tu propiedad en consecuencia.

Resumen

Espero que encuentres esto interesante y si eres uno de los que enfrenta este problema ahora tienes información para no detenerte por este. Si deseas enviar tus preguntas, siéntete libre de usar una de las siguientes opciones:

Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que monitorearé.
Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
Instagram: Puedes enviarme un DM en Instagram a @alexandrev

Servicio AWS Prometheus para Proporcionar Más Disponibilidad a su Solución de Monitoreo

2026-01-142021-01-17 por Alexandre Vazquez

Aprende qué proporciona el Servicio Administrado de Amazon para Prometheus y cómo puedes beneficiarte de él.

El monitoreo es uno de los temas candentes cuando hablamos de arquitecturas nativas de la nube. Prometheus es un proyecto de código abierto graduado de la Cloud Native Computing Foundation (CNCF) y una de las soluciones estándar de la industria cuando se trata de monitorear tu implementación nativa de la nube, especialmente cuando Kubernetes está involucrado.

Siguiendo su propia filosofía de proporcionar un servicio administrado para algunos de los proyectos de código abierto más utilizados pero totalmente integrado con el ecosistema de AWS, AWS lanza una vista previa general (en el momento de escribir este artículo): Servicio Administrado de Amazon para Prometheus (AMP).

Lo primero es definir qué es el Servicio Administrado de Amazon para Prometheus y qué características proporciona. Así que, esta es la definición de Amazon del servicio:

Un servicio de monitoreo totalmente administrado compatible con Prometheus que facilita el monitoreo de aplicaciones en contenedores de manera segura y a escala.

Y me gustaría dedicar algo de tiempo a algunas partes de esta oración.

Servicio totalmente administrado: Entonces, esto será alojado y manejado por Amazon, y solo vamos a interactuar con él usando API como lo hacemos con otros servicios de Amazon como EKS, RDS, MSK, SQS/SNS, y así sucesivamente.
Compatible con Prometheus: Entonces, eso significa que incluso si esta no es una instalación pura de Prometheus, la API será compatible. Así que los clientes de Prometheus que pueden usar Grafana u otros para obtener la información de Prometheus funcionarán sin cambiar sus interfaces.
Servicio a escala: Amazon, como parte del servicio administrado, se encargará de la escalabilidad de la solución. No necesitas definir un tipo de instancia o cuánta RAM o CPU necesitas. Esto será manejado por AWS.

Entonces, eso suena perfecto. Así que puedes pensar que vas a eliminar tu servidor de Prometheus, y comenzará a usar este servicio. Tal vez incluso estés escribiendo algo como helm delete prom… ¡ESPERA ESPERA!

Porque en este punto, esto no va a reemplazar tu servidor local de Prometheus, pero permitirá la integración con él. Así que, eso significa que tu servidor de Prometheus actuará como un recolector para toda la solución de monitoreo escalable que AMP está proporcionando, algo como puedes ver en la imagen a continuación:

Entonces, todavía vas a necesitar un servidor de Prometheus, eso es correcto, pero toda la complejidad se evitará y se aprovechará en el servicio administrado: La configuración de almacenamiento, alta disponibilidad, optimización de API, y así sucesivamente, se te proporcionará directamente.

Ingesta de información en el Servicio Administrado de Amazon para Prometheus

En este momento, hay dos formas de ingresar datos en el Servicio de Prometheus de Amazon:

Desde un servidor de Prometheus existente usando la capacidad y configuración de remote_write, lo que significa que cada serie que es recolectada por el Prometheus local será enviada al Servicio de Prometheus de Amazon.
Usando AWS Distro para OpenTelemetry para integrarse con este servicio usando el Receptor de Prometheus y los componentes Exportador de Escritura Remota de AWS Prometheus para obtener eso.

Resumen

Así que esta es una forma de proporcionar una instalación de nivel empresarial aprovechando todo el conocimiento que AWS tiene al alojar y gestionar esta solución a escala y optimizada en términos de rendimiento. Puedes centrarte en los componentes que necesitas para obtener las métricas ingresadas en el servicio.

Estoy seguro de que este no será el último movimiento de AWS en temas de observabilidad y gestión de métricas. Estoy seguro de que continuarán proporcionando más herramientas a las manos de los desarrolladores y arquitectos para definir soluciones optimizadas tan fácilmente como sea posible.

📚 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.

¿Por qué GraphQL? Se explican 3 beneficios claros

2022-10-102021-01-14 por Alexandre Vazquez

3 beneficios de usar GraphQL en tu API que deberías tener en cuenta.

Todos sabemos que las APIs son el nuevo estándar cuando desarrollamos cualquier pieza de software. Todos los enfoques de paradigma más recientes se basan en una cantidad distribuida de componentes creados con un enfoque colaborativo en mente que necesitan trabajar juntos para proporcionar más valor a todo el ecosistema.

Hablando de la parte técnica, una API se ha convertido en sinónimo de usar REST/JSON para exponer esas APIs como un nuevo estándar. Pero esta no es la única opción incluso en el mundo de solicitud/respuesta sincrónica, y estamos comenzando a ver un cambio en esta selección por defecto de REST como la única opción en esta área.

GraphQL ha surgido como una alternativa que también funciona desde que Facebook lo introdujo en 2015. Durante estos cinco años de existencia, su adopción está creciendo fuera de las paredes de Facebook, pero esto todavía está lejos de los usos del público en general, como muestra el siguiente gráfico de Google Trends.

Pero creo que este es un gran momento para volver a mirar los beneficios que GraphQL puede proporcionar a tus APIs en tu ecosistema. Puedes comenzar un nuevo año introduciendo una tecnología que puede proporcionarte a ti y a tu empresa beneficios claros. Así que, echemos un vistazo a ellos.

Tabla de contenidos

1.- Estilo más flexible para satisfacer las necesidades de diferentes perfiles de clientes.
2.- Enfoque más desacoplado con el proveedor de servicios
3.- Especificación más estructurada y definida
Resumen

1.- Estilo más flexible para satisfacer las necesidades de diferentes perfiles de clientes.

Quiero comenzar este punto con un pequeño salto al pasado cuando se introdujo REST. REST no siempre fue el estándar que usamos para crear nuestra API o Servicios Web, como lo llamábamos en ese momento. Un estándar del W3C, SOAP, era el líder de eso, y REST lo reemplaza, enfocándose en varios puntos.

Sin embargo, el peso del protocolo mucho más ligero que SOAP marca la diferencia, especialmente cuando los dispositivos móviles comienzan a ser parte del ecosistema.

Esa es la situación hoy en día, y GraphQL es un paso adicional en ese enfoque y la perspectiva de ser más flexible. GraphQL permite a cada cliente decidir qué parte de los datos les gustaría usar la misma interfaz para diferentes aplicaciones. Cada uno de ellos seguirá teniendo un enfoque optimizado porque pueden decidir qué les gustaría obtener en cada momento.

2.- Enfoque más desacoplado con el proveedor de servicios

Otro tema importante es la dependencia entre el consumidor de la API y el proveedor. Todos sabemos que diferentes paradigmas como los microservicios se centran en ese enfoque. Nuestro objetivo es obtener tanta independencia como sea posible entre nuestros componentes.

REST no proporciona un gran vínculo entre los componentes, eso es cierto. Aun así, la interfaz está fija al mismo tiempo, por lo que eso significa que cada vez que modificamos esa interfaz agregando un nuevo campo o cambiando uno, podemos afectar al consumidor incluso si no necesitan ese campo para nada.

GraphQL, por su característica de seleccionar los campos que me gustaría obtener, facilita mucho la evolución de la API en sí misma y al mismo tiempo proporciona mucha más independencia para los componentes porque solo los cambios que tienen un impacto claro en los datos que un cliente necesita pueden generar un efecto en ellos, pero el resto es completamente transparente para ellos.

3.- Especificación más estructurada y definida

Uno de los aspectos que definió el auge de REST como un protocolo ampliamente utilizado es la falta de estándares para estructurar y definir su comportamiento. Tuvimos varios intentos usando RAML o incluso solo «muestras como especificación», swagger, y finalmente una especificación OpenAPI. Pero ese tiempo de situación «no estructurada» genera que la API REST pueda hacerse de maneras muy diferentes.

Cada desarrollador o proveedor de servicios puede generar una API REST con un enfoque y filosofía diferentes que generan ruido y es difícil de estandarizar. GraphQL se basa en un Esquema GraphQL que define el tipo gestionado por la API y las operaciones que puedes hacer con él en dos grupos principales: consultas y mutaciones. Eso permite que todas las APIs de GraphQL, sin importar quién las esté desarrollando, sigan la misma filosofía ya que está incluida en el núcleo de la especificación en sí.

Resumen

Después de leer este artículo, probablemente estés diciendo, entonces eso significa que debería eliminar toda mi API REST y comenzar a construir todo en GraphQL. Y mi respuesta a eso es… ¡NO!

El objetivo de este artículo es que seas consciente de los beneficios que diferentes formas de definir API te están proporcionando para que puedas agregarlos a tu cinturón de herramientas, así que la próxima vez que crees una API pienses en estos temas descritos aquí y llegues a una conclusión que sea: mmm creo que GraphQL es la mejor opción para esta situación específica o al revés, no voy a obtener ningún beneficio en esta API específica, así que prefiero usar REST.

La idea es que ahora sepas aplicar a tu caso específico y elegir en base a eso porque nadie mejor que tú para decidir qué es lo mejor para tu caso de uso.

¿Cómo conocer las publicaciones más grandes en Medium para compartir tus artículos?

2022-09-152021-01-13 por Alexandre Vazquez

Sigue estos consejos para seleccionar la publicación adecuada para tu artículo y asegurarte de garantizar el mejor impacto.

Cuando estamos escribiendo un artículo en Medium y nos gustaría compartirlo con nuestra audiencia, todos sabemos que usar una Publicación es la mejor manera de hacerlo. Una Publicación es como un sitio de medios o una revista tradicional que aloja artículos sobre un tema y los comparte con sus suscriptores. Cuanto más grande sea la publicación, más personas serán notificadas de que tu artículo está disponible, y mejor será la oportunidad de que tus artículos se muestren en la página de inicio de los usuarios de Medium. Así que seleccionar la publicación adecuada es crucial en este proceso.

Encuentra los seguidores de cualquier publicación.

Lo primero que necesitamos hacer para conocer el número de seguidores de cada publicación es seleccionar la publicación que nos gustaría verificar. Por ejemplo, voy a usar una de las principales, que es The Innovation. Si vas a su página principal: https://medium.com/the-innovation

No verás el número de seguidores directamente en su barra de menú como se muestra en la imagen a continuación:

Algunas otras publicaciones pueden mostrar su número de seguidores en el menú de la barra superior, pero esto no sucede para todas las publicaciones. Pero aún tienes la opción de conocer el número de seguidores de cada publicación haciendo este pequeño truco. Si tienes la URL principal de una publicación, si agregas /latest a esa URL, estarás en una página que siempre muestra el mismo diseño para todas las publicaciones, y como parte de ese diseño, encontrarás en la barra lateral derecha el número de seguidores:

Así que, ahora puedes verificar el número de seguidores de cada publicación disponible en Medium, y también te ayudará a saber cuánto tiempo ha pasado desde que se publicó su última entrada. Si la publicación no está publicando nada nuevo, tu historia nunca llegará a todos los seguidores que tiene, así que también verifica la fecha de la última entrada disponible en la misma página.

Encuentra las publicaciones más grandes de hoy.

Ahora sabemos cómo conocer el número de seguidores de cada publicación, pero eso requiere verificar publicación por publicación para obtener ese número, y esto es tedioso. Pero aún peor, necesitamos conocer la publicación que nos gustaría verificar, y no creo que nadie en el espacio de Medium conozca todas las publicaciones para asegurarse de haber verificado todas las relevantes. Entonces, ¿cómo podemos hacer eso más rápido y mejor? Fácil. Aquí está el truco mágico que estabas esperando.

Simplemente ve a esta URL: https://medium.com/search/publications?q=*. Esta URL va a enviar todas las publicaciones (* actúa como un comodín que dice «todo»), por lo que se mostrarán todas las publicaciones, y se ordenarán según el número de editores, como puedes ver aquí:

Para mostrar el número de seguidores, tomo los primeros 20 y hago el truco del primer paso para obtener la siguiente tabla:

Encuentra la adecuada para ti

Ahora que tenemos todos los datos en nuestras manos, solo necesitamos seleccionar la adecuada para el artículo que nos gustaría enviar, basado en el tema que estamos cubriendo y la perspectiva y estilo que usamos para generar nuestra historia. Es muy recomendable mirar las pautas del creador que tiene cada publicación para adaptar el contenido a lo que se espera de la audiencia de la publicación. De esa manera, maximizamos nuestro éxito con la audiencia.

Principios SOA que sobrevivieron en la arquitectura nativa de la nube

2022-09-152021-01-12 por Alexandre Vazquez

El mundo del desarrollo ha cambiado mucho, pero eso no significa que todas las cosas no sean válidas. Aprende qué principios debes tener en cuenta.

El mundo cambia rápido, y en TI, cambia aún más rápido. Todos sabemos eso, lo que generalmente significa que necesitamos enfrentar nuevos desafíos y encontrar nuevas soluciones. Ejemplos de ese enfoque son las tendencias que hemos visto en los últimos años: Contenedores, DevSecOps, Microservicios, GitOps, Service Mesh…

Pero al mismo tiempo, sabemos que TI es un ciclo en términos de que los desafíos que enfrentamos hoy son diferentes evoluciones de desafíos que se han abordado en el pasado. El objetivo principal es evitar reinventar la rueda y evitar cometer los mismos errores que las personas antes que nosotros.

Por lo tanto, creo que vale la pena revisar los principios que las Arquitecturas Orientadas a Servicios (SOA) nos proporcionaron en las últimas décadas y ver cuáles son relevantes hoy en día.

Definición de Principios

Utilizaré los principios del libro de Thomas Erl SOA Principles of Service Design y las definiciones que podemos encontrar en el artículo de Wikipedia:

1.- Abstracción de Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios para que la información publicada en un contrato de servicio se limite a lo que se requiere para utilizar efectivamente el servicio.

El objetivo principal detrás de estos principios es que un consumidor de servicios no debe ser consciente del componente particular. La principal ventaja de ese enfoque es que necesitamos cambiar el proveedor de servicios actual. Podemos hacerlo sin afectar a esos consumidores. Esto sigue siendo totalmente relevante hoy en día por diferentes razones:

Comunicación de servicio a servicio: Los Service Meshes y proyectos similares proporcionan capacidades de registro y descubrimiento de servicios basadas en los mismos principios para evitar conocer el pod que proporciona la funcionalidad.
Modo de protección SaaS habilitado: Algunos sistemas backend todavía están aquí para quedarse, incluso si tienen formas más modernas de configurarse como plataformas SaaS. Esa flexibilidad también proporciona una manera más fácil de alejarse o cambiar la aplicación SaaS que proporciona la funcionalidad. Pero toda esa flexibilidad no es real si tienes esa aplicación SaaS totalmente acoplada con el resto de los microservicios y la aplicación nativa de la nube en tu espacio.

2.- Autonomía del Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para proporcionar servicios con mayor independencia de sus entornos de ejecución.

Todos conocemos la importancia del aislamiento de servicios que los patrones de desarrollo nativos de la nube proporcionan basados en las capacidades de los contenedores para proporcionar independencia entre entornos de ejecución.

Cada servicio debe tener su propio contexto de ejecución aislado tanto como sea posible del contexto de ejecución de los otros servicios para evitar cualquier interferencia entre ellos.

Por lo tanto, eso sigue siendo relevante hoy en día, pero alentado por los paradigmas actuales como la nueva forma normal de hacer las cosas debido a los beneficios mostrados.

3.- Ausencia de Estado del Servicio

Principio de diseño que se aplica dentro del paradigma de diseño orientado a servicios, para diseñar servicios escalables separándolos de sus datos de estado siempre que sea posible.

Los microservicios sin estado no mantienen su propio estado dentro de los servicios a través de las llamadas. Los servicios reciben una solicitud, la manejan y responden al cliente que solicita esa información. Si es necesario almacenar alguna información de estado, esto debe hacerse externamente a los microservicios utilizando un almacén de datos externo como una base de datos relacional, una base de datos NoSQL o cualquier otra forma de almacenar información fuera del microservicio.

4.- Composibilidad del Servicio

Diseño de servicios que pueden ser reutilizados en múltiples soluciones que están compuestas por servicios compuestos. La capacidad de recomponer el servicio es idealmente independiente del tamaño y la complejidad de la composición del servicio.

Todos sabemos que la reutilización no es uno de los principios detrás de los microservicios porque argumentan que la reutilización va en contra de la agilidad; cuando tenemos un servicio compartido entre muchas partes, no tenemos una manera fácil de evolucionarlo.

Pero esto se trata más de aprovechar los servicios existentes para crear nuevos que son el mismo enfoque que seguimos con el paradigma de Orquestación y Coreografía de API y la agilidad que proporciona aprovechar los existentes para crear servicios compuestos que cumplan con los objetivos de innovación del negocio.

Resumen

Los paradigmas de desarrollo de aplicaciones nativas de la nube son una evolución suave de los principios existentes. Debemos aprovechar los que aún son relevantes y proporcionar una visión actualizada de ellos y actualizar los que se necesiten.

Al final, en esta industria, lo que hacemos cada día es dar un nuevo paso en el largo viaje que es la historia de la industria, y aprovechamos todo el trabajo que se ha hecho en el pasado, y aprendemos de ello.

#TIBFAQS 2022! ¡La solución a tus preguntas basadas en el desarrollo de TIBCO!

2022-09-142021-01-04 por Alexandre Vazquez

Mejora tu conocimiento sobre la tecnología TIBCO y también resuelve los problemas que enfrentas en tus tareas diarias de desarrollo

Presentando #TIBFAQS: La Solución a Tus Preguntas Basadas en el Desarrollo de TIBCO — Presentando TIBFAQs por Alex Vazquez

Tabla de contenidos

Mejora tu conocimiento sobre la tecnología TIBCO y también resuelve los problemas que enfrentas en tus tareas diarias de desarrollo

¡TIBFAQS está aquí! Este nuevo año me gustaría comenzar varias iniciativas, y espero que puedas acompañarme durante este viaje. Como sabrás, soy un Arquitecto de TIBCO, así que en mis actividades diarias recibo muchas preguntas e inquietudes sobre cómo hacer diferentes cosas con la tecnología TIBCO, desde TIBCO BusinessWorks hasta TIBCO EMS o TIBCO Spotfire.

He notado que algunas de estas preguntas son similares de un cliente a otro, así que me gustaría usar esta plataforma para compartir todo este conocimiento para beneficiarnos en nuestras actividades diarias y usar la tecnología de la manera más eficiente.

1.- ¿Cómo va a funcionar esto?

Utilizaré algunos de los temas comunes que conozco en términos de preguntas de desarrollo de TIBCO y crearé un artículo periódico cubriéndolo con detalle y con una aplicación de muestra que muestre el problema y la solución. Todo el código estará disponible en mi repositorio de GitHub para que lo uses como referencia.

https://github.com/alexandrev

2.- ¿Puedo enviarte mis preguntas?

¡Sí, claro! ¡Eso sería increíble! Como dije, me gustaría crear una comunidad participativa alrededor de estas publicaciones para que todos podamos beneficiarnos de ello. Así que me gustaría ver tus preguntas y para enviármelas puedes hacerlo de las siguientes maneras:

Twitter: Puedes enviarme una mención a @alexandrev en Twitter o un DM o incluso solo usando el hashtag #TIBFAQs que estaré monitoreando.
Email: Puedes enviarme un correo electrónico a alexandre.vazquez en gmail.com con tu pregunta.
Instagram: Puedes enviarme un DM en Instagram a @alexandrev

3.- ¿Dónde va a comenzar esto?

Esto comenzará a finales de enero. La idea es tener al menos un artículo con una periodicidad quincenal, pero eso dependerá mucho del compromiso con esta iniciativa. Cuanto más compartas y hables sobre esta iniciativa con tus compañeros, y cuantas más preguntas me envíes, más artículos crearé.

4.- ¿Qué sigue?

Desde hoy puedes comenzar a enviar tus preguntas y compartir tus comentarios sobre esta iniciativa, y puedes seguir este blog para esperar los artículos que vendrán. ¡Hagámoslo juntos!

CICD Docker: Las 3 principales razones para usar contenedores en tu pipeline de DevSecOps

2026-01-142020-12-30 por Alexandre Vazquez

Mejora el rendimiento y la productividad de tu canalización DevSecOps usando contenedores.

Tabla de contenidos

1.- Solución mucho más escalable
2.- Fácil de mantener y extender
3.- Evitar el bloqueo del Orquestador
Resumen

CICD Docker significa el enfoque que la mayoría de las empresas están utilizando para introducir contenedores también en la fase de construcción y pre-despliegue para implementar una parte de la canalización CICD. Veamos por qué.

DevSecOps es la nueva norma para despliegues a gran escala en grandes empresas para cumplir con el ritmo requerido en los negocios digitales hoy en día. Estos procesos se orquestan utilizando una herramienta de orquestación CICD que actúa como el cerebro de este proceso. Las herramientas habituales para hacer este trabajo son Jenkins, Bamboo, AzureDevOps, GitLab, GitHub.

En el enfoque tradicional, tenemos diferentes servidores de trabajo realizando etapas del proceso DevOps: Código, Construcción, Prueba, Despliegue, y para cada uno de ellos, necesitamos diferentes tipos de herramientas y utilidades para hacer el trabajo. Por ejemplo, para obtener el código, podemos necesitar un git instalado. Para hacer la construcción, podemos confiar en maven o Gradle, y para probar, podemos usar SonarQube, etc.

CICD Docker: 3 Razones para usar Contenedores en tu canalización DevSecOps — Estructura de CICD Docker y la relación entre Orquestador y Trabajadores

Entonces, al final, necesitamos un conjunto de herramientas para desempeñarnos con éxito, y eso también requiere algo de gestión. En los nuevos días, con el auge del desarrollo nativo en la nube y el enfoque de contenedores en la industria, esto también está afectando la forma en que desarrollas tus canalizaciones para introducir contenedores como parte de la etapa.

En la mayoría de los Orquestadores CI, puedes definir una imagen de contenedor para ejecutar como cualquier paso de tu proceso DevSecOps, y déjame decirte que es genial si lo haces porque esto te proporcionará muchos de los beneficios de los que necesitas estar consciente.

1.- Solución mucho más escalable

Uno de los problemas cuando usas un orquestador como el elemento principal en tu empresa, y que está siendo utilizado por muchas tecnologías diferentes que pueden ser de código abierto, propietario, basado en código, desarrollo visual, etc., significa que necesitas gestionar muchas cosas e instalar el software en los trabajadores.

Usualmente, lo que haces es que defines algunos trabajadores para hacer la construcción de algunos artefactos, como la imagen mostrada a continuación:

Eso es genial porque permite la segmentación del proceso de construcción y no requiere que todo el software esté instalado en todas las máquinas, incluso cuando pueden ser incompatibles.

Pero, ¿qué pasa si necesitamos desplegar muchas aplicaciones de uno de los tipos que tenemos en la imagen a continuación, como aplicaciones de TIBCO BusinessWorks? Que estarás limitado según el número de trabajadores que tengan el software instalado para construirlo y desplegarlo.

Con un enfoque basado en contenedores, tendrás todos los trabajadores disponibles porque no se necesita software, solo necesitas extraer la imagen de docker, y eso es todo, así que solo estás limitado por la infraestructura que usas, y si adoptas una plataforma en la nube como parte del proceso de construcción, estas limitaciones simplemente se eliminan. Tu tiempo de comercialización y ritmo de despliegue mejoran.

2.- Fácil de mantener y extender

Si eliminas la necesidad de instalar y gestionar los trabajadores porque se activan cuando los necesitas y se eliminan cuando no son necesarios y todo lo que necesitas hacer es crear una imagen de contenedor que haga el trabajo, el tiempo y el esfuerzo que los equipos necesitan gastar en mantener y extender la solución disminuirán considerablemente.

También la eliminación de cualquier proceso de actualización para los componentes involucrados en los pasos ya que siguen el proceso habitual de imagen de contenedor.

3.- Evitar el bloqueo del Orquestador

Como confiamos en los contenedores para hacer la mayor parte del trabajo, el trabajo que necesitamos hacer para movernos de una solución DevOps a otra es pequeño, y eso nos da el control para elegir en cualquier momento si la solución que estamos usando es la mejor para nuestro caso de uso y contexto o necesitamos movernos a otra más optimizada sin el problema de justificar grandes inversiones para hacer ese trabajo.

Recuperas el control, y también puedes incluso ir a un enfoque de multi-orquestador si es necesario, como usar la mejor solución para cada caso de uso y obtener todos los beneficios de cada uno de ellos al mismo tiempo sin necesidad de luchar contra cada uno de ellos.

Resumen

Todos los beneficios que todos conocemos de los paradigmas de desarrollo nativo en la nube y los contenedores son relevantes para el desarrollo de aplicaciones y otros procesos que usamos en nuestra organización, siendo uno de esos tu canalización y procesos DevSecOps. Comienza hoy haciendo ese viaje para obtener todas esas ventajas en el proceso de construcción y no esperes hasta que sea demasiado tarde. Disfruta tu día. Disfruta tu vida.

Escalado automático de Kubernetes: Aprende a escalar tus implementaciones de Kubernetes de manera dinámica

2026-01-142020-12-29 por Alexandre Vazquez

Descubre las diferentes opciones para escalar tu plataforma según la carga de tráfico que recibas

Cuando hablamos de Kubernetes, siempre estamos hablando de las opciones de flexibilidad que proporciona. Normalmente, uno de los temas que surgen en la discusión son las opciones de elasticidad que vienen con la plataforma, especialmente cuando se trabaja con un proveedor de nube pública. Pero, ¿cómo podemos implementarlo realmente?

Antes de comenzar a mostrar cómo escalar nuestra plataforma Kubernetes, necesitamos hacer un breve repaso de las opciones que están disponibles para nosotros:

Cluster Autoscaler: Cuando la carga de toda la infraestructura alcanza su pico, podemos mejorarla creando nuevos nodos de trabajo para alojar más instancias de servicio.
Horizontal Pod Autoscaling: Cuando la carga para un pod específico o conjunto de pods alcanza su pico, desplegamos una nueva instancia para asegurar que podemos tener la disponibilidad global que necesitamos.

Veamos cómo podemos implementar esto usando uno de los servicios gestionados de Kubernetes más populares, los Servicios de Kubernetes Elásticos (EKS) de Amazon.

Configuración

Lo primero que vamos a hacer es crear un clúster con un solo nodo de trabajo para demostrar fácilmente el comportamiento de escalabilidad. Y para hacerlo, vamos a usar la herramienta de línea de comandos eksctl para gestionar fácilmente un clúster EKS.

Para poder crear el clúster, lo haremos con el siguiente comando:

eksctl create cluster --name=eks-scalability --nodes=1 --region=eu-west-2 --node-type=m5.large --version 1.17 --managed --asg-access

Después de unos minutos, tendremos nuestro propio clúster de Kubernetes con un solo nodo para desplegar aplicaciones sobre él.

Ahora vamos a crear una aplicación de muestra para generar carga. Vamos a usar TIBCO BusinessWorks Application Container Edition para generar una aplicación simple. Será una API REST que ejecutará un bucle de 100,000 iteraciones actuando como un contador y devolverá un resultado.

Aplicación de muestra de BusinessWorks para mostrar las opciones de escalabilidad

Y utilizaremos los recursos disponibles en este repositorio de GitHub:

GitHub – alexandrev/testeks

Contribute to alexandrev/testeks development by creating an account on GitHub.

Construiremos la imagen del contenedor y la subiremos a un registro de contenedores. En mi caso, voy a usar mi instancia de Amazon ECR para hacerlo, y usaré los siguientes comandos:

docker build -t testeks:1.0 .
docker tag testeks:1.0 938784100097.dkr.ecr.eu-west-2.amazonaws.com/testeks:1.0
docker push 938784100097.dkr.ecr.eu-west-2.amazonaws.com/testeks:1.0

Y una vez que la imagen esté subida al registro, desplegaremos la aplicación sobre el clúster de Kubernetes usando este comando:

kubectl apply -f .testeks.yaml

Después de eso, tendremos nuestra aplicación desplegada allí, como puedes ver en la imagen a continuación:

Imagen desplegada en el clúster de Kubernetes

Entonces, ahora podemos probar la aplicación. Para hacerlo, haré que el puerto 8080 esté disponible usando un comando de reenvío de puerto como este:

kubectl port-forward pod/testeks-v1-869948fbb-j5jh7 8080:8080

Con eso, puedo ver y probar la aplicación de muestra usando el navegador, como se muestra a continuación:

Probador de Swagger UI para la aplicación de muestra de Kubernetes

Escalado automático de pods horizontales

Ahora, necesitamos comenzar a definir las reglas de escalado automático, y comenzaremos con la regla de Escalado Automático de Pods Horizontales (HPA). Necesitaremos elegir el recurso que nos gustaría usar para escalar nuestro pod. En esta prueba, usaré la utilización de CPU para hacerlo, y usaré el siguiente comando:

kubectl autoscale deployment testeks-v1 --min=1 --max=5 --cpu-percent=80

Ese comando escalará el conjunto de réplicas testeks de una (1) instancia a cinco (5) instancias cuando el porcentaje de utilización de CPU sea superior al 80%.

Si ahora verificamos el estado de los componentes, obtendremos algo similar a la imagen a continuación:

Definición de regla HPA para la aplicación usando la utilización de CPU como la métrica clave

Si verificamos la columna TARGETS, veremos este valor: <unknown>/80%. Eso significa que el 80% es el objetivo para activar las nuevas instancias y el uso actual es <unknown>.

No tenemos nada desplegado en el clúster para obtener las métricas de cada uno de los pods. Para resolver eso, necesitamos desplegar el Servidor de Métricas. Para hacerlo, seguiremos la documentación de Amazon AWS:

Installing the Kubernetes Metrics Server – Amazon EKS

The Kubernetes Metrics Server is an aggregator of resource usage data in your cluster, and it is not deployed by default in Amazon EKS clusters. For more information, see Kubernetes Metrics Server on GitHub. The Metrics Server is commonly used by other Kubernetes add ons, such as the

Entonces, ejecutando el siguiente comando, tendremos el Servidor de Métricas instalado.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.3.7/components.yaml

Y después de hacer eso, si verificamos nuevamente, podemos ver que el uso actual ha reemplazado el <unknown>:

Utilización actual de recursos después de instalar el servidor de métricas en el clúster de Kubernetes — Utilización actual de recursos después de instalar el Servidor de Métricas en el clúster de Kubernetes

Si eso funciona, voy a comenzar a enviar solicitudes usando una Prueba de Carga dentro del clúster. Usaré la aplicación de muestra definida a continuación:

Capacidad de Escalado Automático con HPA – Bootcamp de Kubernetes Definitivo

Con el Escalado Automático de Pods Horizontales, Kubernetes escala automáticamente el número de pods en un controlador de replicación, despliegue o conjunto de réplicas basado en la utilización de CPU observada (o, con soporte alfa, en algunas otras métricas proporcionadas por la aplicación).

Para desplegar, usaremos un archivo YAML con el siguiente contenido:

https://gist.github.com/BetterProgramming/53181f3aa7bee7b7e3adda7c4ed8ca40#file-deploy-yaml

Y lo desplegaremos usando el siguiente comando:

kubectl apply -f tester.yaml

Después de hacer eso, veremos que la utilización actual está aumentando. Después de unos segundos, comenzará a girar nuevas instancias hasta que alcance el número máximo de pods definido en la regla HPA.

Aumento de pods cuando la carga excede el objetivo definido en pasos anteriores.

Luego, tan pronto como la carga también disminuya, el número de instancias será eliminado.

Los pods se eliminan tan pronto como la carga disminuye.

Escalado automático de clústeres

Ahora, necesitamos ver cómo podemos implementar el Escalador Automático de Clústeres usando EKS. Usaremos la información que proporciona Amazon:

https://github.com/alexandrev/testeks

El primer paso es desplegar el escalado automático del clúster, y lo haremos usando el siguiente comando:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/autoscaler/master/cluster-autoscaler/cloudprovider/aws/examples/cluster-autoscaler-autodiscover.yaml

Luego ejecutaremos este comando:

kubectl -n kube-system annotate deployment.apps/cluster-autoscaler cluster-autoscaler.kubernetes.io/safe-to-evict=”false”

Y editaremos el despliegue para proporcionar el nombre actual del clúster que estamos gestionando. Para hacer eso, ejecutaremos el siguiente comando:

kubectl -n kube-system edit deployment.apps/cluster-autoscaler

Cuando tu editor de texto predeterminado se abra con el contenido del texto, necesitas hacer los siguientes cambios:

Establece el nombre de tu clúster en el marcador de posición disponible.
Agrega estas propiedades adicionales:

- --balance-similar-node-groups
- --skip-nodes-with-system-pods=false

Ediciones de despliegue necesarias para configurar el Escalador Automático de Clústeres

Ahora necesitamos ejecutar el siguiente comando:

kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=eu.gcr.io/k8s-artifacts-prod/autoscaling/cluster-autoscaler:v1.17.4

Lo único que queda es definir la política de AutoScaling. Para hacerlo, usaremos el portal de Servicios de AWS:

Ingresa a la página de servicio EC en la región en la que hemos desplegado el clúster.
Selecciona las opciones de Grupo de Auto Scaling.
Selecciona el Grupo de Auto Scaling que se ha creado como parte del proceso de creación del clúster EKS.
Ve a la pestaña de Escalado Automático y haz clic en el botón Agregar Política disponible.

Opción de política de escalado automático en la consola de servicio EC2

Luego deberíamos definir la política. Usaremos la utilización promedio de CPU como la métrica y estableceremos el valor objetivo en 50%:

Diálogo de creación de política de escalado automático

Para validar el comportamiento, generaremos carga usando el probador como lo hicimos en la prueba anterior y validaremos la carga del nodo usando el siguiente comando:

kubectl top nodes

Ahora desplegamos el probador nuevamente. Como ya lo tenemos desplegado en este clúster, necesitamos eliminarlo primero para desplegarlo nuevamente:

kubectl delete -f .tester.yaml
kubectl apply -f .tester.yaml

Tan pronto como comience la carga, se crearán nuevos nodos, como se muestra en la imagen a continuación:

Después de que la carga termine, volvemos a la situación anterior:

kubectl top nodes mostrando cómo los nodos han sido escalados hacia abajo

Resumen

En este artículo, hemos mostrado cómo podemos escalar un clúster de Kubernetes de manera dinámica tanto a nivel de nodo de trabajo usando la capacidad de Escalador Automático de Clústeres como a nivel de pod usando el Escalador Automático de Pods Horizontales. Eso nos da todas las opciones necesarias para crear un entorno verdaderamente elástico y flexible capaz de adaptarse a las necesidades de cada momento con el enfoque más eficiente.