DEV Community: Emmanuel Rodríguez

Software Deployment Strategies

Emmanuel Rodríguez — Mon, 09 Oct 2023 16:11:32 +0000

ℹ️ Introducción

El mundo del desarrollo de software ha evolucionado a un ritmo sin precedentes. Lo que antes se consideraba un proceso secuencial y lineal, se ha transformado en un flujo continuo de integraciones, pruebas y despliegues. Este avance, aunque provee velocidad y eficiencia, también introduce desafíos propios de un paradigma recién emergente.

Cuando hablamos de “Estrategias de despliegue de software”, nos referimos a las metodologías que permiten liberar el software al público con agilidad, y mínima intervención humana, después de cada modificación esencial en el producto.

Sin embargo, actuar sin una estrategia de despliegue bien definida o acumular improvisaciones y deudas técnicas, puede sumir a las organizaciones en prácticas perjudiciales, por ejemplo:

Despliegues manuales: Donde la intervención manual puede elevar el riesgo de errores convirtiendo, lo que debería ser una operación sencilla, en un posible punto de fallo.
Falta de pruebas: Donde al omitir pruebas esenciales o no validar adecuadamente los criterios de aceptación, podría resultar en la liberación de software defectuoso en producción.
Resistencia al cambio: Donde las organizaciones que no abrazan una estrategia de despliegue robusta suelen resistirse a cambios, estancando la innovación, la creatividad y, consecuentemente, el progreso.
Tiempo de inactividad: Porque sin una planificación adecuada, podrían surgir periodos inesperados de inactividad, afectando la experiencia del usuario y deteriorando la imagen del producto o de la organización.

Al comprender y abordar estos desafíos o malos hábitos, las organizaciones pueden garantizar que sus procesos de despliegue sean más fluidos, eficientes y, sobre todo, efectivos. Por ello, en esta publicación, nos adentraremos en estrategias de despliegue de software diseñadas para superar estos y otros obstáculos.

⌛️ Historia

El despliegue de software no es un concepto nuevo, pero su forma y metodología han sufrido transformaciones radicales a lo largo de los años.

En los primeros días de la computación, el software se distribuía físicamente. Esto podía ser en tarjetas perforadas, cintas magnéticas o, más tarde, en discos. El proceso de actualización era lento, manual y propenso a errores. Las versiones del software eran estáticas durante largos períodos, y cualquier modificación requería una re-configuración completa del sistema.

Con la llegada de la era de Internet, la distribución de software comenzó a migrar hacia la descargas en línea. Esto permitió actualizaciones más frecuentes, pero aún requería intervención manual debido al caos generado por las solicitudes. Las organizaciones empezaron a experimentar con despliegues más regulares, pero sin una estrategia coherente.

Hoy en día, podemos encontrar vestigios de algunas prácticas sin una implementación de un “Sistema de Gestión de Versiones” (VCS o Version Control System), donde se gestiona manualmente versiones de código o total de un producto digital.

A medida que los equipos de desarrollo adoptaron metodologías ágiles (como SCRUM o Kanban), el ritmo de producción del software aumentó. La necesidad de despliegues más frecuentes y confiables, llevaron al surgimiento de la integración continua (CI) y, eventualmente, al despliegue continuo (CD), también conocido como DevOps. Estas prácticas buscan automatizar la mayoría, si no todos, los aspectos del proceso de despliegue, reduciendo errores y acelerando la entrega.

DevOps, es un conjunto de prácticas, herramientas y una cultura organizacional que automatiza e integra procesos despliegue y entrega continua; a su vez, un rol en un equipo de desarrollo de software.

A medida que el despliegue continuo se volvía más común, la industria reconoció la necesidad de estandarizar y formalizar estas prácticas. Se han propuesto numerosos marcos y herramientas, buscando definir un conjunto de mejores prácticas y estándares. Este impulso hacia la estandarización, ha sido en parte motivado por la creciente complejidad del software y la infraestructura (adopción de tecnologías como cómputo remoto en la nube), así como por la necesidad de garantizar la calidad y seguridad en cada despliegue.

5 Estrategias más populares de despliegue de software

Continuando con la evolución del despliegue de software, te presento las cinco estrategias más populares y utilizadas en el desarrollo moderno de software. Cada una ofrece un enfoque único, con sus propias ventajas, restricciones y complejidades.

💥 Bing-Bang

Es una estrategia de despliegue referida como “todo a la vez” (all-to-once). Refiriendo a la estrategia de despliegue de software que reemplaza por completo a la versión anterior en un solo paso.

Beneficios:

Simplicidad: Dada su naturaleza directa, no requiere de complejos procesos de implementación ni de herramientas avanzadas.
Rapidez: Si todo va bien, esta estrategia permite una transición rápida entre versiones.
Familiaridad: Al ser una de las estrategias más antiguas y básicas, muchos equipos están familiarizados con ella y pueden implementarla sin una curva de aprendizaje significativa.

Restricciones:

Riesgo de Fallos: Cualquier error en la nueva versión afectará a todos los usuarios inmediatamente después del despliegue.
Tiempo de Inactividad: Es probable que los usuarios experimenten interrupciones durante el cambio de versión.
Reversión Compleja: Si algo sale mal, volver a la versión anterior puede ser difícil y tomar tiempo.

La estrategia es ideal para proyectos pequeños que buscan agilidad y rapidez, donde los riesgos entre versiones y/o tiempo de inactividad son tolerables. Su adopción en el equipo de desarrollo es rápido, ya que no involucra pasos complicados y su implementación suele estar delegada al proveedor host del producto (por ejemplo, Railway, Heroku, Render, entre otros).

Por proyectos pequeños, me refiero a aquellos que buscan explorar ideas o implementar funcionalidades emergentes, también conocidos como MVE o Experimento Mínimo Viable (Minimum-viable-experiment). Sin embargo, proyectos intencionados para productos como MVP o Producto Mínimo Viable (Minimum-viable-product), se recomiendan otras estrategias más apropiadas, ofreciendo mayor control y, minimizando los riesgos asociados por versiones y cambios de funcionalidades críticas o esenciales.

📈 Rolling

Esta estrategia de despliegue, conocida también como despliegue gradual, implementa la nueva versión en fases, reemplazando poco a poco las instancias de la versión antigua hasta que toda la aplicación ha sido actualizada.

Beneficios:

Minimización de Riesgos: Al desplegar en fases, es posible identificar y rectificar errores tempranamente, protegiendo así a la mayoría de los usuarios de fallos potenciales.
Disponibilidad Continua: Al no actualizar todas las instancias a la vez, se mantiene la disponibilidad del servicio durante el proceso de despliegue.
Feedback Temprano: Al recibir respuestas de los usuarios en las primeras fases, se pueden hacer ajustes rápidos antes del despliegue total.

Restricciones:

Complejidad: Requiere de herramientas y procesos más elaborados para gestionar los despliegues graduales y para revertir los cambios si es necesario.
Tiempo: Puede llevar más tiempo completar el despliegue total comparado con estrategias como Big-Bang.

La estrategia Rolling es muy adecuada para proyectos de tamaño medio a grande, donde la continuidad del servicio y la minimización de riesgos son prioritarias. Es ideal cuando se busca mantener una alta disponibilidad del servicio y se dispone del tiempo y las herramientas necesarias para gestionar el despliegue gradual.

Los equipos de desarrollo podrían necesitar un tiempo de adaptación y formación para implementar y gestionar correctamente esta estrategia, siendo particularmente útil en entornos donde la calidad del servicio es crucial, como en aplicaciones de comercio electrónico (E-Commerce) o plataformas de streaming (como Netflix, Spotify, etc.).

🔁 Blue-Green

Blue-Green es una estrategia de despliegue que implica tener dos entornos de producción paralelos: "Blue", que es la versión actualmente en uso, y "Green", donde se prepara la nueva versión. Una vez que la versión "Green" está lista y probada, se cambia el tráfico de usuarios al entorno "Green", haciendo que esta se convierta en la versión activa.

Beneficios:

Cero Tiempo de Inactividad: Al cambiar el tráfico entre los entornos, las actualizaciones pueden realizarse sin interrupciones para los usuarios.
Gestión de Versiones: Si se detectan problemas en el entorno "Green", se puede volver rápidamente al entorno "Blue". Y viceversa, antes de hacer el cambio, se puede probar la versión "Green" en un entorno que es idéntico al de producción.

Restricciones:

Recursos Duplicados: Se requiere mantener y gestionar dos entornos de producción, lo que puede aumentar los costos.
Complejidad de Coordinación: Asegurar que ambos entornos sean idénticos y sincronizar bases de datos u otros recursos compartidos puede ser un desafío.

Blue-Green es altamente recomendado para proyectos donde el tiempo es crucial y la reversión de cambios, en caliente, es vital. Es especialmente útil para aplicaciones críticas, como sistemas bancarios en línea, ofreciendo a los usuarios una experiencia fluida y sin interrupciones, incluso durante las actualizaciones más grandes y críticas.

Para los equipos de desarrollo, esta estrategia requiere una comprensión clara de cómo gestionar y coordinar dos entornos paralelos. Es apropiado para organizaciones que pueden invertir en infraestructura adicional para mantener la alta disponibilidad y calidad del servicio.

🐥 Canary

La estrategia de despliegue Canary toma su nombre de la antigua práctica minera de llevar canarios a las minas para detectar la presencia de gases tóxicos. En el contexto de despliegue de software, implica lanzar la nueva versión inicialmente solo a un pequeño grupo de usuarios (el "canario") antes de desplegarla al conjunto total de usuarios. Esto permite evaluar y monitorizar el comportamiento y el rendimiento de la actualización en un entorno real y con una muestra real de usuarios.

Beneficios:

Detección Temprana de Problemas: Al desplegar primero a un grupo pequeño, los problemas potenciales pueden identificarse antes de que afecten a toda la base de usuarios.
Feedback Rápido: Se obtiene una respuesta rápida de los usuarios "canarios" sobre la nueva versión.
Mitigación de Riesgos: Reduce el impacto de posibles fallos, ya que solo afectaría a un subconjunto de usuarios.

Restricciones:

Selección de Usuarios: Es esencial elegir adecuadamente al grupo "canario" para asegurarse de que sea representativo.
Gestión de Versiones: Puede ser complicado gestionar varias versiones del software simultáneamente si los despliegues canarios se extienden por largos períodos.
Complejidad Adicional: Requiere herramientas y procesos más avanzados para dirigir el tráfico de usuarios y monitorizar el despliegue.

Canary es ideal para proyectos que buscan minimizar riesgos y obtener un feedback rápido en entornos vivos. Beneficiándose en aquellas aplicaciones con una gran base de usuarios donde los fallos pueden tener un impacto significativo.

Los equipos de desarrollo deben estar preparados para actuar rápidamente en función del feedback y las métricas obtenidas del grupo "canario". Por lo que generar módulos o sistemas de monitoreo mediante soluciones MELT, son vitales para su éxito.

Esta estrategia es muy popular entre las grandes plataformas o productos web, ya que conocen sus audiencias poseen un conocimiento transversal de su valor diferencial. Con ello en mente, la estrategia les permite probar nuevas características de manera simultánea e incluso, completamente aislada de regiones enteras de una población.

👁️‍🗨️ A/B Testing

A/B Testing, o prueba dividida, es una estrategia de despliegue que implica lanzar simultáneamente dos o más versiones de un software o de una característica específica a diferentes segmentos de usuarios. Estas versiones son evaluadas en función de métricas específicas, como tasas de conversión, tiempo de permanencia en la página, entre otras, para determinar cuál de ellas es más efectiva en términos de rendimiento, usabilidad o cualquier otro criterio de éxito definido.

Beneficios:

Decisiones Basadas en Datos: Permite tomar decisiones sobre características o cambios basándose en datos reales de comportamiento del usuario.
Optimización Constante: Facilita la mejora continua del software al probar constantemente nuevas ideas y soluciones.
Reducción de Riesgos: Al lanzar nuevas características a segmentos pequeños y controlados de usuarios, se puede evaluar su impacto y aceptación antes de un despliegue total.

Restricciones:

Complejidad Analítica: Requiere herramientas de análisis robustas y la capacidad de interpretar correctamente los resultados.
Gestión de Versiones: Manejar múltiples versiones en paralelo puede ser un desafío técnico y logístico.
Factores Externos: Los resultados del A/B Testing pueden verse afectados por factores externos, donde es crucial aislar y entender estos factores para interpretar correctamente los resultados.

A/B Testing es particularmente útil para plataformas y aplicaciones centradas en el usuario donde se busca optimizar la experiencia del usuario.

Los equipos de desarrollo, marketing y de producto, suelen colaborar estrechamente en estas pruebas para garantizar que las métricas analizadas sean relevantes y que los resultados se interpreten adecuadamente. Al adoptar el A/B Testing, las organizaciones pueden asegurarse de que sus despliegues y actualizaciones estén alineados con las necesidades y preferencias reales de sus usuarios, lo que a su vez puede llevar a una mayor retención, satisfacción y conversión.

🍻 Conclusión

La entrega de software es un arte que va más allá de simplemente escribir código. Es una amalgama de prácticas, herramientas y, sobre todo, estrategias que aseguran que cada lanzamiento sea fluido, eficiente y, lo más importante, efectivo. Como hemos visto, existen múltiples estrategias de despliegue, y cada una tiene sus fortalezas y contextos ideales de aplicación. Lo más crucial es entender profundamente el proyecto que estás desarrollando, sus necesidades y su audiencia. Eso te permitirá elegir la estrategia que mejor se alinee con tus objetivos.

La Ingeniería de Software, constantemente te reta a emplear nuevas estrategias, a experimentar con ellas y a combinarlas si es necesario. No hay una talla única en el mundo; lo que funciona para un proyecto podría no ser adecuado para otro.

Explora, pregunta y amplia tu conocimiento para que te beneficies como profesional y amplíes tu cartera de éxitos.

Encuentra tu equilibrio en el mismo movimiento. Camina hacia el futuro.

GitOps

Emmanuel Rodríguez — Mon, 03 Oct 2022 16:27:26 +0000

✨ Concepto clave
GitOps es una práctica donde los equipos mantienen sus procesos DevOps (Integración Continua y Despliegue Continuo), en un único recurso de verdad, Git.

Vistazo General

Como colaboradores de algún proyecto de software, muy posiblemente estén familiarizados con el uso de Git.

Un proyecto de software es un jardín, que necesita ser atendido y cuidado.

El objetivo de GitOps no solamente es el resultado de un DevOps coordinado, sino de aquellas etapas de integración, fases de revisión de código y estado de salud de nuestro proyecto en curso.

Flujo de Trabajo (Workflow)

✨ Concepto clave
Me refiero al flujo de trabajo, a aquello que nos permite mover una aplicación en desarrollo a producción, el ciclo de vida de las aplicaciones y las configuraciones que caracterizan a nuestra infraestructura.

Cada industria conoce sobre lo que es adecuado y/o las mejores prácticas concernientes a su mercado. En el software, podemos encontrar muchas estrategias, algunas veces llamadas patrones y/o frameworks, que expresan reglas como estándar, dejándolas a su interpretación e implementación.

Por ello, te comparto algunas relacionadas al flujo de trabajo mediante Git.

Git Flow Branch Strategy

ℹ️ Definición
En Branch Strategy, la idea principal es aislar nuestro trabajo en diferentes tipos de ramas que generalmente entregan una cierta versión de nuestro producto.

Como colaboradores de proyectos en software, seguramente hemos trabajado con la estrategia de flujo mediante ramas, las cuales generalmente configuramos como:

Master Cuyas alternativas pueden ser Production o Main.
Release Cuyas alternativas podemos tener Development, Testing o Staging.
Action Cuyas alternativas podemos tener Integration, Hotfix o feature.

Los beneficios que ganamos serían:

Al tener diversos tipos de ramas (principales o de apoyo), hacen que sea fácil e intuitivo organizar nuestro trabajo.
Del efecto anterior, se puede proveer de un proceso de desarrollo de pruebas eficientes.
Se puede soporta múltiples versiones de código.

Los retos, por su parte, dependerán de:

Dependiendo de la complejidad, a veces de la madurez por concepción del producto o proyecto, podría complicar el proceso no lineal de desarrollo por falta de etiquetas de referencias.
Debido al poco control o coordinación entre los colaboradores, el historial de commits podrá limitar la identificación del cambio, desde la descripción hasta la atomicidad de cambios por registro.

Git Flow Feature Strategy

ℹ️ Definición
En Feature Strategy, nuestras ramas principales contienen versiones finales que fueron integradas y/o desplegadas; en otras ramas (features), tendremos acciones que se desplegarán y fusionarán a los entornos y ramas principales, respectivamente.

Como colaboradores, utilizamos esta estrategia de trabajo para liberar características, despreocupándonos del entorno a desplegar ya que la misma rama posee la capacidad de despliegue al entorno personalizado (feat.1.0-dashboard) o como de release (production).

Como beneficios, tendríamos:

Al aislar la característica en una rama, no mezclamos los historiales de origen, evitando el efecto dominó entre ramas.
Con cada modificación, se puede desplegar, detalladamente, características al entorno deseado.
Al ser una estrategia independiente entre características, en proyectos basados en sprints, se podrá agrupar y visualizar versiones y sus respectivos efectos individuales.

Los retos, por su parte, dependerán de:

Una estrategia madura en el versionado del código, por ejemplo Semantic-Version sobre Git.
La falta de sincronización entre ramas origen, dejan sin comunicación entre características o dependencias relacionadas.
Se requiere madurez en DevOps para personalizar tanto el despliegue como destrucción de entornos.

Beneficios de GitOps

✨ Concepto clave
Estamos de acuerdo que, cada cambio modificará el estado de la versión en nuestro repositorio, los cuales, una vez aprobados, se mezclaran a un destino que eventualmente marcará una nueva referencia de estado.

Experiencia de desarrollo (Development Experience XD)
- Interiorice el proceso de desarrollo en su equipo u organización, vinculando a los colaboradores con herramientas familiares como Git, permitiendo su adopción de manera individual.
Resiliencia y tolerancia a errores (Site Reliability Engineering SRE)
- Si su entorno está inactivo debido a la última implementación, simplemente puede usar Git para volver a la versión anterior.
Seguimiento de procesos (Issues Tracking)
- Dado que todo tiene que suceder a través del repositorio de Git, todos los cambios en el sistema son completamente accesibles a través del registro de Git. Es fácil ver quién, cuándo y, exactamente, qué cambió de una versión a otra.
DevOps unificado
- Con GitOps, las organizaciones pueden administrar toda su infraestructura y el ciclo de vida de desarrollo de aplicaciones utilizando una única herramienta unificada. Esto permite una mayor colaboración y coordinación entre los equipos, dando como resultado que haya menos errores y una pronta resolución de problemas más rápida.

Conclusión

GitOps no es más que un sinónimo de automatización y registro, sus derivaciones hermanas pueden ser ChatOps e IssueOps, los cuales complementa nuestro flujo de trabajo y potencian nuestro ciclo de vida de software. Es por que el uso de una herramienta dependerá de la intención que conlleva en su implementación.

Contenedores y la nube

Emmanuel Rodríguez — Mon, 15 Aug 2022 15:47:18 +0000

✨ Concepto clave
Los contenedores son recursos informáticos encapsulables, transportables y repetibles que modernizan los ambientes de ejecución.

Antecedentes

Los contenedores surgieron como una tecnología que buscaba segmentar un sistema, compactable en subsistemas o procesos. Estas últimas, se pensaban como entornos seguros, administrados y compartibles entre los distintos usuarios dentro o fuera de una empresa.

En 2008 surge Docker, un servicio del cual incorporaría una serie de conceptos y herramientas nuevas, como por ejemplo:

Una interfaz de línea de comandos sencilla para ejecutar y diseñar imágenes nuevas en capas.
Un daemon de servidor.
Una biblioteca de imágenes en contenedores preestablecidas.
El concepto de un servidor de registros.

Es por ello que los contenedores son considerados como una de las tecnologías revolucionarias en la ingeniería moderna, permitiendo que cada vez se combinen más tecnologías con mayor rapidez y menor complicación.

Docker, el inicio de las aplicaciones modernas

Con Docker, es posible automatizar el despliegue de aplicaciones dentro de contenedores de software, generando una abstracción del mismo y, al mismo tiempo, una automatización de virtualización distribuido llamado microservicios.

Lo que hizo que Docker fuera un recurso significativo en el desarrollo de cualquier proyecto, radica en el aislamiento de recursos primarios del kernel o corazón de una aplicación, permitiendo que ya sea independiente (llamado contenedor) o en conjunto (llamado servicios), puedan armonizar un entorno de aplicación.

❓ Debate
Actualmente, los proveedores de cómputo en la nube, como GCP, permiten el uso de contenedores.
Sin embargo, ¿sabes cuál es la nube que aporta, de manera considerable, al ecosistema de contenedores?

El surgimiento de una era computacional

A partir del 2010, las nubes empezaron a popularizarse como proveedores de servicios y de tecnología clave para la competitividad que se veía por venir.

El creciente número de requerimientos por parte de una empresa que pretendía ser competitiva dentro de un mercado súper acelerad, dependía de aquello que dejaría de ser responsable de la misma, es decir, delegar ciertas responsabilidad "Made in House" (como la administración de servidores), a proveedores externos a la empresa, como lo son las nubes de cómputo.

De esta necesidad, surgieron nuevas arquitecturas, enfoques descentralizados, entre muchos otros nuevos conceptos.

Si de algo tenemos la certeza, es de que nunca sabremos lo que vamos a necesitar durante el desarrollo de un proyecto.

La nube, proveedora de servicios

La nube no es más que un sinónimo del uso, para obtener beneficios sobre la infraestructura como pago por uso (similar a una renta), liberando el monedero para inversión en otras dependencias.

Dependiendo de su ámbito, considere 3 tipos de implementaciones de computo en la nube (variando entre autores):

Nube Privada. La cual hace referencia a aquellos recursos que se usan exclusivamente por una empresa u organización, abstraída en centro de datos internos (intranet) o en la nube en sí.
Nube Pública. La cual hace referencia a aquellos recursos de propiedad del proveedor externo, administrador por un tercero.
Nube híbrida. La cual hace referencia a un modelo de infraestructura donde son combinadas las 2 anteriores, conectando ambas abstracciones de recursos.

Si bien, la computación de la nube muestra rumbos claros de modernización, no siempre es aplicable dichos efectos en nuestra arquitectura en cuestión.

Por ello, se sugiere proyectar una planificación de migración, generalizando y segmentando nuestro monolito en aquellos servicios y/o módulos (generalmente como procesos temporales de acción), con la intención de desarrollar microservicios y serverless computacionales.

Conclusión

La nube es un tecnología que se sigue solicitando día con día, requiriendo que profesionales del campo sean más versátiles en cuanto a la implementación de múltiples recursos informáticos.

Saber por dónde empezar, es una tarea compleja por la cantidad de información que encaras el primer día. Por suerte, "todos los caminos llegan a Roma", así que inicia familiarizándote con la terminología, realizando pequeñas prácticas que te retornen confianza con cada éxito en tu largo camino por descubrir.

MELT: La observabilidad web

Emmanuel Rodríguez — Tue, 26 Jul 2022 16:32:00 +0000

✨ Concepto clave
La Observabilidad describe a aquello de lo que se puede entender y ocurrir dentro de un sistema, utilizando el marco tecnológico METL.

Antecedentes

Saber el mejor rumbo para el desarrollo de una aplicación, es un tema de conversación para cualquier emprendimiento de un proyecto, inclusive, cuando se ha finalizado un MVP (Producto Mínimo Viable).

Antes, al proceso de soporte y mejoramiento del producto, era responsabilidad de una persona llamada Web master, ahora Full Stack.

De la misma forma, los roles y culturas organizaciones han adoptado o modernizados sus prácticas tanto de desarrollo como de despliegue, llamándolas DevOps.

ℹ️ Definición
DevOps es conocido como cultura organizacional, área o rol de profesión, así como también un proceso moderno de integración y despliegue.

El nacimiento de esta vertiente de desarrollo de soluciones, surge por el hecho mismo de la automatización.

"Si el software nació para automatizar, entonces automaticemos nuestro proceso de desarrollo."

Identificación global

Si bien, DevOps es una corriente versátil que colabora en el proceso de desarrollo, no quita la existencia de varios puntos ciegos, es decir, la aparición de anomalías, defectos, fallos y errores.

ℹ️ Definición
Existen 4 grandes eventos ante una funcionalidad no esperada:
- Anomalía, la descripción de un comportamiento no esperado.
- Defecto, situación que se puede reproducir por su origen replicable.
- Fallo, incapacidad del sistema dentro de los márgenes conocidos.
- Error, acción humana que genera el desperfecto en el sistema.

Digamos por ejemplo:

Contamos con un despertador que todas las mañanas a las 9 AM suena su alarma, pero desde hace unos días ya no lo hace, eso es una anomalía, en caso de que hubiera llegado con una manecilla rota, seria defecto, si necesita luz para funcionar que, por una tormenta, se nos va la luz y ya no sirve, es fallo y por último si utilizas tu despertador para otro fin, es un error.

De lo anterior, la observabilidad nos responde y pone en contexto de nuestro sistema y saber, a mediano plazo, los siguientes pasos a desarrollar para mejorar su competitividad y/o uso.

Tendencia y contexto actual

Los sistemas modernos se transforman rápidamente día a día, dentro de contextos complejos que, progresivamente, se van distorsionando y mutando las formas de probar y de aislar sus casos de usos, características, etc.

Antes, las soluciones de software se presentaban con detalles, del modo y mecanismo para probarlas, teniendo la certeza del origen y efecto, cuando se presentaban fallas.

Construir "mejor" software, mediante prácticas de desarrollo moderno, no es la única solución.

Nada es perfecto, aparecen nuevos defectos, la infraestructura esta caída y/o desactualizada, surgen errores que afectan al comportamiento final con el usuario; delegando la responsabilidad a los desarrolladores con crear software que sea más fácil de probar y arreglar, dejando ambigüedades e incertidumbres para liberar características o soluciones, urgentes para encarar un mercado altamente competitivo.

Los 4 componentes fundamentales de la observability o MELT

Actualmente, con la integración de múltiples servicios y modernizando los equipos de desarrollo mediante la especialización individual, podemos generar una observabilidad a través de 4 componentes, integrándolos individualmente o en conjunto.

✨ Concepto clave
Las métricas son medidas numéricas que pueden incluir un estado numérico, en un momento en el tiempo o agregaciones como promedios, totales, etc.

Se tienen un conjunto de valores calculados, los cuales representan diferentes métricas que comparten nombre, tiempo y valor.

Deseamos rastrear tanto el valor total de la compra como el valor promedio de la compra.

Con ello, podemos realizar ciertas preguntas:
¿Cuáles fueron mis ventas durante un período de tiempo en específico?

Para este registro, hemos perdido algunos detalles, ya que no sabemos cuáles fueron las tres compras específicas, ni tenemos acceso a sus valores individuales.

✨ Concepto clave
Un evento se puede definir como una acción discreta que sucede en un determinado momento.

Se tienen un conjunto un conjunto de eventos de compras, de los cuales se ha registrado la compra de diferentes productos con un determinado precio o valor.

Con ello, podemos realizar preguntas como:
¿De cuánto fue la ganancia por ventas?
¿Cuál fue la preferencia de pago?
¿Cuál fue el promedio de selección por producto?

✨ Concepto clave
Los logs son un repositorio de datos que, en su forma más fundamental, son sólo líneas de texto que un sistema produce.

El caso de uso más común para los registros es obtener un resumen detallado, paso a paso, de lo que sucedió en un momento determinado.

A partir de esto, sabemos que se intentó y falló una compra donde podremos replicar el imprevisto, de manera específica.

Conclusión

Como leyó, con MELT es posible obtener un sistema observable que nos permite visualizar y analizar a lo largo de las diferentes capas de una aplicación.

Se dice que un sistema es llamado Full Stack Observable, cuando aplica MELT tanto al frontend como al backend, como al proceso de DevOps como el de infraestructura y, con ello, tener la certeza de aquellas anomalías, defectos, fallos y errores.

Por último, no olvide que existen herramientas que nos permiten adoptar METL sin complicaciones de instalación (Google Analytics, Hotjar, New Relic, invitando a utilizar cada una y aprender de ella como una extensión de su stack tecnológico.