DEV Community: Israel Blancas

Cómo los perfiles JSON me ayudaron a que la IA me entendiera

Israel Blancas — Wed, 24 Sep 2025 22:39:54 +0000

El otro día, hablando con Carlos Caballero, me comentaba el suplicio que a veces es generar miniaturas para sus vídeos de YouTube. No sé si sabéis, pero Carlos tiene un canal sobre programación y tecnología, y el toque personal, la imagen, es crucial. Me explicaba que, por mucho que se esforzara con los prompts, los resultados que le devolvía la IA a menudo eran genéricos, carentes de la chispa o del estilo visual que él buscaba. No es que las imágenes fueran feas, es que no eran suyas.

Me reconozco en su problema. A menudo, cuando uso una IA generativa, le pido que me escriba un texto sobre algo muy concreto, como alguna documentación sobre OpenTelemetry, y lo que me devuelve es correcto, pero le falta contexto. No sabe que quiero que se enfoque en los problemas que soluciona, no en cómo está implementado. Le falta un mapa, una guía que le diga no solo qué hacer, sino cómo hacerlo para que el resultado sea coherente con lo que busco.

Fue entonces cuando le hablé de la idea que había visto un tweet (si podemos seguir llamándolo así): usar perfiles de contexto JSON (JSON Context Profiles). Lo comenté también en el segundo episodio de “Compila o revienta”. No es una varita mágica, sino una manera mucho más estructurada y eficiente de comunicarnos con la IA. En lugar de una simple instrucción, le damos un archivo de configuración, un pequeño dossier con todas las reglas del juego.

La clave está en ir más allá del prompt simple y crear un perfil con información detallada.

https://medium.com/media/30fb1ca7e4c7007a67c6af00482a8899/href

Un mapa de carretera para la IA

La clave está en ir más allá del prompt simple y crear un perfil con información detallada. Por ejemplo, imagina un archivo JSON que contenga:

"meta" : Aquí defines los parámetros básicos: el idioma, el tono, la longitud del texto o, en el caso de Carlos, el estilo visual (minimalista, con colores vivos, etc.). Le dices a la IA a quién se dirige y cuál es el propósito de su trabajo.
"restrictions" : Aquí pones los límites. "No uses más de 1000 palabras", "no incluyas texto", "los colores principales deben ser el azul y el naranja". Esto evita que la IA se vaya por las ramas.
"data" : Esta es la parte más interesante. En lugar de un simple texto, le proporcionas una estructura de datos. Para las miniaturas de Carlos, por ejemplo, podría ser una lista de conceptos clave, un titular que debe destacar, o los elementos visuales que tienen que aparecer (un ordenador, un logo de Python, una taza de café). Esto obliga a la IA a seguir una estructura de salida específica.

Esto simplifica enormemente el proceso. En lugar de reescribir un prompt larguísimo una y otra vez, solo tienes que cambiar los datos del archivo JSON.

Poniéndolo en práctica

Por ejemplo, si doy a Gemini esta imagen:

Alhambra de Granada

Y le pido al modelo que me genere el JSON Context Profile, obtengo esto de vuelta:

{
  "image_description": "A dusk-time, wide-angle shot of the Alhambra complex in Granada, Spain, with a focus on its architectural details. The image is taken from a lower vantage point, looking up at the complex. The sky is a gradient of blue and purple, with clouds obscuring the tops of the mountains in the background. The Alhambra itself is a collection of various architectural styles. The most prominent feature is a large, rectangular, Renaissance-style palace building on the right, which is the Palace of Charles V. To its left and slightly forward is a large, older, and more fortified structure, likely the Alcazaba, with prominent crenellated walls and towers. In the center, a bell tower rises above the lower buildings, which are a mix of terracotta-colored structures with traditional Spanish tiling and arched windows. The foreground is filled with the dark green foliage of trees, which partially obscure the base of the fortress walls. The buildings are illuminated by warm, yellow-orange light, creating a strong contrast with the cooler tones of the sky and mountains. The lighting suggests that the photo was taken around sunset or just after.",
  "location": "Alhambra, Granada, Spain",
  "time_of_day": "Dusk/Sunset",
  "architectural_styles": [
    "Moorish/Nasrid",
    "Renaissance"
  ],
  "key_features": [
    "Alcazaba fortress",
    "Palace of Charles V",
    "Bell tower",
    "Forested hillside",
    "Mountain range in the background"
  ],
  "dominant_colors": [
    "Terracotta (buildings)",
    "Dark green (trees)",
    "Blue/Purple (sky and mountains)",
    "Yellow/Orange (lighting)"
  ],
  "mood": "Majestic, historic, serene",
  "possible_use_case": "Travel and tourism promotion, historical documentation, photography portfolio"
}

El modelo de IA, al recibir esta información estructurada, tiene una guía clara. Sabe que debe generar una imagen y que debe incluir los elementos visuales y el texto que le has pasado. La probabilidad de que el resultado se ajuste a tus expectativas se dispara.

De hecho, si en una nueva conversación, pedimos que se genere una imagen basada en ese prompt, obtendremos esto:

A la izquierda, la imagen original. A la derecha, la imagen generada desde el JSON Context Profile por Gemini

A partir del JSON, podemos modificarlo y obtener imágenes similares pero con modificaciones. Por ejemplo, puedo cambiar el cielo de la fotografía:

Dependiendo del modelo, esto será más o menos acertado. Además, según la imagen, algunos parámetros aparecerán o desaparecerán: ángulo de la cámara, texto, edificios, número de personas…

También podemos hacerlo utilizando varias fotografías, de forma que podemos pedir a nuestro modelo de confianza un JSON que extraiga el estilo de lo que queremos hacer y nos permita alcanzar los resultados deseados.

https://medium.com/media/7c86c9eba896155bceafd48e65906615/href

Al final, no se trata de convertir a la IA en una mente creativa, sino de usarla como la herramienta inteligente que es. Si le damos las instrucciones adecuadas, de forma precisa y estructurada, el trabajo se vuelve mucho más eficiente y los resultados, más satisfactorios. Y, con suerte, Carlos tendrá miniaturas que no solo sean correctas, sino que realmente le representen.

Creando agentes con ADK

Israel Blancas — Fri, 12 Sep 2025 08:38:40 +0000

¿Alguna vez te has detenido a pensar en el potencial que reside en programas de inteligencia artificial capaces no solo de responder, sino de razonar, planificar y actuar para desentrañar tareas de una complejidad sorprendente? La respuesta, en esencia, se esconde tras la fascinante idea de los Agentes de IA. Y es aquí donde Google, con su recién estrenado Agent Development Kit (ADK), nos allana el camino de una manera notable.

Imagina el ADK como una caja de herramientas indispensable, forjada en Python — sí, ese lenguaje que, con toda probabilidad, ya dominas — . Su propósito no es otro que el de facilitarte la construcción de estos asistentes inteligentes. Con él, serás capaz de insuflar vida a agentes dotados de la capacidad de razonar, de emplear herramientas externas (como buscar información en la vasta red o interactuar con otras API) y de tomar decisiones dinámicas. Todo ello, por supuesto, impulsado por la robustez de los Modelos de Lenguaje Grandes (LLMs), como Gemini.

Si el universo de los agentes de IA te ha atraído siempre, pero la incertidumbre sobre por dónde empezar te ha frenado, este es, sin duda, tu momento. Acompáñame en este recorrido y descubrirás lo asombrosamente sencillo que puede ser erigir tu primer agente.

La esencia de un Agente de IA: ¿Qué lo hace singular?

Piensa en un asistente digital extraordinariamente inteligente. Esa es, en su sentido más puro, la definición de un Agente de IA. Pero, ¿qué elementos lo distinguen de cualquier otro programa? Un agente de IA utiliza un “cerebro” avanzado, como los Modelos de Lenguaje Grandes (LLM) de Google (por ejemplo, Gemini), para entender lo que le pides y encontrar la mejor manera de hacerlo. No se limita a lo que ya sabe, pues puede usar “Herramientas” externas para obtener la información que necesita, ya sea realizando una búsqueda en Google, consultando una base de datos o interactuando con otras aplicaciones. Basándose en su razonamiento y la información que recopila, puede tomar decisiones y ejecutar acciones para cumplir con su objetivo. Incluso para tareas muy complejas, puedes tener un Agente “padre” o principal que coordine a un equipo de sub-agentes , cada uno especializado en una parte del trabajo, como un equipo de especialistas que trabajan juntos, por ejemplo, uno podría escribir un guion, otro buscar imágenes y un tercero unirlos.

Agent Development Kit (ADK) de Google: Desmitificando la creación de agentes

Si la mera idea de construir estos agentes te parece una empresa titánica, respira tranquilo. Google, consciente de ello, ha concebido el Agent Development Kit (ADK) con la clara intención de simplificarnos la existencia. El ADK es un framework de código abierto y gratuito de Google, un compendio de herramientas y librerías que te ayuda a construir, probar, desplegar y administrar tus agentes de IA de una manera más sencilla y organizada. Una de sus virtudes más destacadas reside en su filosofía “code-first” , lo que implica que tus agentes cobran vida a través de la programación directa en Python, otorgándote un dominio total sobre su funcionamiento.

La flexibilidad es otra de sus grandes bazas; no estás constreñido a un único modelo, pues tienes la libertad de optar por Gemini, por otros modelos de Google, o incluso por soluciones de terceros. Una vez que tu agente está listo, puedes ubicarlo en la nube de tu preferencia o en tus propios servidores. Además, el ADK ha sido diseñado para ser interoperable , lo que significa que puede convivir y colaborar sin fricciones con otros frameworks y herramientas populares en el ámbito de la IA. Los agentes en ADK se pueden clasificar en: Agentes LLM (los más adaptables), Agentes de Flujo de Trabajo (para secuencias de tareas predefinidas) y Agentes Personalizados (para un control aún más minucioso).

Los pilares del ADK: Componentes esenciales

Para entender cómo funcionan estos agentes, es útil conocer sus componentes fundamentales. Los Agentes son los ladrillos de la construcción: tenemos el LLMAgent, que es el agente "inteligente" que se apoya en el LLM para tomar decisiones, y los Workflow Agents (Agentes de Flujo de Trabajo), ideales para orquestar tareas paso a paso, de forma predefinida, sin que el LLM tenga que decidir la secuencia. Un buen ejemplo es el LoopAgent, perfecto para repetir pasos. Las Herramientas (Tools) son, por decirlo de algún modo, las "manos" del agente, permitiéndole llevar a cabo acciones como buscar en la web o realizar cálculos. El Estado y output_key definen cómo los agentes se "comunican" entre sí, transfiriéndose información. El Runner es el "motor" que activa y supervisa todo el proceso del agente, mientras que los Servicios se encargan de gestionar la memoria, la conversación (sesión) y los archivos que el agente pueda generar.

Es fundamental que los agentes sigan un estándar, como el Protocolo de Contexto de Modelo (MCP) o el Protocolo de Agente a Agente (A2A), para asegurar su coherencia y facilidad de mantenimiento.

¡Manos a la obra! Nuestro primer agente: un ejemplo práctico

Vamos a construir un agente sencillo para ilustrar el proceso. Nuestro objetivo es crear un agente que genere ideas para YouTube Shorts. Este ejemplo se inspira directamente en los ADK-samples. La arquitectura se compone de un Agente Padre (LoopAgent), encargado de asegurar la ejecución de todos los pasos, y de varios sub-agentes: uno para la escritura del guion (que incorpora una herramienta de búsqueda para enriquecer su contenido), otro para la visualización (que describe las imágenes pertinentes), y un tercero para formatear la información, reuniendo todo el material y presentándolo en formato Markdown.

Para ponerlo en marcha, los primeros pasos son sencillos. Primero, instala el ADK ejecutando pip install google-adk. Luego, configura tus claves de API si vas a trabajar con Gemini, por ejemplo, asegurándote de tenerlas correctamente configuradas. Finalmente, familiarízate con la estructura básica del código en Python y del proyecto en general. Puedes explorar parte del código, como este fragmento:

# --- Llm Agent Workflow ---
youtube_shorts_agent = LlmAgent(
    name="youtube_shorts_agent",
    model="gemini-2.0-flash-001",
    instruction=load_instruction_from_file("shorts_agent_instruction.txt"),
    description="You are an agent that can write scripts, visuals and format youtube short videos. You have subagents that can do this",
    sub_agents=[scriptwriter_agent, visualizer_agent, formatter_agent],
)

Para interactuar con tu agente, tienes dos opciones principales. Para realizar pruebas rápidas directamente en la terminal, utiliza adk run youtube-shorts-assistant. Pero si quieres una visión más detallada, adk web es, sin duda, una herramienta esencial. Te permite lanzar una interfaz web para visualizar paso a paso (mediante eventos) el funcionamiento de tu agente y, si fuera necesario, depurarlo. Al ejecutar adk web, verás una respuesta en la terminal indicando la dirección web a la que debes acceder para interactuar con la interfaz.

En resumen…

El ADK se perfila como una herramienta potente y maleable para construir agentes de IA utilizando Python. Su diseño te brinda un control significativo y simplifica el proceso de desarrollo. Mi consejo es que te animes a experimentar. Puedes encontrar más ejemplos y recursos valiosos en el repositorio de ejemplos del ADK. Para profundizar aún más, no dudes en consultar la documentación oficial y el repositorio principal.

gemini-cli: el nuevo aliado para l@s devs

Israel Blancas — Sun, 07 Sep 2025 22:46:17 +0000

En un mundo donde la inteligencia artificial se ha colado hasta en la sopa –y bendita sea esa sopa, a veces–, es probable que ya te hayas familiarizado con la versión web de Gemini. Esa interfaz pulcra, intuitiva, donde uno teclea una pregunta y, casi por arte de magia, una respuesta aparece por pantalla. Es una maravilla, no cabe duda, para la creatividad, la búsqueda de información o, simplemente, para sacarnos de algún apuro conceptual. Pero, ¿y si te dijera que esa es solo una faceta de la historia? ¿Y si te dijera que el verdadero potencial de interacción con una IA como Gemini podría residir en un lugar mucho menos glamuroso, pero infinitamente más poderoso para quienes pasamos horas frente a un teclado programando o gestionando sistemas?

Aquí es donde entra en juego gemini-cli, una herramienta que, como su nombre indica, lleva el poder del modelo de Google directamente a tu terminal, a esa ventana negra (o del color que le hayas puesto) donde los comandos son el lenguaje universal. La primera pregunta que surge es obvia: ¿para qué querría uno prescindir de la comodidad de una interfaz gráfica para volver a las líneas de comando? Y la respuesta es tan sencilla como profunda: por la integración y la eficiencia.

Mientras la versión web es fantástica para consultas puntuales y flujos de trabajo aislados, la terminal es el corazón de la productividad para desarrolladores, ingenieros de sistemas y cualquier persona que trabaje con código o gestione infraestructuras. Gemini CLI no es solo una “conversación” con la IA; es una herramienta que se integra con tu entorno de trabajo, con tus archivos, con tu lógica de proyecto. Imagina poder pedirle a Gemini que genere un fragmento de código y que, acto seguido, ese código se escriba directamente en el archivo que tienes abierto, o que te ayude a refactorizar una función compleja y los cambios se reflejen al instante en tu base de código. Esta es la diferencia fundamental: la capacidad de operar directamente sobre tu proyecto, manipular archivos, ejecutar comandos y automatizar tareas , todo ello sin salir del flujo de trabajo habitual de la terminal.

No se trata de una mera duplicación de funcionalidades, sino de una extensión lógica. Es el salto de la consulta pasiva a la interacción activa y contextualizada. La IA no solo te dice cómo hacer algo, sino que te ayuda a hacerlo en el mismo lugar donde trabajas. Y en un ámbito como el desarrollo de software, donde cada segundo cuenta y la fricción entre herramientas puede ralentizarlo todo, esta integración se convierte en un verdadero catalizador para la productividad. Es llevar la inteligencia artificial de un mero “consejero” a un “colaborador” directo en tu día a día, en ese espacio que ya dominas: la línea de comandos.

Lo que verdaderamente lo hace atractivo, al menos en un primer contacto, es su accesibilidad. Google ha sido bastante generoso con su nivel gratuito, ofreciendo hasta mil solicitudes diarias, lo que lo convierte en una opción muy tentadora para experimentar sin que el bolsillo se resienta. Además, su naturaleza open-source nos invita a bucear en sus entrañas, comprender cómo funciona y, quién sabe, quizás incluso a contribuir a su evolución. Imagina poder decirle a tu terminal: “Oye, créame un plan de proyecto para esto”, o “Depura esta función”, y que la IA, con un par de comandos, comience a trazar caminos y a sugerir soluciones. Es un paso más hacia esa promesa de un desarrollo asistido, casi simbiótico, con la máquina.

Ahora bien, el ecosistema de herramientas de IA en la terminal no es, ni de lejos, un desierto. Aquí es donde la comparación se vuelve no solo necesaria, sino también reveladora.

Por un lado, tenemos a OpenAI con su “Codex CLI” , una herramienta que emerge como una respuesta directa a la necesidad de llevar los grandes modelos de lenguaje (LLMs) al entorno local. Codex CLI se jacta de ser un agente de codificación ligero, capaz de leer, modificar y ejecutar código en tu máquina. Su énfasis en la seguridad, con la ejecución en entornos aislados y sin acceso a la red por defecto, es un punto a favor que no podemos obviar. Si bien las capacidades son similares en cuanto a la manipulación de archivos y la ejecución de comandos, la filosofía de OpenAI parece centrarse en una interacción aún más agéntica, con la visión de un “ingeniero de software agéntico” que automatice progresivamente tareas complejas de programación. El hecho de que puedas usarlo para refactorizar código, depurar problemas o incluso escribir tests y ejecutarlos, suena a música celestial para cualquier desarrollador.

Y por el otro, Anthropic nos trae sus propuestas con “Claude Code” y “Claude Engineer”. Si bien Claude es conocido por su enfoque en la seguridad y la precisión, sus herramientas de interfaz de línea de comandos no se quedan atrás. “Claude Code” busca integrarse directamente en tu entorno de desarrollo, ofreciendo una serie de herramientas para operaciones de archivo, búsqueda de código y navegación web, todo ello sin la necesidad de servidores adicionales. Por su parte, “Claude Engineer” se presenta como un asistente de IA auto-mejorable, diseñado para crear y gestionar herramientas de IA con Claude 3.5. La promesa aquí es la capacidad de Claude para generar y gestionar sus propias herramientas, expandiendo continuamente sus capacidades a través de la conversación. Es una aproximación más modular, donde la IA no solo te asiste, sino que también construye sus propias extensiones para adaptarse mejor a tus necesidades.

Entonces, ¿cuál elegir?

La verdad es que cada herramienta tiene su matiz, su punto fuerte. Gemini CLI brilla por su integración con el ecosistema de Google y su modelo Gemini, además de una política de uso gratuito bastante generosa. Su capacidad para manejar grandes bases de código y la flexibilidad de las instrucciones personalizadas a través de gemini.md son características a tener en cuenta.

Codex CLI de OpenAI, por su parte, se posiciona como un asistente robusto y seguro, con un enfoque más centrado en la automatización y la interacción directa con el repositorio. La posibilidad de que la IA no solo sugiera cambios, sino que los aplique automáticamente (si así lo configuras), es una muestra de la dirección hacia la que se dirige el desarrollo asistido por IA.

Y las herramientas de Claude, con su énfasis en la creación y gestión de herramientas por parte de la propia IA, abren una puerta a una personalización y una evolución constante que podría ser revolucionaria para aquellos que buscan una IA que no solo resuelva problemas, sino que también se adapte y crezca con ellos.

Y tú… ¿usas ya alguno?

Recursos si estás empezando (o llevas poco)

Israel Blancas — Fri, 08 Nov 2024 10:50:48 +0000

Si estás comenzando en el mundo de la programación, probablemente te hayas dado cuenta de que hay una gran cantidad de recursos disponibles. Tantos, que saber por dónde empezar puede ser un desafío. En este post, quiero ayudarte a encontrar algunos de los mejores recursos gratuitos o de bajo costo para iniciar tu camino en el desarrollo de software.

Antes de enlazarte ningún recurso, me gustaría darte algunos consejos:

1. Entiende a dónde quieres llegar

Define qué quieres lograr con la programación. ¿Te interesa el desarrollo web, aplicaciones móviles, ciencia de datos o inteligencia artificial? Tener un objetivo te ayudará a enfocar tus esfuerzos y elegir los recursos adecuados.

2. Aprende los fundamentos

Antes de sumergirte en tecnologías avanzadas, asegúrate de comprender los conceptos básicos como variables, bucles, funciones y estructuras de datos. Una base sólida facilita el aprendizaje de lenguajes y herramientas más complejas. Además, te facilitará el salto de una tecnología a otra en caso de ser necesario.

3. Elige un lenguaje y profundiza

Es tentador intentar aprender varios lenguajes a la vez, pero es más efectivo dominar uno antes de pasar a otro. Python y JavaScript son excelentes opciones para principiantes debido a su amplia aplicación y comunidad de apoyo.

4. Practica regularmente

La programación es una habilidad que mejora con la práctica constante. Dedica tiempo diario o semanal para escribir código y resolver problemas.

5. Lee y analiza código de otros

Examinar el código escrito por programador@s experimentad@s puede brindarte nuevas perspectivas y técnicas que podrías no haber considerado.

6. Resuelve problemas reales

Aplica tus conocimientos creando proyectos que te interesen o resuelvan problemas cotidianos. Esto no solo refuerza lo que has aprendido sino que también construye tu portafolio. Existen algunas páginas como Exercism o Codewars que te permiten practicar lenguajes de programación mediante retos. Esta no es forma favorita de aprender a programar… no estarás solucionando problemas como los que te puedes encontrar una vez estés trabajando y no estarás “engordando” tu portfolio.

7. Utiliza Control de Versiones

Familiarízate con herramientas como Git y plataformas como GitHub o GitLab. El control de versiones es esencial en el desarrollo profesional y te ayudará a colaborar con otros.

8. No temas pedir ayuda

Si te atascas, pide ayuda en foros, comunidades en línea o grupos de estudio. La comunidad de programación es generalmente muy abierta y dispuesta a ayudar.

9. Mantente actualizad@

El mundo de la tecnología evoluciona rápidamente. Sigue blogs, podcasts y canales de YouTube relacionados con programación para estar al día con las últimas tendencias y prácticas. Únete a grupos como GDG y ve a conferencias.

10. Desarrolla habilidades “blandas”

La comunicación, el trabajo en equipo y la resolución de problemas son habilidades igualmente importantes. Participa en grupos de estudio o proyectos colaborativos para desarrollarlas.

11. Cuida tu salud mental y física

Programar puede ser desafiante. Estresante y frustrante, incluso. Tómate descansos, mantén una postura adecuada y no olvides equilibrar tu tiempo frente al ordenador con otras actividades.

12. Explora Diferentes Áreas de la Programación

Una vez que te sientas cómod@, experimenta con diferentes campos como el desarrollo de juegos, la inteligencia artificial o la ciberseguridad para encontrar tu verdadera pasión. No hace falta que seas un@ expert@ en el campo para empezar a “oler” lo que hay en otras áreas.

Y, ahora sí, algunos recursos.

freeCodeCamp

freeCodeCamp es una organización sin fines de lucro dedicada a hacer que el aprendizaje de la programación sea accesible para todos. Ofrece una plataforma en línea gratuita que incluye un plan de estudios interactivo, una comunidad activa y recursos educativos diversos.

El plan de estudios de freeCodeCamp abarca más de 3,000 horas de contenido, cubriendo áreas como desarrollo web, análisis de datos y aprendizaje automático. Los estudiantes pueden obtener certificaciones gratuitas en temas como:

Responsive Web Design
Algoritmos y estructuras de datos en JavaScript
Bibliotecas de desarrollo front-end
Visualización de datos
Desarrollo Back-End y APIs
Computación científica con Python
Análisis de datos con Python
Seguridad de la Información
Machine Learning con Python

DotTech-ES

DotTech-ES es un canal de YouTube dedicado a la tecnología y la programación. Ofrece contenido educativo sobre patrones de diseño, código limpio, JavaScript, Angular y otros temas relacionados con el desarrollo de software. El canal cuenta con una lista de reproducción llamada “Lo mejor de DotTech” que recopila sus vídeos más destacados.

Este canal es para gente que ya lleva programando un tiempo y quiere ir un pasito más allá. Para quienes buscan recursos en español sobre programación y desarrollo de software, DotTech-ES es una opción valiosa que combina teoría y práctica en sus contenidos.

Python Weekly

Python Weekly es un boletín electrónico semanal que se enfoca en recopilar y compartir las últimas noticias, artículos, tutoriales, proyectos y eventos relacionados con el lenguaje de programación Python. Es una herramienta invaluable para desarrolladores de todos los niveles que desean mantenerse al día con las tendencias y avances en la comunidad de Python.

Incorporar Python Weekly a tu rutina semanal es una excelente manera de complementar tu aprendizaje y mantenerte conectado con la vibrante comunidad de Python. Ya seas principiante o un experimentad@, este recurso te ofrecerá información valiosa para continuar creciendo en tu camino como programador.

Guía sobre Git de Atlassian

¡Explora esta guía y lleva tus habilidades de programación al siguiente nivel! Aprender a utilizar Git de manera eficiente es esencial para colaborar en proyectos y mantener un flujo de trabajo organizado. La guía de Atlassian te acompaña paso a paso en este proceso de aprendizaje.

Y tú… ¿qué otros recursos utilizas?

Talking about performance, profiling, testing and other stuff

Israel Blancas — Tue, 18 Apr 2023 08:40:00 +0000

Performance testing is a type of software testing that measures how well an application performs under certain conditions. It is the process of determining the speed, responsiveness, stability, and scalability of a software application under a particular workload.

It is significant for a number of reasons. First off, it aids in locating performance bottlenecks and other problems that might affect an application's performance. Second, it helps to guarantee that an application is scalable and can handle the anticipated traffic. Last but not least, it assists in ensuring that an application satisfies the performance standards established by the stakeholders.

It is typically done during the testing phase of the software development life cycle (SDLC), after the functional testing has been completed. It can also be done before the application is released to production to ensure that it meets the performance requirements.

Some of the variables that can be measured in performance testing include:

Response Time - the time it takes for the application to respond to a user request.
Throughput - the number of transactions that can be processed by the application in a given time period.
Concurrency - the number of users that can access the application at the same time without impacting performance.
CPU usage - the amount of CPU resources consumed by the application.
Memory usage - the amount of memory resources consumed by the application.
Network latency - the time it takes for data to travel between the client and server.

Is it the same than load testing?

Some people are not able to find differences between performance testing and load testing. They are related (somehow).

Load testing is a type of software testing that measures how well an application can handle a specific load or level of demand. The goal of load testing is to determine the maximum capacity of an application and to identify any bottlenecks or issues that may impact its performance under high load. Load testing typically involves simulating a large number of users or transactions to see how the application responds. The focus is on measuring the response time, throughput, and resource utilization of the application under load.

Performance testing, on the other hand, is a broader term that encompasses several types of testing. It can include load testing, stress testing, endurance testing, and other types of testing. The goal is to identify performance issues and bottlenecks that may impact the application's performance under different conditions.

How to Write Performance Tests in Golang

Why Write Performance Tests in Golang? Golang is a programming language that is well-suited for building high-performance applications. However, even the best-written code can suffer from performance issues when it is deployed in the real world. Performance testing helps identify these issues before they become major problems.

In Golang, you can write performance tests using the built-in testing package. The package provides the Bench function, which allows you to write benchmark tests for your code.

Here's an example of a performance test for a function that sorts an array of integers:

func BenchmarkSort(b *testing.B) {
    // Create a random array of integers
    arr := make([]int, 1000000)
    for i := 0; i < len(arr); i++ {
        arr[i] = rand.Intn(1000000)
    }
    // Reset the timer
    b.ResetTimer()
    // Run the sort function b.N times
    for n := 0; n < b.N; n++ {
        sort.Ints(arr)
    }
}

In this example, we create a random array of integers and then reset the timer before running the sort.Ints function b.N times. The b.N value is an integer that represents the number of times the sort.Ints function should be run.

Then, you can use the go test command. To run the BenchmarkSort test from the previous example, you can use the following command:

go test -bench=.

The -bench flag specifies the pattern to match against benchmark test names. In this case, the . matches all benchmark tests.

Should I implement performance tests?

As always: it depends. If the value of your application is to be a high performance communication system, it would make sense to integrate performance tests. If your application is a TODO-list, maybe is not as important. You need to implement the tests that bring more value to you.

Also, you have to take into account that, if your application depends on third-party services or in other web services, it can be difficult to detect bottlenecks during your performance testing. Also, some performance issues will appear only in your production environment. Why? Because they will take place only in those scenarios where the load is high and the users behavior is real and, maybe, less predictable. This is the usual scenario for cloud based applications.

Performance testing can be interesting for certain parts of your code but you can be interested in continuous profiling.

Continuous profiling

Profiling involves analyzing an application's behavior, such as its CPU and memory usage, to identify performance bottlenecks and areas for optimization. It is typically done by running the application with a profiling tool that collects data about its performance, which can then be analyzed to identify areas for improvement. Performance testing, on the other hand, involves testing an application's performance under specific conditions. But those conditions could not reproduce the workflows from your users (you're not testing a real behavior or under the correct load).

Continuous profiling is a technique used in software development to analyze and monitor the performance of an application in real-time. It involves the collection of data about the application's performance, such as CPU usage, memory usage, and other metrics, continuously and automatically.

In contrast to traditional profiling, which is typically performed manually and only for short periods of time, continuous profiling is designed to provide ongoing insights into an application's performance. By monitoring the application's behavior over time, continuous profiling can identify trends and patterns that may indicate performance issues or opportunities for optimization.

Continuous profiling is often used in conjunction with other techniques, such as continuous integration and continuous delivery, to ensure that an application is performing optimally throughout the development process. It can also be used in production environments to monitor the performance of an application in real-time and identify issues before they become critical.

Overall, continuous profiling is a valuable tool for software developers and operations teams, as it allows them to identify and address performance issues quickly and efficiently, leading to faster and more reliable software delivery.

You can learn more about continuous profiling in the CNCF website.

Golang. Yes or not?

Israel Blancas — Mon, 10 Apr 2023 11:51:00 +0000

I have been working with Golang for some years and some people ask me if Golang is a good language. The answer is always the same: "it depends on what you want to build". This post is not another one about why you should stop working with Python or Java and start with Golang. It is about when I consider Golang can (not must) be used and where can make you more productive.

I can attest to the many advantages of using Golang, also known as Go, as a programming language. Developed by Google in 2007, Golang has become increasingly popular among developers due to its simplicity, concurrency support, and performance capabilities. In this article, I will explain why you should consider using Golang for your next project and compare it to other popular languages like Python and Rust.

Advantages of Golang

Simple and easy to learn

Golang is known for its simplicity and ease of use. Its syntax is straightforward, and its standard library is well-documented, making it easy for developers to learn and start coding. Moreover, Golang has a smaller codebase compared to other languages, making it easier to maintain and debug.

Concurrency support

Golang is designed to handle concurrent programming. Its built-in goroutines, lightweight threads, and channels make it easy to write concurrent programs, improving the scalability and efficiency of your code. This is especially important for web applications that require handling multiple requests simultaneously.

High-performance capabilities

Golang is known for its high-performance capabilities. Its compiled nature allows it to run faster than interpreted languages like Python. Additionally, Golang has efficient garbage collection, making it suitable for memory-intensive applications.

Great for building network applications

Golang has excellent support for building network applications. Its standard library includes packages for working with HTTP, TCP, and UDP protocols, making it easy to develop web servers, APIs, and networking tools.

When to use Golang?

Golang is a suitable choice for building a wide range of applications. Here are some situations where you should consider using Golang:

Developing microservices

Golang is an excellent choice for developing microservices, which are small, independently deployable services that work together to form a larger application. Its concurrency support and high-performance capabilities make it ideal for building scalable microservices.

Building network applications

Golang’s built-in support for networking protocols makes it a great choice for building network applications like web servers, APIs, and networking tools.

Developing command-line tools

Golang’s simple syntax and ease of use make it a great choice for developing command-line tools.

Golang vs. Python vs. Rust

Golang is often compared to other popular programming languages like Python and Rust. Here are some key differences between the three languages:

Syntax: Golang’s syntax is simpler and easier to learn than Python and Rust.
Performance: Golang is faster than Python but slower than Rust.
Concurrency support: Golang has better concurrency support than Python but worse than Rust.
Memory safety: Rust offers memory safety features that are not available in Golang or Python.

When not use Golang?

While Golang is a powerful language for many applications, there are certain scenarios where it may not be the best choice. Here are some cases where Golang may not be the optimal language to use:

GUI Applications: Golang does not have strong support for building Graphical User Interface (GUI) applications. Although there are some libraries available for building GUIs, they are not as mature or well-supported as other languages like Java, C++, or Python. If you are building a GUI application, you may want to consider a language like Python or Java.

Complex Mathematical Calculations: Golang does not have built-in support for complex mathematical calculations. Although you can use external libraries for complex mathematical operations, Golang may not be the best choice for scientific computing or numerical analysis. If your application requires complex mathematical calculations, you may want to consider a language like Python or MATLAB.

Interoperability with Legacy Systems: Golang does not have strong support for interoperability with legacy systems. If you need to integrate your application with legacy systems written in languages like COBOL or FORTRAN, you may want to consider a language like C or C++.

Machine Learning: Although Golang has some libraries for machine learning, they are not as robust or widely used as Python's machine learning libraries. If your application requires extensive machine learning capabilities, you may want to consider using Python.

High-Level Abstractions: Golang is a low-level language and does not have the high-level abstractions that other languages like Python or Ruby provide. If your application requires a lot of high-level abstractions, you may want to consider a language like Python or Ruby. For this reason, a lot of people says it is not good for business logic. Things like filter, map or reduce are not part of the standard library.

About writing business logic with Golang

Golang is not the preferred language for writing business logic. Why? A lot of companies prefer to use Java for this kind of usage. These are some of the reasons:

Ecosystem Maturity: Java has been around for more than two decades and has a mature ecosystem that includes many libraries and frameworks for building business logic applications. On the other hand, Golang is a relatively new language, and although its ecosystem is growing, it is not as mature as Java’s.
Strong Type System: Java’s strong type system helps developers catch errors at compile time, making it easier to build complex business logic applications. Golang has a weaker type system, which means that some errors may only be caught at runtime, making it more difficult to build complex business logic applications.
Garbage Collection: Java has a robust garbage collection system that helps manage memory, which is essential for business logic applications that require a lot of memory. While Golang also has a garbage collection system, it is less efficient than Java’s. And we know efficiency affect to costs.
Debugging and Profiling Tools: Java has a range of debugging and profiling tools, such as VisualVM and JProfiler, that make it easier to debug and optimize business logic applications. Golang also has some debugging and profiling tools, but they are not as mature as Java’s.
Enterprise Support: Java has strong enterprise support from vendors like Oracle, making it a popular choice for building business logic applications. Golang is still a relatively new language, and while it is gaining popularity, it may not have the same level of enterprise support as Java.

In conclusion, Golang is an excellent choice for building scalable, high-performance applications, especially for network and microservices development. Its simplicity, concurrency support, and performance capabilities make it a top contender for many software engineering projects. However, the choice of programming language ultimately depends on the specific requirements of your project, and you should evaluate each language based on your needs before making a decision.

Use scratch images. Is it a good idea?

Israel Blancas — Fri, 24 Mar 2023 16:51:28 +0000

When you create the container image for your application, you need to set a base container image (indicated in the FROM statement from Dockerfiles/Containerfiles). Usually, we set Linux distributions as base images like Debian, CentOS, or Ubuntu. Later, we install all the libraries we need to build and/or run our application and generate the final container image. If we’re working with Java, we’ll install Gradle or use an image with Gradle installed. If we’re using Python, we’ll install the Python runtime or use an image with Python installed by default.

One of the recommendations given as a good practice is to create minimal container images. What is a minimal container image? A container image with only your application, the configurations (XML files, environment variables), and the dependencies. Following this approach, we reduce the size of our container images. Why is this interesting? The images will be cheaper to store and to pull/push from/to container registries.

Depending on the technologies your application relies on, you will depend more or less on the base image. For example, if you develop in NodeJS or Python, you only need a base image with the runtime installed: you don’t care about the base OS. If you develop in C, you probably need to care about it because you may need to depend on a specific LIBC implementation (GLIBC or MUSL, for instance). So, to productize your application, you should choose a base container image that meets your requirements but minimal footprint. For instance, if we need to use a NodeJS Carbon container image as a base for ours, carbon-alpine is the best choice.

Repository	Tag	Image ID	Size (MB)
node	carbon-alpine	b9e61ad789af	67,4
node	carbon-slim	6fded0f27b5f	139
node	carbon-buster-slim	06ad6f44bf28	148
node	carbon-jessie-slim	ad0fdfc38d06	183
node	carbon-jessie	e866fe9eab07	675
node	carbon-buster	39eb5db21f68	862
node	carbon	7a9afc16a57f	894

But, if we’re using something as Golang, were you can do static link of everything into your application, you can reduce the size even more. Why? Because you don’t need a runtime and you can, even, not need a base operating system. For that reason, is pretty common to see Dockerfiles from Golang applications as simple as (supposing the application was built locally or you can use multi-stage container builds)


FROM scratch

COPY myapp .

ENTRYPOINT [“./myapp”]

Is using scratch images a good idea?

Using scratch images as the base for containers can be a good idea because they provide a minimal and clean starting point for building images. The scratch image is completely empty and does not include any pre-installed packages or libraries, which means that you have complete control over the dependencies and software that are included in the image. It is the 0 image. The “Object” container image. The minimal container image. The nothing.

Using scratch images as the base for our containers can be beneficial in situations where you need to build a small, lightweight image that only includes the exact packages and libraries that are necessary for your application. Following this approach can help you to ensure that your images are more secure since there are no pre-installed packages or libraries that could be vulnerable to security exploits.

Some developers prefer not to use scratch images as a base for their container images. They can be “safer” because they don’t have applications the hackers can take advantage of to break into your system but they do not provide any security or patching mechanisms. This is usually a concern for developers. Instead, many developers prefer to use base images that include a minimal set of commonly-used packages and libraries, which can save time and reduce the risk of errors, even when the base images are not totally minimal. A good approach for this can be to use the distroless container base images, where you have base images but not with a lot of components.

And you? What do you prefer to use?

Kubernetes: why yes and why not

Israel Blancas — Thu, 02 Feb 2023 10:20:25 +0000

For sure you have heard about Kubernetes. Kubernetes is an open-source container orchestration system that has taken the world of containerization by storm. This powerful platform has become a go-to choice for organizations of all sizes looking to manage and deploy containerized applications at scale.

Why yes

One of the main reasons why Kubernetes is so amazing is its ability to automate the deployment, scaling, and management of containerized applications. This means that organizations can focus on developing and deploying new features and functionality, rather than worrying about the underlying infrastructure.

In addition to its automation capabilities, Kubernetes also offers a high degree of flexibility. The platform can be easily customized to meet the unique needs of different organizations, and it can be deployed on a wide range of infrastructure, including on-premises, in the cloud, or in a hybrid environment.

Another key advantage of Kubernetes is its ability to handle high availability and disaster recovery. The platform supports automatic failover and self-healing, which helps to ensure that applications remain up and running even in the event of a failure. This helps to minimize downtime and ensure that users always have access to the services they need.

Finally, Kubernetes is an open-source project, which means that it is constantly being improved and updated by a large and active community of developers. This ensures that the platform remains cutting-edge and up-to-date with the latest technologies and trends.

Why not

Despite all the advantages, it's not always the perfect solution for every organization. In this blog post, we'll explore some of the reasons why Kubernetes can be a horrible fit for certain organizations.

One of the main issues with Kubernetes is its steep learning curve. The platform is highly complex and can be difficult to set up, configure, and manage. This can be a significant barrier for organizations that do not have a dedicated team of experts with the necessary skills and experience to work with Kubernetes.

Another issue with Kubernetes is its high resource requirements. The platform requires a lot of memory, CPU, and storage to run, which can be a significant burden for organizations that have limited resources. Furthermore, Kubernetes requires a lot of management and maintenance which can be a real headache for organizations that are struggling to keep up with the day-to-day operations.

Another downside of Kubernetes is its scalability limitations. While the platform is designed to handle large numbers of containerized applications, it can struggle to meet the needs of organizations that are dealing with massive traffic or large-scale deployments. This can lead to increased downtime, slow performance, and other issues that can negatively impact the user experience.

What alternatives do I have to run my own Kubernetes?

Depending on your application needs, it could be OK to use systemd to run your containers or deploy a virtual machine as host. Other alternatives are using a Platform as a Service or a Backend as a Service (like Firebase).

If you still feel you need Kubernetes but you cannot manage to create your own Kubernetes cluster, there are some alternatives like:

Managed Kubernetes Services: Many cloud providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure offer managed Kubernetes services. These services handle the deployment, scaling, and management of Kubernetes clusters, leaving you to focus on developing and deploying your applications.
Kubernetes-as-a-Service: This is a fully managed Kubernetes service offered by a third-party provider. It allows you to easily create and manage Kubernetes clusters on a variety of cloud providers, without having to worry about the underlying infrastructure. 3.Serverless Containers: Serverless container platforms such as AWS Fargate, Azure Container Instances, and Google Cloud Run allow you to run your containerized applications without having to worry about managing the underlying infrastructure.

Conclusion

In conclusion, while Kubernetes is a powerful platform that has a lot to offer, it's not always the best fit for every organization. The platform is highly complex, requires a lot of resources and maintenance, and has scalability limitations. Organizations that are struggling to meet these requirements may be better off looking for alternative solutions that are better suited to their specific needs.

Development principles you should know

Israel Blancas — Sat, 28 Jan 2023 16:03:45 +0000

In our industry, principles are rules and recommendations to follow during software development to make it easy to maintain and evolve. Developers can apply these principles at various stages of the software development process, from planning and design to implementation and testing. These principles can look not so valuable when somebody is at the beginning of their career. On the other hand, they make sense when you start working on more professional applications.

During this post, I'll try to give you a quick view of some well-known software principles you should know!

You Ain't Gonna Need It

YAGNI is a principle that advises developers not to add unnecessary features or code to a software system. The idea is to keep the system as simple as possible. Adding new features happens later only if they are needed. So: rather than trying to anticipate future needs and adding them in advance, we only spend resources on creating something to satisfy our requirements.

Why is YAGNI important? Keep the product as much simple as possible, not adding stuff that will not bring value to the final customer, is a good practice: you don't waste resources and ensure your technical debt will not increase.

Don't Repeat Yourself

DRY is a principle that advises developers to avoid writing redundant code. The idea is to ensure that there is only one source of truth for any given piece of information within a system. This makes it easier to maintain the system, as you only have to update a single piece of code rather than searching for and updating multiple copies of the same code. You can reuse logic you wrote before: write once, use thousands of times.

Why is DRY important? Because you don't need to solve the same problem multiple times. If, for instance, you wrote a method to calculate the price of something... why do you need to write the same again in another place of your code? Also: if you fix a bug in one of the methods, you might forget about propagating the change to the other implementations of the same agorithm.

Keep It Simple, Stupid

KISS is a principle that advises developers to keep their code and design as simple as possible. The idea is that simple systems are easier to understand, maintain, and modify than complex ones.
It is a similar principle than Ockham's razor. Ockham's razor is a principle of parsimony which states that, when presented with multiple explanations for a phenomenon, one should select the explanation that makes the fewest number of assumptions. So: if you have multiple posibilities to implement something... what is the correct? The simplest.

Why is KISS important? Remember you will not be working alone when developing software. Keeping stuff simple, will help new contributors to understand your methods/architectures/systems easier... Find (and fix) bugs will be a piece of cake!

Law of Demeter

LOD is a principle that advises developers to reduce the number of dependencies between objects in a system. The idea is to minimize the amount of knowledge that an object has about other objects, as this can make the system more modular and easier to maintain.

Why is LOD important? It will help the KISS and DRY pinciples. Also... it will help you for testing purposes!

Separation of Concerns

SOC is a principle that advises developers to divide a software system into distinct parts, each of which addresses a separate concern. The idea is to make it easier to understand and modify the system, as each part can be developed and tested independently of the others.

Why is SOC important? Imagine, for instance, you integrated an application with a database. After some time, for cost reasons, you need to switch to another system. If the application is really coupled to the database (you have calls to the database API across all your code), the costs of using a new database will raise. But, if your code calls an intermediate piece of code thata acts as an interface for the database, you only need to change the implementation of its methods!

SOLID

SOLID is an acronym for five design principles for writing maintainable and scalable software. They are:

Single Responsibility Principle: A class should have one and only one reason to change.
Open-Closed Principle: A class should be open for extension but closed for modification.
Liskov Substitution Principle: Subtypes should be able to substitute for their base types.
Interface Segregation Principle: A class should not be forced to implement interfaces it doesn't use.
Dependency Inversion Principle: High-level modules should not depend on low-level modules, but both should depend on abstractions.

Why are SOLID principles important? They mainly resume the others!

These are just a few examples of software development principles that can help developers create high-quality, maintainable software. By following these principles, developers can help ensure that their systems are flexible, scalable, and easy to modify over time. Which others do you know?

Access the Jaeger REST API programatically in OpenShift

Israel Blancas — Thu, 05 May 2022 14:22:59 +0000

Have you ever tried to access Jaeger programmatically in OpenShift? It can be a little bit difficult. Sometimes, it is needed because you want, for instance, access to the REST API which is not documented because it is for internal usage. Or you want (as it is my case) to test something from the UI.

Before reading this article

This article is about how to get access to the Jaeger query service when using the “production” deployment strategy and deploying via the Jaeger Operator. Some steps can be the same if you are using other deployment methods. Even, these steps can be not needed if you disabled the security:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: disable-oauth-proxy
spec:
  ingress:
    security: none

Also, take into account this is for OpenShift. So, if you are using Kubernetes without any security proxy or something, you’ll not need to follow these steps to access the Jaeger query endpoints. Or (if you are using another proxy) you’ll need to configure your credentials to access the API. I’ll assume you’re using the OpenShift Oauth Proxy.

Getting access to the Jaeger query service

Let’s imagine I deployed the following CRD (kubectl create -f simple-prod.yaml) in the israel namespace:

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  strategy: production
  storage:
    type: elasticsearch
    elasticsearch:
      nodeCount: 1
      resources:
        requests:
          cpu: 200m
          memory: 1Gi
        limits:
          memory: 1Gi

The result of running curl against the created OpenShift route will be a 403 error:

$ curl https://$(kubectl get route simple-prod -o jsonpath='{.spec.host}') -I
HTTP/1.1 403 Forbidden
Set-Cookie: _oauth_proxy=; Path=/; Domain=simple-prod-israel.apps.mycluster.iblancasa.com; Expires=Thu, 05 May 2022 11:09:34 GMT; HttpOnly; Secure; SameSite
Date: Thu, 05 May 2022 12:09:34 GMT
Content-Type: text/html; charset=utf-8
Set-Cookie: 3f978cf9c2d3ee8d70cad1d11aef9dcd=8d2f11be8db90157d1e73d19b515f187; path=/; HttpOnly; Secure; SameSite=None

If you didn’t specify the -I option to receive just the headers, you will receive the full HTML code from the logging webpage. Let’s see how to get the “correct” answer from the server.

The first step is to create a Service Account. From the OpenShift documentation:

A service account is an OpenShift Container Platform account that allows a component to directly access the API.

I’ll name my Service Account as “automation-access”. So, my file sa.yaml contains:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: automation-access

And create it in OpenShift using kubectl create -f sa.yaml:

$ kubectl create -f sa.yaml
serviceaccount/automation-access created

Now, we need to create a Cluster Role Binding. From the Kubernetes documentation:

A role binding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted. A RoleBinding grants permissions within a specific namespace whereas a ClusterRoleBinding grants that access cluster-wide.

As a simplification, we can use Cluster Role Bindings to establish relationships between, for instance, a Service Account and Cluster Role. In our case, it would be enough with system:auth-delegator for the jaeger-operator Service Account from the observability namespace and cluster-reader for the Service Account we created before. Our crb.yaml file will be similar to this one:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: jaeger-operator-with-auth-delegator
  namespace: observability
subjects:
- kind: ServiceAccount
  name: jaeger-operator
  namespace: observability
roleRef:
  kind: ClusterRole
  name: system:auth-delegator
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: automation-access-bind
subjects:
- kind: ServiceAccount
  name: automation-access
  namespace: israel
roleRef:
  kind: ClusterRole
  name: cluster-reader
  apiGroup: rbac.authorization.k8s.io

And apply it to our OpenShift cluster using: kubectl create -f crb.yaml:

$ kubectl create -f crb.yaml
clusterrolebinding.rbac.authorization.k8s.io/jaeger-operator-with-auth-delegator created
clusterrolebinding.rbac.authorization.k8s.io/automation-access-bind created

Finally, we need to set some extra options to our Jaeger deployment (jaeger-sar.yaml):

apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simple-prod
spec:
  query:
    options:
      query.bearer-token-propagation: true
  ingress:
    openshift:
      sar: '{"namespace": "israel", "resource": "pods", "verb": "get"}'
      delegateUrls: '{"/":{"namespace": "israel", "resource": "pods", "verb": "get"}}'
    options:
      pass-access-token: true
      pass-user-bearer-token: true
      scope: "user:info user:check-access"
      pass-basic-auth: false

Then, we apply it with kubectl apply -f jaeger-sa.yaml:

$ kubectl apply -f jaeger-sar.yaml
Warning: resource jaegers/simple-prod is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
jaeger.jaegertracing.io/simple-prod configured

Ok! We’re almost there. The next step is to get the token that will allow us to access the Jaeger query service programmatically. To get the token, we need to get the name of the Kubernetes secret to use. We can get that information from the following command:

$ kubectl get sa automation-access -o jsonpath='{.secrets}'
[{"name":"automation-access-token-q2p2x"},{"name":"automation-access-dockercfg-xvzsq"}]

The result is the name of 2 secrets. We’ll use the one called auomation-access-token-<ID>. If you use yq, the command can be:

$ kubectl get sa automation-access -o yaml | yq eval '.secrets[] | select( .name == "*-token-*")'.name 
automation-access-token-q2p2x

And, finally, we extract the token from the secret:

$ kubectl get secret automation-access-token-q2p2x -o jsonpath='{.data.token}' |  base64 -d
eyJhbGciOiJSUzI1NiIsImtpZCI6Iks3TXcwUWhyb3BVdUVJblhkQmVQT25Fek1KVVlfa2RPV3dDZWpJVXpmekUifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJpc3JhZWwiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoiYXV0b21hdGlvbi1hY2Nlc3MtdG9rZW4tcTJwMngiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiYXV0b21hdGlvbi1hY2Nlc3MiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiI1NGY1ZDE0MC1lMDEwLTQ5NWYtYWE4Yy0wNmQ3ZjIwNjg3OGIiLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6aXNyYWVsOmF1dG9tYXRpb24tYWNjZXNzIn0.J5USv-olD1vU0A5tL8TT1SDoH-jf5f58hSIEPnkkiZzTiOjHHx2Vj2v1p0bm26epfTQwLV3TfIsgcsV7tnpC0cR64MmDQe9EuBtNonJqV45nTkSoboWuBfeSxXqjk7Tuj_bcZcutcA0vsVHzAglb-Z0wavx9ETfQJueDWTzF6Cry5HxVxYn6ytogHfbaEgiLN9HNeZBWW4xi7JAzY-2viECrFq1yEIJKzWDihZScFkyX2fu1UDpFLH2ewA8N6bdqSd5FTEna0JS0e8yxQcGo-oXykDW2G_YcLDBSrCpQaji390FgMp_6dEl1yHSazGgCaKwulwOU4Rr6usf807mdBQ

This command gets the token from the secret and decodes it. We need to provide this token in the Authorization header when doing a curl call:

$ export TOKEN=$(kubectl get secret automation-access-token-q2p2x -o jsonpath='{.data.token}' |  base64 -d)
$ curl https://$(kubectl get route simple-prod -o jsonpath='{.spec.host}') -I -H "Authorization: Bearer $TOKEN"
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Date: Thu, 05 May 2022 12:44:06 GMT
Gap-Auth: system:serviceaccount:israel:automation-sa@cluster.local
Gap-Upstream-Address: localhost:16686
Vary: Accept-Encoding
Set-Cookie: 3f978cf9c2d3ee8d70cad1d11aef9dcd=2e6b6fcf2050268c74e1aabcf71e9bab; path=/; HttpOnly; Secure; SameSite=None
Cache-control: private

Thank you for reading! I hope this article helped you! :)

Observability: the basics

Israel Blancas — Tue, 15 Feb 2022 22:25:39 +0000

Probably you have heard about observability, but.. do you really understand it? In this post, I’ll explain it in an easy way. If this is the first time you read something about observability: I hope you learn a lot. Else, if you know a lot about observability, I hope you learn something new.

What is observability?

A system is observable when you can infer its internal state just from its outputs. That’s it. Sounds easy, right? Not exactly. The systems are more and more complex each day and deciding what outputs provide the tools to use to manage that data and being able to convert those data into information can be a big challenge.

A 101 example

Let’s imagine you created a calculator command line application. At some point, you try to multiply 3 by 3 and the result is 9 but, if you multiply 3 by 4, the result is 150. How would you debug that issue? Probably you will:

Check the output of the program for different inputs
Read the source code of the tool to detect what can go wrong
Use a debugging tool (or add a lot of temporary print statements, right? 😛)

And, after some time, you’ll find the issue, fix the problem, rebuild your application and, hopefully, run the tests to verify nothing was broken. This is so slow. And our example is a small application running in a single node: imagine when your codebase has thousands of lines of code, is running on a multi-cloud environment with hundreds of nodes and interacting with other applications. Problems can be difficult to find, aren't they? Systems are complex with complex failures.

Why is observability needed?

The dependency of business on technology has increased over the years. And the architecture of those software systems too. And, as a consequence, the architecture of the systems where this software runs.

From monolith to microservices

There are a lot of articles about how a lot of companies have evolved the software architecture of their systems from a single application to a lot of them. "Splitting" your application into microservices has some advantages, like better scalability, faster time to market, greater agility or better fault tolerance.
But it also has some disadvantages, like the need for more collaboration between teams or poorer performance (because the information needs to be sent through the network). And you need to maintain more systems. So, when something needs investigation (like an error or a performance degradation), instead of reviewing a single element, we need to inspect our microservices to detect which one is causing the issue and where.

From one machine to containers

Another big change was in the infrastructure. Before, the applications were deployed on a single machine. The dependencies as databases were installed in the same machine. If the system needed more resources, the solution was to buy new hardware and migrate everything to the new machine. This is called vertical scaling. But this solution has limitations in the number of resources you can have in a machine and the price of hardware with a lot of resources is expensive. And you have to throw away your old hardware! What is the solution? Horizontal scaling.

We can simplify and say that horizontal scaling is using small interconnected machines to work as a single unit. For example, you can have 10 machines running a web application and another one running a load balancer software to distribute the load between the different nodes.

But using physical machines has a big inconvenience: when you don’t need all the computing power your system has, you are wasting resources. Virtual machines to rescue! Using virtual machines, you can benefit more from your resources. If you need more computing power, you create copies of the VM running your application. If you need less, you can scale down your system easily. And… What do you do with the spare resources? You rented them to other companies with the same problems (oh wait! We just invented Cloud Computing).

This new scenario has other benefits: since you can create and destroy instances of your applications easily, if one of them starts to fail, you can remove it and spawn a new one. Another one: if you are running microservices, you can scale up or down one of them without affecting the others.

Using a cloud as infrastructure for your virtual machines avoids the need for maintaining physical hardware. And, depending on the cloud you are using, you can deploy your application in different regions, reducing the response delay of your customers.

When we use physical resources, we could run one instance of our application machine. Now, we can run multiple instances per machine. But our infrastructure can be more efficient: for each VM, there is an installation of the full operating system, libraries and other stuff that is not really important for our application. How about a way to isolate the instances of our applications but share those resources? That’s the idea behind containers.

With containers, we don’t need a hypervisor. Instead, we run a container engine in the host operating system and share OS resources across the different containers. As a consequence, each container includes the application and its dependencies. This leads to a lower resource usage per application instance. So, we can run more instances of our application in the same machine.

The less resources we use, the more money we save.

Why is this related to observability?

With one single instance of our application, observability was important to reduce the time to identify possible issues in our system. Imagine how important it is now, since we have hundreds of containers running instances of our microservices in different clouds with thousands of users accessing them. Systems are complex. And complexity increases the probabilities of creating a catastrophe.

There is something you need to take into account: disaster can not be avoided. There will always be:

Human error
Network issues: latency, bandwidth, reliability…
Outages
Untested code paths
Corner cases

We need to be ready for issues to avoid them or, at least, recover from them as fast as possible. Each minute our system is not working, is money our company is losing.

The free pillars of observability

If your application is observable, you should be able to detect where the problem originated by checking the outputs. What outputs?

Traces: contextual data about how a request or operation went through a system
Metrics: quantitative information about the system
Logs: specific messages emitted by a process or service As I said, once your system is generating that data, you need to convert it into information. Usually, send everything to a central place where you can correlate everything. For instance: if you start seeing crashes in your applications, you can query your system to detect what queries are producing those crashes. After that, using tracing and logging, you can go directly to the source of the problem. Observability is about the integration of multiple sources of telemetry data together that can help you to better understand how your software is operating. To get context to solve a problem before it happens or as soon as possible after the failure is produced.

Something that is pretty clear is that the concept of monitoring is complementary to observability. Monitoring tells you when something is wrong and observability why. Monitoring provides information about how the system is performing about connectivity, downtime or bottlenecks and observability what piece is failing and the reasons. Monitoring is part of observability.

Traces

A trace is a visualization of the events in your system showing the calling relationship between the events. This visualization includes information like the timing data for each event. The individual events are called "spans".

Using them, you can get what functions were called in your code or when one microservice connected a database to retrieve some information. And something really important: you can get how much time is spent in the different operations. Distributed tracing helps to do profiling of your system in production.

Metrics

They consist of a single numeric value tracked over time. We have used them in monitoring systems for years: CPU usage, memory, disk performance… But all this information gives us an incomplete view of what is happening in our system.

Observable systems include the concept of "application performance monitoring". This new concept proposes to track application level metrics like average load times, error rates, requests per second, time to perform operations against third party services… providing a real picture of what the user experiences.

Each metric tracks only one variable, which makes them more efficient to send and store.

Logs

Logs are text strings written to the terminal or to a file. You can generate these logs directly by printing information on the screen. But there are libraries that can help you to structurate that data to print information depending on the importance level (it is not the same as a debug message than an error message, for instance).

Los aggregation services allow you to send these messages to a central place to store them. Later, you can retrieve that data and extract information about what is happening in your system.

Closing

I hope you found this article useful. I'll create more posts about more observability topics soon!

Use VS Code online for your workshops!

Israel Blancas — Wed, 20 Oct 2021 20:05:02 +0000

How many times did your workshops turn into a copy-code-from-slides session? When you run a workshop, it is easy your attendees get lost:

They can not see your slides to copy the examples
The code is long and is easy to mistype something
They spend more time copying code than actually attending what you are saying
If they distract, they can be lost the rest of the session

It would be amazing if you could send the code ahead to their laptops while you are explaining. Right? You would reduce the copy/paste time. The audience engagement would be higher. Everybody would learn more with less effort. I was thinking a lot about this problem two days ago.

One alternative could be to use something like Google Drive. But those tools are not good when you share code:

No syntax highlighting
Copy/paste operations can be a problem
You cannot handle more than one file at the same time in a single session
No code suggestions/autocompletion

There are other tools like Code Anywhere that allow you to share code on real time with different people. Even, they allow you to enter in a “classroom” mode -where the invitees to the session cannot modify the code you are sharing-. But they also have their problems:

Not easy to find one free
Usually, the users need to register in the tool platform
Poor language support

Some code editors have plugins to allow the developers to create collaboration sessions. Visual Studio has Live Share and Atom has Teletype. But the invitees need to install the editor to be able to join the session. Until today.

Today I saw this tweet:

Wanna see something cool? 😎 Go to "https://t.co/k0d9MtptVW" and start coding with Visual Studio Code entirely in your browser. Anywhere, anytime, on any device and tablet, with no install required 🧑‍💻🪄
Read the announcement 👉 https://t.co/XpTxjfVENL pic.twitter.com/eOxK5gSoiE
— Visual Studio Code (@code) October 20, 2021

Now when you visit the vscode.dev, you'll go to a website with a lightweight version of VS Code running fully in the browser. Open a folder on your local machine and start coding. There are some limitations like you can't access a debugger or a terminal… but it is better than what we currently have. And... it's free!

What does this mean? You can ask the assistants to your workshop to open vscode.dev, install the Live Share extension and… share the code easily! They will not need to sign up on a new service or something similar.

I'm looking forward to schedule a workshop session to test Visual Studio online, and you?