Programming Archives - Página 2 De 3

Temas Avanzados de Kubernetes: Contenedores de Inicialización

2026-01-142021-10-26 por Alexandre Vazquez

Descubre cómo los Init Containers pueden proporcionar capacidades adicionales a tus cargas de trabajo en Kubernetes

Hay muchos nuevos desafíos que vienen con el nuevo patrón de desarrollo de una manera mucho más distribuida y colaborativa, y cómo gestionamos las dependencias es crucial para nuestro éxito. Kubernetes y las distribuciones dedicadas se han convertido en el nuevo estándar de implementación para nuestra aplicación nativa de la nube y proporcionan muchas características para gestionar esas dependencias. Pero, por supuesto, el recurso más habitual que utilizarás para hacer eso son las sondas. Kubernetes proporciona diferentes tipos de sondas que permitirán a la plataforma conocer el estado de tu aplicación. Nos ayudará a saber si nuestra aplicación está «viva» (sonda de vivacidad), ha sido iniciada (sonda de inicio) y si está lista para procesar solicitudes (sonda de preparación).

Las sondas de Kubernetes son la forma estándar de hacerlo, y si has implementado alguna carga de trabajo en un clúster de Kubernetes, probablemente hayas usado una. Pero hay ocasiones en las que esto no es suficiente. Eso puede ser porque la sonda que te gustaría hacer es demasiado compleja o porque te gustaría crear algún orden de inicio entre tus componentes. Y en esos casos, confías en otra herramienta: los Init Containers. Los Init Containers son otro tipo de contenedor en el que tienen su propia imagen que puede tener cualquier herramienta que puedas necesitar para establecer los diferentes chequeos o sondas que te gustaría realizar. Tienen las siguientes características únicas:

Los init containers siempre se ejecutan hasta completarse.
Cada init container debe completarse con éxito antes de que comience el siguiente.

¿Por qué usarías init containers?

#1 .- Gestionar Dependencias

El primer caso de uso para utilizar init containers es definir una relación de dependencias entre dos componentes como Deployments, y necesitas que uno comience antes que el otro. Imagina la siguiente situación: Tenemos dos componentes: una aplicación web y una base de datos; ambos se gestionan como contenedores en la plataforma. Así que si los implementas de la manera habitual, ambos intentarán comenzar simultáneamente, o el programador de Kubernetes definirá el orden, por lo que podría ser posible que la aplicación web intente comenzar cuando la base de datos no esté disponible. Podrías pensar que eso no es un problema porque para eso tienes una sonda de preparación o de vivacidad en tus contenedores, y tienes razón: el Pod no estará listo hasta que la base de datos esté lista, pero hay varias cosas a tener en cuenta aquí:

Ambas sondas tienen un límite de intentos; después de eso, entrarás en un escenario de CrashLoopBack, y el pod no intentará comenzar de nuevo hasta que lo reinicies manualmente.
El pod de la aplicación web consumirá más recursos de los necesarios cuando sabes que la aplicación no comenzará en absoluto. Así que, al final, estás desperdiciando recursos en el proceso.

Por lo tanto, definir un init container como parte de la implementación de la aplicación web que verifique si la base de datos está disponible, tal vez solo incluyendo un cliente de base de datos para ver rápidamente si la base de datos y todas las tablas están adecuadamente pobladas, será suficiente para resolver ambas situaciones.

#2 .- Optimización de recursos

Una cosa crítica cuando defines tus contenedores es asegurarte de que tienen todo lo que necesitan para realizar su tarea y que no tienen nada que no sea necesario para ese propósito. Así que en lugar de agregar más herramientas para verificar el comportamiento del componente, especialmente si esto es algo para gestionar en momentos específicos, puedes descargar eso a un init container y mantener el contenedor principal más optimizado en términos de tamaño y recursos utilizados.

#3.- Precarga de datos

A veces necesitas realizar algunas actividades al inicio de tu aplicación, y puedes separar eso del trabajo habitual de tu aplicación, por lo que te gustaría evitar el tipo de lógica para verificar si el componente ha sido inicializado o no. Usando este patrón, tendrás un init container gestionando todo el trabajo de inicialización y asegurando que todo el trabajo de inicialización se haya realizado cuando se ejecute el contenedor principal.

¿Cómo definir un Init Container?

Para poder definir un init container, necesitas usar una sección específica de la sección de especificaciones de tu archivo YAML, como se muestra en la imagen a continuación:

apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
  - name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo ¡La aplicación está en ejecución! && sleep 3600']
initContainers:
  - name: init-myservice
image: busybox:1.28
command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a myservice; sleep 2; done"]
  - name: init-mydb
image: busybox:1.28
command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo esperando a mydb; sleep 2; done"]

Puedes definir tantos Init Containers como necesites. Sin embargo, notarás que todos los init containers se ejecutarán en secuencia como se describe en el archivo YAML, y un init container solo puede ejecutarse si el anterior se ha completado con éxito.

Resumen

Espero que este artículo te haya proporcionado una nueva forma de definir la gestión de tus dependencias entre cargas de trabajo en Kubernetes y, al mismo tiempo, también otros grandes casos de uso donde la capacidad del init container puede aportar valor a tus cargas de trabajo.

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

AccessModes facilita el camino para ejecutar cargas de trabajo con estado en la plataforma Kubernetes

2026-01-142021-10-04 por Alexandre Vazquez

Los AccessModes de Kubernetes proporcionan mucha flexibilidad sobre cómo los diferentes pods pueden acceder a los volúmenes compartidos

Todas las empresas se están moviendo hacia una transformación, cambiando las cargas de trabajo actuales en servidores de aplicaciones que se ejecutan en máquinas virtuales en un centro de datos hacia una arquitectura nativa de la nube donde las aplicaciones se han descompuesto en diferentes servicios que se ejecutan como componentes aislados utilizando contenedores y gestionados por una plataforma basada en Kubernetes. Comenzamos con los casos de uso y cargas de trabajo más fáciles, moviendo nuestros servicios en línea, principalmente API REST que funcionan en modo de balanceo de carga, pero los problemas comenzaron cuando movimos otras cargas de trabajo para seguir el mismo camino de transformación. La plataforma Kubernetes no estaba lista en ese momento. La mayoría de sus mejoras se han realizado para admitir más casos de uso. ¿Significa eso que la API REST es mucho más nativa de la nube que una aplicación que requiere una solución de almacenamiento de archivos? ¡Absolutamente no! Estábamos confundiendo diferentes cosas. Los patrones nativos de la nube son válidos independientemente de esas decisiones. Sin embargo, es cierto que en el camino hacia la nube e incluso antes, hubo algunos patrones que intentamos reemplazar, especialmente los basados en archivos. Pero esto no es por el uso del archivo en sí. Era más sobre el enfoque por lotes que estaba estrechamente relacionado con el uso de archivos que intentamos reemplazar por varias razones, como las siguientes:

El enfoque en línea reduce el tiempo de acción: las actualizaciones y notificaciones llegan más rápido al objetivo, por lo que los componentes están actualizados.
Las soluciones basadas en archivos reducen la escalabilidad de la solución: generas una dependencia con un componente central que tiene una solución de escalabilidad más compleja.

Pero este camino se está facilitando, y la última actualización en ese viaje fueron los Access Modes introducidos por Kubernetes. El Access Mode define cómo los diferentes pods interactuarán con un volumen persistente específico. Los modos de acceso son los que se muestran a continuación.

ReadWriteOnce — el volumen puede montarse como lectura-escritura por un solo nodo

ReadOnlyMany — el volumen puede montarse como solo lectura por muchos nodos.

ReadWriteMany — el volumen puede montarse como lectura-escritura por muchos nodos

ReadWriteOncePod — el volumen puede montarse como lectura-escritura por un solo Pod. Esto solo es compatible con volúmenes CSI y Kubernetes versión 1.22+.

Puedes definir el modo de acceso como una de las propiedades de tus PVs y PVCs, como se muestra en el ejemplo a continuación:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
 name: single-writer-only
spec:
 accessModes:
 - ReadWriteOncePod # Permitir solo a un único pod acceder a single-writer-only.
 resources:
 requests:
 storage: 1Gi

Todo esto nos ayudará en nuestro camino para que todos nuestros diferentes tipos de cargas de trabajo logren todos los beneficios de la transformación digital y nos permita, como arquitectos o desarrolladores, elegir el patrón correcto para nuestro caso de uso sin estar restringidos en absoluto.

Enfrentémoslo: ¡Los mejores desarrolladores no están en Twitch o YouTube!

2022-05-072021-09-19 por Alexandre Vazquez

Los creadores de contenido están educando a los desarrolladores junior en plataformas sociales que probablemente idealizan su visión incluso cuando no son los mejores de su clase.

Estamos viviendo un momento de máxima exposición a la creación de contenido con temas de desarrollo de software. La última noticia sobre este tema es la creación de una sección específica sobre Canales de Desarrollo de Software en la popular plataforma de streaming Twitch:

Twitch introduces new “Software & Game Development” streaming category, boosting gamedev content discoverability | Game World Observer

Twitch announced that it’s introducing new Software & Game Development streaming category to improve the discoverability of content for devs.

Y eso es solo una etapa adicional en la tendencia que estamos viendo en los últimos años donde el contenido creado y las personas que invierten su tiempo en compartir su conocimiento en internet están explotando.

Prácticamente puedes encontrar un Canal en Vivo que te enseñará o compartirá contigo mucho conocimiento y experiencia sobre todos los temas relacionados con el desarrollo de software. No importa qué tema estés buscando, lo tendrás allí. Por ejemplo, hoy más temprano fui. Encontré los siguientes canales en vivo: Creando un MMO desde cero, Desarrollo de Maya, Programación en Java, Programación en GoLang, Programación de CMS usando Django y Python, y mucho más.

Esto es algo grandioso. Vivimos en una era donde tenemos contenido de gran calidad a nuestra disposición, especialmente en nuestra industria, que nos ayudará a mejorar nuestras habilidades y base de conocimientos. Todos estos creadores de contenido son los principales contribuyentes a eso. Y esos están aumentando la popularidad de los mejores creadores de contenido alcanzando niveles sobresalientes.

Pero esa situación también está creando la circunstancia de que los desarrolladores junior o simplemente personas que comienzan una nueva habilidad comiencen a pensar que las personas que muestran su visión o experiencia sobre un tema son los mejores desarrolladores en esa área, y eso está muy lejos de la verdad. Así que se está inclinando hacia una situación peligrosa.

Para ser claro: Los Creadores de Contenido no suelen ser Grandes Desarrolladores. Normalmente son desarrolladores regulares con habilidades de comunicación impresionantes. Y eso es más importante con una voluntad de compartir lo que saben con su audiencia. Incluso que están ganando dinero con esto, para ser justos, tienen una determinación inequívoca de desempeñar un papel social de compartir el conocimiento con el mundo, y eso es muy importante.

Esto no es solo intentar avergonzar a los creadores de contenido por su calidad; esto está sucediendo en todas las industrias. El mejor conocimiento compartido no suele ser el mejor de su práctica. Puedes pensar en cualquier tema: Matemáticas, Física, pero también Deportes. ¿Son los mejores narradores de Fútbol los mejores jugadores? No, seguro.

Pero por esta razón, es importante tener en cuenta esto cuando asistimos a esos canales o vemos esos videos que no son los verdaderos expertos, por lo que siempre debes verificar sus declaraciones para asegurarte de que estén alineadas con las mejores prácticas y procesos.

Si te gustaría ver lo que los verdaderos buenos desarrolladores están haciendo, es mucho más fácil encontrarlo cerca de donde reside el código. Usando plataformas como GitHub o SourceForge, los proyectos con más estrellas que proporcionan valor y leyendo sus conversaciones o analizando sus commits, te proporcionaremos una visión mucho más clara de lo que los verdaderos desarrolladores de alto nivel están haciendo.

Otra opción es suscribirse a la lista de correo de esos proyectos donde puedes ver la discusión real de los desarrolladores, los puntos principales que están haciendo y el razonamiento detrás de esas decisiones.

Este es un conocimiento mucho más importante que lo que puedes ver en una sesión en vivo de alguien programando en una plataforma de streaming, pero esto también es parte del proceso porque necesitarás tener la base para estar listo para entender a qué se refiere la discusión y para ese nivel de introducción la forma en que este increíble creador de contenido está compartiendo el conocimiento es la mejor manera para que cualquiera lo entienda y lo asimile.

GraalVM: ¿Cómo mejorar el rendimiento de los microservicios en 2022?

2022-09-122021-08-15 por Alexandre Vazquez

GraalVM proporciona las capacidades para hacer de Java un lenguaje de primera clase para crear microservicios al mismo nivel que Go-Lang, Rust, NodeJS y otros.

GraalVM: Haciendo que los lenguajes JVM sean eficientes para microservicios — Foto de Caspar Camille Rubin en Unsplash

El lenguaje Java ha sido el líder de lenguajes durante generaciones. Prácticamente cada pieza de software ha sido creada con Java: Servidores Web, Sistemas de Mensajería, Aplicaciones Empresariales, Frameworks de Desarrollo, y así sucesivamente. Esta predominancia se ha mostrado en los índices más importantes como el índice TIOBE, como se muestra a continuación:

Pero siempre, Java tiene algunas compensaciones que necesitas hacer. La promesa del código portátil es porque la JVM nos permite ejecutar el mismo código en diferentes sistemas operativos y ecosistemas. Sin embargo, al mismo tiempo, el enfoque del intérprete también proporcionará un poco de sobrecarga en comparación con otras opciones compiladas como C.

Esa sobrecarga nunca fue un problema hasta que entramos en la ruta de los microservicios. Cuando tenemos un enfoque basado en servidores con una sobrecarga de 100–200 MB, no es un gran problema en comparación con todos los beneficios que proporciona. Sin embargo, si transformamos ese servidor en, por ejemplo, cientos de servicios, y cada uno de ellos tiene una sobrecarga de 50 MB, esto comienza a ser algo de lo que preocuparse.

Otra compensación fue el tiempo de inicio, nuevamente la capa de abstracción proporciona un tiempo de inicio más lento, pero en la arquitectura cliente-servidor, eso no era un problema importante si necesitamos unos segundos más para comenzar a atender solicitudes. Sin embargo, hoy en la era de la escalabilidad, esto se vuelve crítico si hablamos de tiempo de inicio basado en segundos en comparación con tiempo de inicio basado en milisegundos porque esto proporciona mejor escalabilidad y un uso más optimizado de la infraestructura.

Entonces, ¿cómo proporcionar todos los beneficios de Java y ofrecer una solución para estas compensaciones que ahora comenzaban a ser un problema? Y GraalVM se convierte en la respuesta a todo esto.

GraalVM se basa en sus propias palabras: “una distribución de JDK de alto rendimiento diseñada para acelerar la ejecución de aplicaciones escritas en Java y otros lenguajes JVM,” que proporciona un proceso de Compilación Anticipada para generar un proceso binario a partir del código Java que elimina la sobrecarga tradicional del proceso de ejecución de la JVM.

En cuanto a su uso en microservicios, este es un enfoque específico que han dado, y la promesa de un inicio alrededor de 50 veces más rápido y un uso de memoria 5 veces menor es simplemente asombrosa. Y es por eso que GraalVM se convierte en la base para frameworks de desarrollo de microservicios de alto nivel en Java como Quarkus de RedHat, Micronaut, o incluso la versión de Spring-Boot potenciada por GraalVM.

Entonces, probablemente te estés preguntando: ¿Cómo puedo empezar a usar esto? Lo primero que necesitamos hacer es ir a la página de lanzamientos de GitHub del proyecto y encontrar la versión para nuestro sistema operativo y seguir las instrucciones proporcionadas aquí:

GraalVM

GraalVM is a high-performance JDK distribution designed to accelerate the execution of applications written in Java and other JVM languages along with suppor...

Releases · graalvm/graalvm-ce-builds

GraalVM CE binaires built by the GraalVM community - graalvm/graalvm-ce-builds

Cuando tengamos esto instalado, es el momento de comenzar a probarlo, y qué mejor manera de hacerlo que creando un servicio REST/JSON y comparándolo con una solución tradicional potenciada por OpenJDK 11.

Para crear este servicio REST de la manera más simple posible para centrarnos en la diferencia entre ambos modos, usaré el Framework Spark Java, que es un framework mínimo para crear servicios REST.

Compartiré todo el código en este repositorio de GitHub, así que si deseas echar un vistazo, clónalo desde aquí:

GitHub - alexandrev/graalvm-sample-rest-service: Sample REST Service Using GraalVM

Sample REST Service Using GraalVM . Contribute to alexandrev/graalvm-sample-rest-service development by creating an account on GitHub.

El código que vamos a usar es muy simple, solo una línea para crear un servicio REST:

Luego, usaremos un plugin de maven de GraalVM para todos los procesos de compilación. Puedes verificar todas las opciones aquí:

GraalVM

GraalVM is a high-performance JDK distribution designed to accelerate the execution of applications written in Java and other JVM languages along with suppor...

El proceso de compilación lleva un tiempo (alrededor de 1–2 min). Sin embargo, necesitas entender que esto compila todo a un proceso binario porque la única salida que obtendrás de esto es un solo proceso binario (nombrado en mi caso rest-service-test) que tendrá todas las cosas que necesitas para ejecutar tu aplicación.

Y finalmente, tendremos un solo binario que es todo lo que necesitamos para ejecutar nuestra aplicación:

Este binario es excepcional porque no requiere ninguna JVM en tu máquina local, y puede comenzar en unos pocos milisegundos. Y el tamaño total del binario es de 32M en disco y menos de 5MB de RAM.

La salida de esta primera aplicación pequeña es sencilla, como viste, pero creo que puedes captar la idea. Pero veámoslo en acción, lanzaré una pequeña prueba de carga con mi computadora con 16 hilos lanzando solicitudes a este endpoint:

Como puedes ver, esto es simplemente increíble, incluso con la falta de latencia ya que esto es solo activado por la misma máquina, estamos alcanzando con un solo servicio una tasa de TPS en 1 minuto de más de 1400 solicitudes/segundo con un tiempo de respuesta de 2ms para cada una de ellas.

¿Y cómo se compara eso con una aplicación normal basada en JAR con el mismo código exactamente? Por ejemplo, puedes ver en la tabla a continuación:

En resumen, hemos visto cómo usando herramientas como GraalVM podemos hacer que nuestros programas basados en JVM estén listos para nuestro entorno de microservicios evitando los problemas normales relacionados con el alto uso de memoria o el tiempo de inicio pequeño que son críticos cuando estamos adoptando una estrategia completamente nativa de la nube en nuestras empresas o proyectos.

Pero, la verdad debe ser dicha. Esto no siempre es tan simple como mostramos en este ejemplo porque dependiendo de las bibliotecas que estés usando, generar la imagen nativa puede ser mucho más complejo y requerir mucha configuración o simplemente ser imposible. Así que no todo está ya hecho, pero el futuro se ve brillante y lleno de esperanza.

Aprende a Mantener Bajo Control el Uso de Disco de tu Entorno Local de Docker

2022-05-062021-07-06 por Alexandre Vazquez

Descubre nuevas opciones que tienes a tu disposición para hacer un uso eficiente del disco en tu instalación de Docker

El auge del contenedor ha sido un cambio de juego para todos nosotros, no solo en el lado del servidor donde prácticamente cualquier nueva carga de trabajo que implementamos se despliega en forma de contenedor, sino también en nuestros entornos locales ocurre el mismo cambio.

Adoptamos contenedores para gestionar fácilmente las diferentes dependencias que necesitamos manejar como desarrolladores. Incluso si la tarea en cuestión no estaba relacionada con contenedores. ¿Necesitas una base de datos en funcionamiento? Usas una versión en contenedor de ella. ¿Necesitas un sistema de mensajería para probar algunas de tus aplicaciones? Inicias rápidamente un contenedor que proporciona esa funcionalidad.

Y tan pronto como no los necesitas, se eliminan, y tu sistema sigue tan limpio como estaba antes de comenzar esta tarea. Pero siempre hay cosas que necesitamos manejar incluso cuando tenemos una solución maravillosa frente a nosotros, y en el caso de un entorno Docker local, el uso del disco es uno de los más críticos.

Este proceso de lanzar cosas nuevas una y otra vez y luego deshacernos de ellas es cierto en cierto modo porque todas estas imágenes que hemos necesitado y todos estos contenedores que hemos lanzado todavía están allí en nuestro sistema esperando una nueva ronda y durante ese tiempo usando nuestros recursos de disco como puedes ver en una imagen actual de mi entorno Docker local con más de 60 GB utilizados para ese propósito.

Lo primero que necesitamos hacer es verificar qué está usando esta cantidad de espacio para ver si podemos liberar algunos de ellos. Para hacer eso, podemos aprovechar el comando docker system df que la CLI de Docker nos proporciona:

Como puedes ver, los 61 GB que están en uso son 20.88 GB por las imágenes que tengo en uso, 21.03 MB solo para los contenedores que he definido, 1.25 GB para los volúmenes locales y 21.07 para la caché de construcción. Como solo tengo activos 18 de las 26 imágenes definidas, puedo reclamar hasta 9.3 GB, que es una cantidad importante.

Si quisiéramos obtener más detalles sobre estos datos, siempre podemos usar la opción verbose como un añadido al comando, como puedes ver en la imagen a continuación:

Entonces, después de obtener toda esta información, podemos proceder y ejecutar una limpieza de tu sistema. Esta actividad eliminará cualquier contenedor e imagen no utilizados que tengas en tu sistema, y para ejecutar eso, solo necesitas escribir esto:

docker system prune -af

Tiene varias opciones para ajustar un poco la ejecución que puedes consultar en la página oficial de Docker :

En mi caso, eso me ayudó a recuperar hasta 40.8 GB de mi sistema, como puedes ver en la imagen a continuación.

Pero si quisieras avanzar un paso más, también puedes ajustar algunas propiedades para considerar dónde estás ejecutando esta limpieza. Por ejemplo, el defaultKeepStorage te ayudará a definir cuánto disco quieres usar para este sistema de caché de construcción para optimizar la cantidad de uso de red que haces al construir imágenes con capas comunes.

Para hacer eso, necesitas tener el siguiente fragmento en tu sección de configuración del motor de Docker, como se muestra en la imagen a continuación:

Espero que todo este proceso de mantenimiento ayude a que tus entornos locales brillen nuevamente y aproveches al máximo sin necesidad de desperdiciar muchos recursos en el proceso.

Apache NetBeans sigue siendo mi opción preferida para el desarrollo en Java

2022-05-062021-06-22 por Alexandre Vazquez

Descubre cuáles son las razones por las que, para mí, Apache NetBeans sigue siendo el mejor IDE de Java que puedes usar

Permíteme empezar desde el principio. Siempre he sido un Desarrollador Java desde mi tiempo en la Universidad. Aunque primero aprendí otro lenguaje de programación menos conocido (Modula-2), rápidamente pasé a Java para hacer todas las diferentes tareas y prácticamente cada tarea en mi camino como estudiante y luego como ingeniero de software.

Siempre estaba buscando el mejor IDE que pudiera encontrar para acelerar mis tareas de programación. La principal opción era Eclipse en la universidad, pero nunca fui fan de Eclipse, y eso se convirtió en un problema.

Si estás en la industria del Software Empresarial, habrás notado que prácticamente todas las herramientas basadas en Desarrolladores están basadas en Eclipse porque su licencia y la comunidad detrás lo hacen la mejor opción. Pero nunca pensé que Eclipse fuera un gran IDE, era demasiado flexible pero al mismo tiempo demasiado complejo.

Así que en ese momento es cuando descubrí NetBeans. Creo que la primera versión que probé fue en la rama 3.x, y Sun Microsystem lo desarrolló en ese momento. Era mucho mejor que Eclipse. De hecho, la cantidad de plugins disponibles no era comparable con Eclipse, pero las cosas que hacía, las hacía increíblemente bien.

Para mí, si necesito declarar por qué en ese momento NetBeans era mejor que Eclipse, probablemente las principales cosas serían estas:

Simplicidad en la Configuración de Ejecución: Aún creo que la mayoría de los IDE de Java hacen las cosas demasiado complejas solo para ejecutar el código. NetBeans simplemente ejecuta sin necesidad de crear una Configuración de Ejecución y configurarla (puedes hacerlo, pero no estás obligado a hacerlo)
Mejor Apariencia: Esto se basa más en una preferencia personal, pero prefiero la configuración predeterminada de NetBeans en comparación con Eclipse.

Así que por eso, NetBeans se convirtió en mi aplicación predeterminada para hacer mi Programación Java, pero Oracle llegó, y las cosas cambiaron un poco. Con la adquisición de Sun Microsystems por parte de Oracle, NetBeans se estancó como muchos otros proyectos de código abierto. Durante años no hubo muchas actualizaciones y progreso.

No es que hayan dejado de lado el producto, pero Oracle tenía un IDE diferente en ese momento, JDeveloper, que era la opción principal. Esto es fácil de entender. Continué siendo leal a NetBeans incluso cuando teníamos otro gran competidor: IntelliJ IDEA.

Esta es la opción elegante, la que la mayoría de los desarrolladores usan hoy en día para la programación en Java, y puedo entender por qué. He intentado varias veces en mi idea tratar de sentir las mismas sensaciones que otros tuvieron, y pude leer los diferentes artículos, y reconozco algunas de las ventajas de la solución:

Mejor rendimiento: Está claro que el tiempo de respuesta del IDE es mejor con IntelliJ IDEA que con NetBeans porque no proviene de un viaje de casi 20 años, y pudo comenzar desde cero y usar enfoques modernos para la GUI.
Menos Recursos de Memoria: Seamos honestos: Todos los IDE consumen toneladas de memoria. Ninguno lo hace genial aquí (a menos que estés hablando de editores de texto con compilador de Java; esa es otra historia). NetBeans de hecho requiere más recursos para funcionar correctamente.

Así que, hice el cambio y comencé a usar la solución de JetBrains, pero nunca me convenció, porque para mí sigue siendo demasiado complejo. Muchas cosas elegantes, pero menos enfoque en las que necesito. O, simplemente porque estaba demasiado acostumbrado a cómo NetBeans hace las cosas, no pude hacer el cambio mental que se requiere para adoptar una nueva herramienta.

Y entonces… cuando todo parecía perdido, algo increíble sucedió: NetBeans fue donado a la Fundación Apache y se convirtió en Apache NetBeans. Parece una nueva vida para la herramienta proporcionando cosas simples como el Modo Oscuro y manteniendo la solución actualizada con el progreso en el Desarrollo de Java.

Así que, hoy, Apache NetBeans sigue siendo mi IDE preferido, y no podría recomendar más el uso de esta increíble herramienta. Y estos son los puntos principales que me gustaría destacar aquí:

Mejor Gestión de Maven: Para mí, la forma y la simplicidad con la que puedes gestionar tu proyecto Maven con NetBeans está fuera de esta liga. Es simple y se enfoca en el rendimiento, agregando una nueva dependencia sin ir al archivo pom.xml, actualizando dependencias sobre la marcha.
Configuración de Ejecución: Nuevamente, esto sigue siendo un diferenciador. Cuando estoy codificando algo rápido debido a un nuevo tipo de utilidad, no me gusta perder tiempo creando configuraciones de ejecución o agregando un plugin maven exec a mi pom.xml para ejecutar el software que acabo de codificar. En su lugar, necesito hacer clic en Ejecutar, un botón verde, y dejar que la magia comience.
No hay necesidad de todo lo demás: Las cosas evolucionan demasiado rápido en el mundo de la programación Java, pero incluso hoy, nunca siento que me falte alguna capacidad o algo en mi IDE NetBeans que podría obtener si me muevo a una alternativa más moderna. Así que, no hay concesiones aquí a este nivel.

Así que, soy consciente de que probablemente mi elección se deba a que tengo una visión sesgada de esta situación. Después de todo, esta ha sido mi solución principal durante más de una década, y simplemente estoy acostumbrado a ella. Pero me considero una persona abierta, y si viera una diferencia clara, no tendría dudas en abandonar NetBeans como lo hice con muchas otras soluciones en el pasado (Evernote, OneNote, Apple Mail, Gmail, KDE Basket, Things, Wunderstling.. )

Así que, si tienes curiosidad por ver cómo ha progresado Apache NetBeans, por favor echa un vistazo a la última versión y dale una oportunidad. O, si sientes que no conectas con la herramienta actual, dale una oportunidad de nuevo. ¡¡¡Quizás tengas la misma visión sesgada que yo!!!

Portainer: Un software visionario y un viaje de evolución

2026-01-272021-06-14 por Alexandre Vazquez

Descubre el estado actual de las primeras interfaces gráficas para contenedores docker y cómo proporciona una solución para las plataformas de contenedores modernas

Quiero comenzar este artículo con una historia que no estoy seguro de que todos ustedes, increíbles lectores, conozcan. Hubo un tiempo en que no había interfaces gráficas para monitorear tus contenedores. Fue hace mucho tiempo, entendiendo mucho tiempo como podemos hacerlo en el mundo de los contenedores. Tal vez esto fue en 2014-2015 cuando Kubernetes estaba en su etapa inicial, y también, Docker Swarm acababa de ser lanzado y parecía la solución más confiable.

Así que la mayoría de nosotros no teníamos una plataforma de contenedores como tal. Simplemente ejecutábamos nuestros contenedores desde nuestras propias laptops o pequeños servidores para empresas de vanguardia usando comandos de docker directamente y sin más ayuda que la herramienta CLI. Como puedes ver, las cosas han cambiado mucho desde entonces, y si te gustaría refrescar esa visión, puedes consultar el artículo compartido a continuación:

Discover Your Perfect Tool for Managing Kubernetes

Maximizing the productivity of working with Kubernetes Environment with a tool for each persona Photo by Christina @ wocintechchat.com on Unsplash We all know that Kubernetes is the default environment for all our new applications we developed we will build. The flavor of that Kubernetes platform can be of different ways and forms, but one thing is […]

Y en ese momento, un proyecto de código abierto proporciona la solución más increíble porque no sabíamos que necesitábamos eso hasta que lo usamos, y esa opción era portainer. Portainer proporciona una interfaz web muy impresionante donde puedes ver todos los contenedores docker desplegados en tu host docker y desplegar como otra plataforma.

Fue el primero y generó un impacto tremendo, incluso generó una serie de otros proyectos que fueron nombrados: el portainer de… como dodo el portainer de la infraestructura de Kubernetes en ese momento.

Pero tal vez te preguntes… ¿y cómo está portainer? ¿sigue siendo portainer una cosa? Sigue vivo y coleando, como puedes ver en su página de proyecto de GitHub: https://github.com/portainer/portainer, con el último lanzamiento a finales de mayo de 2021.

Ahora tienen una versión Business pero aún como Community Edition, que es la que voy a estar analizando aquí con más detalle en otro artículo. Aún así, me gustaría proporcionar algunos aspectos destacados iniciales:

El proceso de instalación sigue el mismo enfoque que los lanzamientos iniciales para ser otro componente de tu clúster. Las opciones para ser utilizadas en Docker, Docker Swarm o Kubernetes cubren todas las soluciones principales que todas las empresas utilizan.

Welcome | Portainer Documentation

Ahora proporciona una lista de plantillas de aplicaciones similar a la lista del Catálogo de Openshift, y también puedes crear las tuyas propias. Esto es muy útil para las empresas que suelen depender de estas plantillas para permitir a los desarrolladores usar un enfoque común de despliegue sin necesidad de hacer todo el trabajo.

Las capacidades de Gestión de Equipos pueden definir usuarios con acceso a la plataforma y agrupar a esos usuarios como parte del equipo para una gestión de permisos más granular.
Soporte multi-registro: Por defecto, se integrará con Docker Hub, pero también puedes agregar tus propios registros y poder extraer imágenes directamente de esos directamente desde la GUI.

En resumen, esta es una gran evolución de la herramienta portainer mientras mantiene el mismo espíritu que todos los antiguos usuarios amaban en ese momento: Simplicidad y Enfoque en lo que un Administrador o Desarrollador necesita saber, pero también agregando más características y capacidades para mantener el ritmo de la evolución en la industria de plataformas de contenedores.

Promtail: Conecta Registros y Métricas en Tu Monitorización

2026-01-192021-06-08 por Alexandre Vazquez

Promtail es la solución cuando necesitas proporcionar métricas que solo están presentes en los rastros de registro del software que necesitas monitorear para proporcionar una plataforma de monitoreo consistente

Es un entendimiento común que tres pilares en el mundo de la observabilidad nos ayudan a obtener una vista completa del estado de nuestras propias plataformas y sistemas: Registros, Trazas y Métricas.

Para proporcionar un resumen de las diferencias entre cada uno de ellos:

Las métricas son los contadores sobre el estado de los diferentes componentes desde una vista técnica y de negocio. Así que aquí podemos ver cosas como el consumo de CPU, el número de solicitudes, el uso de memoria o disco…
Los registros son los diferentes mensajes que cada una de las piezas de software en nuestra plataforma proporciona para entender su comportamiento actual y detectar algunas situaciones no esperadas.
La traza es la diferente información sobre el flujo de solicitudes de extremo a extremo a través de la plataforma con los servicios y sistemas que han sido parte de ese flujo y datos relacionados con esa solicitud concreta.

Tenemos soluciones que afirman abordar todos ellos, principalmente en el software empresarial con Dynatrace, AppDynamics y similares. Y por otro lado, intentamos ir con una solución específica para cada uno de ellos que podamos integrar fácilmente juntos y hemos discutido mucho sobre esas opciones en artículos anteriores.

Pero, algunas situaciones en ese software no funcionan siguiendo este camino porque vivimos en la era más heterogénea. Todos abrazamos, en algún nivel, el enfoque políglota en las nuevas plataformas. En algunos casos, podemos ver que el software está utilizando rastros de registro para proporcionar datos relacionados con métricas u otros asuntos, y aquí es cuando necesitamos confiar en piezas de software que nos ayuden a «arreglar» esa situación, y Promtail hace específicamente eso.

Promtail es principalmente un reenviador de registros similar a otros como fluentd o fluent-bit de CNCF o logstash del stack ELK. En este caso, esta es la solución de Grafana Labs, y como puedes imaginar, esto es parte del stack de Grafana con Loki para ser el «cerebro» que cubrimos en este artículo que te recomiendo que eches un vistazo si aún no lo has leído:

Promtail tiene dos formas principales de comportarse como parte de esta arquitectura, y la primera es muy similar a otras en este espacio, como comentamos antes. Nos ayuda a enviar nuestros rastros de registro desde nuestros contenedores a la ubicación central que principalmente será Loki y puede ser una diferente y proporcionar las opciones habituales para jugar y transformar esos rastros como podemos hacer en otras soluciones. Puedes ver todas las opciones en el enlace a continuación, pero como puedes imaginar, esto incluye transformación, filtrado, análisis, y así sucesivamente.

Stages

Stages Esta seccion es una colección de todas las etapas Sopportas en una tuberá. Parsing etapas: docker: Extraer datos parsendo la linea de log usando la …

Pero lo que hace a promtail tan diferente es solo una de las acciones que puedes hacer, y esa acción es metrics. Metrics proporciona una forma específica de, basado en los datos que estamos leyendo de los registros, crear métricas de Prometheus que un servidor de Prometheus puede recolectar. Eso significa que puedes usar los rastros de registro que estás procesando que pueden ser algo como esto:

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 123

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 191

[2021–06–06 22:02.12] Nueva solicitud recibida para customer_id: 52

Con esta información aparte de enviar esas métricas a la ubicación central para crear una llamada de métrica, por ejemplo: `total_request_count` que será generada por el agente promtail y también expuesta por él y siendo capaz también de usar un enfoque de métricas incluso para sistemas o componentes que no proporcionan una forma estándar de hacer eso como una API de métricas formal.

Y la forma de hacer esto está muy bien integrada con la configuración. Esto se hace con una etapa adicional (así es como llamamos a las acciones que podemos hacer en Promtail) que se llama metrics.

El esquema de esa etapa de métrica es sencillo, y si estás familiarizado con Prometheus, verás lo directo que es desde una definición de métricas de Prometheus a este fragmento:

# Un mapa donde la clave es el nombre de la métrica y el valor es un tipo de
# métrica específico.
metrics:
  [<string>: [ <metric_counter> | <metric_gauge> | <metric_histogram> ] ...]

Así que comenzamos definiendo el tipo de métricas que nos gustaría definir, y tenemos las habituales: contador, gauge o histograma, y para cada uno de ellos, tenemos un conjunto de opciones para poder declarar nuestras métricas como puedes ver aquí para una Métrica de Contador

# El tipo de métrica. Debe ser Counter.
type: Counter

# Describe la métrica.

[description: <string>]

# Define un nombre de prefijo personalizado para la métrica. Si no está definido, el nombre predeterminado «promtail_custom_» será prefijado.

[prefix: <string>]

# Clave del mapa de datos extraídos para usar en la métrica, # por defecto al nombre de la métrica si no está presente.

[source: <string>]

# Los valores de las etiquetas en las métricas son dinámicos, lo que puede causar que las métricas exportadas se vuelvan obsoletas (por ejemplo, cuando un flujo deja de recibir registros). # Para prevenir el crecimiento ilimitado del endpoint /metrics, cualquier métrica que no haya sido actualizada dentro de este tiempo será eliminada. # Debe ser mayor o igual a ‘1s’, si no está definido el valor predeterminado es ‘5m’

[max_idle_duration: <string>]

config: # Si está presente y es verdadero, todas las líneas de registro serán contadas sin # intentar coincidir la fuente con el mapa extraído. # Es un error especificar `match_all: true` y también especificar un `value`

[match_all: <bool>]

# Si está presente y es verdadero, todos los bytes de la línea de registro serán contados. # Es un error especificar `count_entry_bytes: true` sin especificar `match_all: true` # Es un error especificar `count_entry_bytes: true` sin especificar `action: add`

[count_entry_bytes: <bool>]

# Filtra los datos de origen y solo cambia la métrica # si el valor objetivo coincide exactamente con la cadena proporcionada. # Si no está presente, todos los datos coincidirán.

[value: <string>]

# Debe ser «inc» o «add» (insensible a mayúsculas). Si # se elige inc, el valor de la métrica aumentará en 1 por cada # línea de registro recibida que pase el filtro. Si se elige add, # el valor extraído debe ser convertible a un flotante positivo # y su valor se sumará a la métrica. action: <string>

Y con eso, tendrás tu métrica creada y expuesta, solo esperando que un servidor de Prometheus la recolecte. Si te gustaría ver todas las opciones disponibles, toda esta documentación está disponible en la documentación de Grafana Labs que puedes consultar en el enlace:

metrics

metrics stage The metrics stage is an action stage that allows for defining and updating metrics based on data from the extracted map. Note that created …

Espero que encuentres esto interesante y una forma útil de mantener toda tu información de observabilidad gestionada correctamente usando la solución adecuada y proporcionar una solución para estas piezas de software que no siguen tu paradigma.

Mejora tu estrategia de implementación con Canarying en Kubernetes

2026-01-142021-05-04 por Alexandre Vazquez

Ahorra tiempo y dinero en tu plataforma de aplicaciones implementando aplicaciones de manera diferente en Kubernetes.

Venimos de una época en la que implementamos una aplicación utilizando un proceso aparente y lineal. La forma tradicional es más o menos así:

Esperar hasta un fin de semana o algún momento en que la carga sea baja y el negocio pueda tolerar cierta indisponibilidad del servicio.
Programamos el cambio y avisamos a todos los equipos involucrados para que estén listos para gestionar el impacto.
Implementamos la nueva versión y tenemos a todos los equipos durante la prueba funcional que necesitan hacer para asegurarse de que funciona bien, y esperamos a que ocurra la carga real.
Monitoreamos durante las primeras horas para ver si ocurre algo malo, y en caso de que sí, establecemos un proceso de reversión.
Tan pronto como todo va bien, esperamos hasta el próximo lanzamiento en 3-4 meses.

Pero esto ya no es válido. El negocio exige que TI sea ágil, cambie rápidamente y no pueda permitirse hacer ese tipo de esfuerzo de recursos cada semana o, peor aún, cada día. ¿Crees que es posible reunir a todos los equipos cada noche para implementar los últimos cambios? No es factible en absoluto. Entonces, la tecnología avanza para ayudarnos a resolver mejor ese problema, y aquí es donde Canarying vino a ayudarnos.

Introducción a los Despliegues Canary

Los despliegues canary (o simplemente Canarying, como prefieras) no son algo nuevo, y mucha gente ha estado hablando mucho sobre ello:

bliki: CanaryRelease

A canary release occurs when you roll out a new version of some software to a small subset of your user base to see if there are any problems before you make it available to everyone.

Google - Site Reliability Engineering

Release engineering is a term we use to describe all the processes and artifacts related to getting code from a repository into a running production system. Automating releases can help avoid many of the traditional pitfalls associated with release engineering: the toil of repetitive and manual task…

Ha estado aquí por algún tiempo, pero antes no era ni fácil ni práctico implementarlo. Básicamente se basa en implementar la nueva versión en producción, pero aún manteniendo el tráfico apuntando a la versión antigua de la aplicación y solo comienzas a desviar parte del tráfico a la nueva versión.

Basado en ese pequeño subconjunto de solicitudes, monitoreas cómo se desempeña la nueva versión en diferentes niveles, nivel funcional, nivel de rendimiento, etc. Una vez que te sientes cómodo con el rendimiento que está proporcionando, simplemente desvías todo el tráfico a la nueva versión y deprecias la versión antigua.

Los beneficios que vienen con este enfoque son enormes:

No necesitas un gran entorno de pruebas como antes porque puedes hacer algunas de las pruebas con datos reales en producción sin afectar tu negocio y la disponibilidad de tus servicios.
Puedes reducir el tiempo de comercialización y aumentar la frecuencia de los despliegues porque puedes hacerlo con menos esfuerzo y personas involucradas.
Tu ventana de despliegue se ha extendido mucho ya que no necesitas esperar una ventana de tiempo específica, y debido a eso, puedes implementar nuevas funcionalidades con más frecuencia.

Implementando Despliegue Canary en Kubernetes

Para implementar Despliegue Canary en Kubernetes, necesitamos proporcionar más flexibilidad en cómo se enruta el tráfico entre nuestros componentes internos, que es una de las capacidades que se extienden al usar un Service Mesh. Ya discutimos los beneficios de usar un Service Mesh como parte de tu entorno, pero si deseas volver a echar un vistazo, por favor consulta este artículo:

Technology wars: API Management Solution vs Service Mesh

Service Mesh vs. API Management Solution: is it the same? Are they compatible? Are they rivals? Photo by Alvaro Reyes on Unsplash When we talk about communication in a distributed cloud-native world and especially when we are talking about container-based architectures based on Kubernetes platform like AKS, EKS, Openshift, and so on, two technologies generate a lot […]

Tenemos varios componentes tecnológicos que pueden proporcionar esas capacidades, pero así es como podrás crear las rutas de tráfico para implementar esto. Para ver cómo puedes echar un vistazo al siguiente artículo sobre una de las opciones predeterminadas que es Istio:

Integrating Istio with BWCE Applications

Introduction Services Mesh is one the “greatest new thing” in our PaaS environments. No matter if you’re working with K8S, Docker Swarm, pure-cloud with EKS or AWS, you’ve heard and probably tried to know how can be used this new thing that has so many advantages because it provides a lot of options in handling […]

Pero poder enrutar el tráfico no es suficiente para implementar un enfoque completo de despliegue canary. También necesitamos poder monitorear y actuar en base a esas métricas para evitar la intervención manual. Para hacer esto, necesitamos incluir diferentes herramientas para proporcionar esas capacidades: Prometheus es la opción de facto para monitorear cargas de trabajo implementadas en el entorno de Kubernetes, y aquí puedes obtener más información sobre cómo ambos proyectos trabajan juntos.

Kubernetes Service Discovery for Prometheus

In previous posts, we described how to set up Prometheus to work with your TIBCO BusinessWorks Container Edition apps, and you can read more about it here. In that post, we described that there were several ways to update Prometheus about the services that ready to monitor. And we choose the most simple at that […]

Y para gestionar el proceso general, puedes tener una herramienta de Despliegue Continuo para poner algo de gobernanza alrededor de eso usando opciones como Spinnaker o usando alguna de las extensiones para las herramientas de Integración Continua como GitLab o GitHub:

Using Spinnaker for Automated Canary Analysis

Automated canary analysis lets you partially roll out a change then evaluate it against the current deployment to assess its performance.

Resumen

En este artículo, cubrimos cómo podemos evolucionar un modelo de despliegue tradicional para mantener el ritmo de la innovación que los negocios requieren hoy y cómo las técnicas de despliegue canary pueden ayudarnos en ese viaje, y los componentes tecnológicos necesarios para configurar esta estrategia en tu propio entorno.

Descubre tu herramienta perfecta para gestionar Kubernetes

2026-01-142021-04-26 por Alexandre Vazquez

Maximizando la productividad al trabajar con el entorno de Kubernetes con una herramienta para cada persona

Todos sabemos que Kubernetes es el entorno predeterminado para todas nuestras nuevas aplicaciones que desarrollamos y construiremos. El sabor de esa plataforma de Kubernetes puede ser de diferentes maneras y formas, pero una cosa está clara, es complejo. Las razones detrás de esta complejidad son poder proporcionar toda la flexibilidad, pero también es cierto que el proyecto k8s nunca ha puesto mucho esfuerzo en proporcionar una forma sencilla de gestionar tus clústeres y kubectl es el punto de acceso para enviar comandos, dejando esta puerta abierta a la comunidad para proporcionar su propia solución y estas son las cosas que vamos a discutir hoy.

Tablero de Kubernetes: La Opción Predeterminada

El Tablero de Kubernetes es la opción predeterminada para la mayoría de las instalaciones. Es una interfaz basada en la web que es parte del proyecto K8s pero no se despliega por defecto cuando instalas el clúster.

K9S: La opción de CLI

K9S es una de las opciones más comunes para aquellos que aman una interfaz de línea de comandos muy poderosa con muchas opciones a su disposición.

Es una mezcla entre todo el poder de una interfaz de línea de comandos con todas las opciones de teclado a tu disposición con una vista gráfica muy elegante para tener una visión rápida del estado de tu clúster de un vistazo.

Lens — La Opción Gráfica

Lens es una opción de GUI muy vitaminada que va más allá de solo mostrar el estado del clúster de K8S o permitir modificaciones en los componentes. Con integración con otros proyectos como Helm o soporte para el CRD. Proporciona una experiencia muy agradable de gestión de clústeres con soporte para múltiples clústeres también. Para saber más sobre Lens puedes echar un vistazo a este artículo donde cubrimos sus principales características:

Lens Could Be the Tool That You Were Missing to Master Kubernetes-Based Development and Management

Find the greatest way to manage your Kubernetes development cluster Photo by Agence Olloweb on Unsplash. I need to start this article by admitting that I am an advocate of Graphical User Interfaces and everything that provides a way to speed up the way we do things and be more productive. So when we talk […]

Octant — La Opción Web

Octant proporciona una experiencia mejorada en comparación con la opción web predeterminada discutida en este artículo usando el tablero de Kubernetes. Construido para la extensión con un sistema de complementos que te permite extender o personalizar el comportamiento de octant para maximizar tu productividad gestionando clústeres de K8S. Incluyendo soporte para CRD y visualización gráfica de dependencias, proporciona una experiencia increíble.

Resumen

Hemos proporcionado en este artículo diferentes herramientas que te ayudarán durante la importante tarea de gestionar o inspeccionar tu clúster de Kubernetes. Cada una de ellas con sus propias características y cada una de ellas se enfoca en diferentes formas de proporcionar la información (CLI, GUI y Web) para que siempre puedas encontrar una que funcione mejor para tu situación y preferencias.