¿Actualizar el JDK puede reducir nuestra factura de cloud?

¿Actualizar el JDK puede realmente reducir nuestra factura de cloud sin modificar una sola línea del código de la aplicación?

Las versiones modernas del JDK incorporan mejoras importantes dentro de la JVM, pero normalmente hablamos de ellas en términos de implementación, benchmarks o rendimiento. En entornos cloud, mejoras en tiempo de arranque, consumo de CPU, memoria y garbage collection pueden tener otra consecuencia: el costo de infraestructura.

En esta charla exploraremos tres mejoras que actúan en diferentes momentos del ciclo de vida de la JVM:
* JEP 483- Ahead-of-Time Class Loading & Linking, reduciendo trabajo durante el startup;
* JEP 519- Compact Object Headers, reduciendo el footprint de memoria de los objetos Java; y
* JEP 439- Generational ZGC, buscando mayor eficiencia del garbage collector en workloads adecuados.

Mediante experimentos reproducibles mediremos su impacto en startup, CPU, memoria, comportamiento del GC y densidad de workloads, para después conectar esas métricas con la infraestructura que finalmente aparece en nuestra factura de AWS.

También hablaremos de los trade-offs: arrancar más rápido no necesariamente significa consumir menos memoria, y una optimización de la JVM no se convierte automáticamente en ahorro.

El objetivo no es afirmar que actualizar Java mágicamente hace AWS más barato. Queremos responder con datos una pregunta mucho más útil:

¿Cuándo puede un JDK más moderno permitirnos ejecutar el mismo workload Java utilizando menos recursos cloud?

Sin refactoring. Sin reescribir la arquitectura. La misma aplicación, diferentes capacidades de la JVM medidas.

Related material / Previous work

* Java 25 LTS — JEP 519: Compact Object Headers
* https://www.linkedin.com/pulse/java-25-lts-jep-519-compact-object-headers-isaac-ruiz-guerra-gmn0e

OpenTelemetry para gente ocupada.

OpenTelemetry es un proyecto de la CNCF, en concreto es un framework para implementar observabilidad.

El hecho de que sea: "Vendor- and tool- agnostic" a veces en lugar de ayudar a adoptarlo confunde y crea cierta resistencia innecesaria a su difusión.

Está formado por varios componentes, y la intención de la charla es mostrar un repaso didáctico de todos estos componentes.
Mostraremos sus ventajas y algunos casos de estudio para ayudar a promover su entendimiento y en consecuencia su adopción.

Cerraremos con una lista de "siguientes pasos" para los interesados en el tema.
Todo en aproximadamente 30 minutos, ya que, pues es una charla para gente ocupada ;)

OpenTelemetry para todos.

OpenTelemetry es un proyecto de la CNCF, en concreto es un framework para implementar observabilidad.

El hecho de que sea: "Vendor- and tool- agnostic" a veces en lugar de ayudar a adoptarlo confunde y crea cierta resistencia innecesaria a su difusión.

Está formado por varios componentes, y la intención de la charla es mostrar un repaso didáctico de todos estos componentes.
Iniciaremos mostraremos sus ventajas y algunos casos de estudio para ayudar a promover su entendimiento y en consecuencia su adopción.

Continuaremos viendo todos los componentes para poder iniciar con openTelemetry en un proyecto java.

Y cerraremos con una lista de "siguientes pasos" para los interesados en el tema.

Evitando el vendor lock-in en el almacenamiento de tu observabilidad: OpenTelemetry & amigos

OpenTelemetry se ha convertido en el estándar abierto para recolectar métricas, trazas y logs en entornos cloud-native.
Sin embargo, por diseño, no define cómo ni dónde almacenar la información que genera.
Este vacío deja a los equipos frente a una decisión importante: elegir entre soluciones propietarias o construir una capa de almacenamiento abierta, escalable y sostenible.

En esta charla exploraremos cómo cerrar esa brecha con un stack 100 % open source:

A lo largo de la sesión mostraremos:

* Cómo cubrir la capa de almacenamiento que OpenTelemetry no define.
* Cómo diseñar un pipeline completo de observabilidad libre de vendor lock-in.
* Cómo correlacionar métricas, trazas y logs de manera integrada.
* Cómo aplicar estrategias de almacenamiento sostenible y portable.

Cerramos con una demo mostrando que la observabilidad abierta y distribuida no solo es posible, sino práctica.

Esta sesión es una charla técnica (nivel intermedio–avanzado) enfocada en arquitecturas de observabilidad open source.
El contenido es totalmente neutral en cuanto a proveedores y está basado en herramientas CNCF y de código abierto.

Requerimientos técnicos:

* Internet, salida HDMI y audio estándar.

Público objetivo:

Ingenieros de plataforma, DevOps, SREs y desarrolladores que trabajen con observabilidad en entornos cloud o Kubernetes.

Primera presentación pública: KCD México 2026.

Estoy trabajando en un repositorio Github para mostrar paso a paso, con fases, la adopción de este stack.
https://github.com/rugi/OTEL_Parte2/

De trazas a grafos: entendiendo sistemas distribuidos con OpenTelemetry y Neo4j

Una traza puede decirnos qué ocurrió durante una petición. Pero ¿qué pueden decirnos miles de trazas sobre la arquitectura y el comportamiento de todo un sistema distribuido?

Las aplicaciones distribuidas generan continuamente trazas que contienen información valiosa sobre dependencias entre servicios, latencias, errores y caminos de ejecución. OpenTelemetry está estandarizando cada vez más la forma en que recolectamos esta telemetría, pero analizar las relaciones que aparecen entre grandes cantidades de trazas sigue siendo un problema interesante.

¿Qué ocurre si dejamos de observar las trazas únicamente como líneas de tiempo y comenzamos a tratarlas como un grafo?

En esta charla instrumentaremos una pequeña aplicación Java distribuida utilizando OpenTelemetry, recolectaremos trazas reales y transformaremos sus spans y relaciones en un modelo de grafo almacenado en Neo4j.

Una vez que nuestra telemetría se convierte en un grafo podemos comenzar a hacer preguntas diferentes:

¿Qué servicios aparecen con mayor frecuencia en el camino hacia una petición fallida?
¿Cuáles son los caminos de ejecución más frecuentes dentro del sistema?
¿Qué componentes funcionan como dependencias críticas para múltiples servicios?
¿Existen relaciones o patrones de dependencia inesperados escondidos entre miles de trazas?

Mediante consultas Cypher y telemetría real generada por la aplicación, exploraremos cómo el análisis mediante grafos puede complementar el distributed tracing tradicional y ayudarnos a razonar sobre el comportamiento y la topología de sistemas distribuidos.

El objetivo no es reemplazar nuestro stack de observabilidad actual, sino experimentar con una perspectiva diferente sobre la información que ya estamos recolectando.