Observabilidad de aplicaciones: guía práctica para líderes de ingeniería

La observabilidad de aplicaciones es la capacidad de entender por qué el software se comporta como lo hace examinando las señales que produce: registros, métricas, trazas y, cuando resulta útil, datos sobre la experiencia real de los usuarios. Proporciona a los ingenieros el contexto necesario para investigar un fallo desconocido sin tener que añadir primero registros temporales, reconstruir una solicitud a partir de varias herramientas desconectadas o depender de la persona que casualmente recuerda cómo funciona el sistema.

Para los líderes de ingeniería, la observabilidad no es principalmente una compra de herramientas. Es una capacidad operativa. Conecta el comportamiento en producción con los flujos de trabajo de clientes y del negocio que dependen de él, proporciona a los equipos una forma compartida de diagnosticar problemas y hace que los lanzamientos y los incidentes dependan menos de las suposiciones.

El punto de partida sensato rara vez es “instrumentarlo todo”. Empieza con dos o tres flujos críticos: los recorridos en los que un fallo, una latencia o unos datos incorrectos tienen un efecto significativo en los clientes, los ingresos, las operaciones o la prestación del servicio. Desarrolla una visibilidad útil en esas áreas, establece prácticas de responsabilidad y respuesta, y después amplía el alcance de forma deliberada.

 

La observabilidad de aplicaciones de un vistazo

Pregunta	Respuesta práctica
¿Qué es la observabilidad de aplicaciones?	La capacidad de investigar el comportamiento de una aplicación mediante telemetría correlacionada, incluidos registros, métricas, trazas y señales relevantes de la experiencia del usuario.
¿Por dónde debe empezar un equipo?	Empieza con dos o tres flujos de usuarios u operaciones críticos para el negocio, en lugar de intentar instrumentar todo el sistema de una sola vez.
¿Qué telemetría es esencial?	Los registros proporcionan detalles de los eventos, las métricas muestran tendencias y el estado del servicio, y las trazas muestran cómo se desplazan las solicitudes individuales por los servicios y las dependencias.
¿Por qué utilizar OpenTelemetry?	Proporciona un marco ampliamente adoptado e independiente del proveedor para generar y exportar telemetría, lo que ayuda a separar la instrumentación de la plataforma de backend utilizada para analizarla.
¿Qué deben representar las alertas?	Condiciones que afectan a los usuarios o que son importantes para las operaciones, vinculadas a objetivos de nivel de servicio, no cada cambio en una métrica ni cada error aislado.
¿Quién es responsable de la observabilidad?	Los equipos de aplicaciones son responsables del comportamiento de sus servicios; los equipos de plataforma, DevOps o SRE facilitan la adopción de estándares, herramientas y prácticas operativas fiables.

¿Qué es la observabilidad de aplicaciones?

La observabilidad suele confundirse con la monitorización. La monitorización es importante, pero normalmente responde a una pregunta más limitada: ¿hay algo fuera de un límite esperado? Un monitor puede indicar que la tasa de errores ha aumentado, que la profundidad de la cola está creciendo o que la latencia ha superado un umbral.

La observabilidad ayuda a un equipo a investigar por qué ha ocurrido eso. Permite conectar un síntoma visible para el usuario con una solicitud, un servicio, una dependencia, una consulta a la base de datos, una versión del despliegue o un cambio de configuración que haya contribuido al problema.

Esta distinción adquiere mayor importancia a medida que los sistemas se distribuyen. En una aplicación sencilla, un ingeniero puede inspeccionar el registro de un único servicio e identificar el problema. En un sistema con API, colas, servicios en la nube, dependencias de terceros, procesamiento de eventos y varios componentes de aplicaciones, las evidencias suelen estar repartidas en distintos lugares. La observabilidad proporciona el contexto necesario para conectarlas.

Una práctica de observabilidad útil combina:

• Instrumentación: generar telemetría que represente comportamientos importantes del sistema y del negocio.
• Correlación: transportar el contexto de trazas y solicitudes a través de los límites entre servicios para que los eventos relacionados puedan examinarse conjuntamente.
• Investigación: proporcionar a los ingenieros formas útiles de explorar el comportamiento durante incidentes, lanzamientos y trabajos de rendimiento.
• Respuesta operativa: definir quién recibe las señales, cómo evalúa el impacto y qué medidas puede tomar.
• Mejora continua:utilizando incidentes, problemas de soporte y la experiencia de entrega para mejorar la instrumentación y los manuales operativos con el tiempo.

Por qué la observabilidad de las aplicaciones es importante para el negocio

Los líderes no necesitan observabilidad simplemente porque un sistema tenga microservicios o porque el panel de un proveedor resulte impresionante. La necesitan cuando los flujos de trabajo importantes son difíciles de diagnosticar, los incidentes que afectan a los clientes tardan demasiado en comprenderse, las implementaciones generan incertidumbre o los equipos de soporte carecen de pruebas para distinguir un problema del usuario de un problema del sistema.

Cuando se diseña en torno a flujos de trabajo significativos, la observabilidad puede ayudar a los equipos a:

• Reducir el tiempo dedicado a encontrar pruebas relevantes durante los incidentes
• Identificar si una implementación, dependencia, cambio de configuración o patrón de tráfico está asociado con una degradación
• Priorizar el trabajo de fiabilidad en función del impacto en los clientes y las operaciones
• Hacer que la respuesta de guardia dependa menos del conocimiento individual del sistema
• Mejorar las conversaciones entre las partes interesadas de ingeniería, producto, soporte y negocio
• Reconocer patrones de fallo recurrentes antes de que se conviertan en problemas operativos normalizados

El valor para el negocio proviene de tomar decisiones más rápidas y fiables, no de recopilar la mayor cantidad de telemetría. Una organización puede generar enormes volúmenes de registros y métricas sin poder responder a una pregunta básica como: “¿Por qué los clientes no pueden completar este flujo de trabajo hoy?”

Por tanto, la observabilidad debe comenzar con los flujos de trabajo importantes. Algunos ejemplos podrían incluir la creación de cuentas, el proceso de pago, el procesamiento de pagos, la programación de citas, una importación de datos, un proceso de enrutamiento de pedidos o un informe orientado al cliente. Los flujos exactos dependen del producto y del modelo operativo de la organización.

Registros, métricas, trazas y señales de experiencia de usuario

Los distintos tipos de telemetría responden a preguntas diferentes. El valor proviene de utilizarlos conjuntamente con un contexto coherente, no de tratar uno como sustituto de los demás.

Registros: ¿qué ocurrió?

Los registros documentan eventos discretos. Son útiles cuando una investigación necesita contexto detallado: un mensaje de error, un fallo de validación, una respuesta de una dependencia, una decisión de autorización o un evento específico de la aplicación.

Los buenos registros de producción están estructurados, se pueden buscar y se generan de forma deliberada. Deben incluir contexto suficiente para investigar un problema, evitando al mismo tiempo información confidencial innecesaria. Registrar datos personales, financieros, de autenticación o de pago sin procesar en sistemas de acceso amplio crea una categoría de riesgo diferente.

Métricas: ¿se dirige el sistema hacia un problema?

Las métricas miden valores a lo largo del tiempo: tasa de solicitudes, tasa de errores, profundidad de la cola, uso de CPU, conexiones a la base de datos, transacciones correctas o finalización de flujos de trabajo. Son útiles para identificar patrones, establecer líneas base, definir objetivos de servicio y detectar un problema en desarrollo.

En los flujos de trabajo orientados al cliente, los percentiles como la latencia p50, p95 y p99 suelen ser más útiles que las medias por sí solas. Una media puede parecer aceptable mientras una parte significativa de los clientes experimenta interacciones lentas o fallidas.

Trazas: ¿adónde fue la solicitud?

Las trazas siguen una solicitud o evento individual a través de servicios y dependencias. En un sistema distribuido, una traza puede revelar cómo se distribuyen el tiempo y los fallos entre llamadas a API, colas, bases de datos, trabajos en segundo plano y servicios de terceros.

El contexto de las trazas debe atravesar los límites de forma coherente. Si la traza termina cuando una solicitud entra en una cola de mensajes o llama a un servicio externo crítico, el equipo pierde visibilidad justo en el punto donde suelen comenzar las investigaciones difíciles.

Monitorización de usuarios reales: ¿qué experiencia tuvo el usuario?

La monitorización de usuarios reales, la telemetría del navegador y el contexto de las sesiones pueden añadir una valiosa perspectiva del lado del cliente. Los servicios de backend pueden parecer saludables mientras los usuarios sufren errores del navegador, renderizado lento, interacciones fallidas, problemas geográficos, barreras de accesibilidad o problemas específicos del dispositivo.

Estas señales deben recopilarse con controles adecuados de privacidad, conservación y acceso. El objetivo es comprender la experiencia de un flujo de trabajo, no capturar más datos de clientes de los que la organización necesita.

Regla práctica: Incluya desde el principio en la telemetría la versión de la implementación, el entorno, el nombre del servicio y el identificador del flujo de trabajo correspondiente. Sin ese contexto, correlacionar una regresión con una versión concreta o un cambio del sistema se vuelve innecesariamente difícil.

Comience con flujos críticos, no con una cobertura universal

Los equipos suelen intentar introducir la observabilidad instrumentando todos los servicios, creando paneles para cada métrica y generando alertas para cada condición inusual. Este enfoque puede crear costes elevados de telemetría, alertas ruidosas, etiquetas incoherentes y una colección de paneles en la que nadie confía durante un incidente.

Un enfoque más práctico comienza con dos o tres flujos importantes para los usuarios o las operaciones. Para cada uno, defina:

• El resultado para el usuario o el negocio que se espera que produzca el flujo
• Los componentes de la aplicación, almacenes de datos, colas y dependencias externas implicados
• Las señales que indican una finalización correcta, una degradación o un fallo
• Los límites aceptables de rendimiento y fiabilidad
• El equipo o rol responsable de responder cuando se superan esos límites
• La información necesaria para investigar y recuperarse de un fallo

Por ejemplo, un flujo de envío de pedidos podría requerir visibilidad sobre las solicitudes de los usuarios, la latencia de la API, la validación del inventario, las respuestas del proveedor de pagos, los eventos de creación de pedidos, los mensajes asíncronos de preparación y la confirmación final mostrada al cliente. El objetivo no es capturar todos los detalles posibles, sino proporcionar pruebas suficientes para determinar dónde falló el flujo y qué debe ocurrir a continuación.

Este enfoque está estrechamente relacionado con una buena arquitectura de transmisión de eventosSi el trabajo importante se mueve de forma asíncrona a través de colas o eventos, los equipos necesitan una forma de seguir un evento desde su origen, pasando por el procesamiento, los reintentos y los fallos, hasta su finalización.

Instrumentación con OpenTelemetry

OpenTelemetry es un marco de observabilidad de código abierto y un conjunto de especificaciones para generar, recopilar y exportar telemetría. Ayuda a los equipos a estandarizar la instrumentación entre servicios, manteniendo la flexibilidad en las plataformas utilizadas para almacenar, consultar y visualizar los datos resultantes.

La instrumentación independiente del proveedor no significa que todas las plataformas sean intercambiables. Los backends de observabilidad difieren en coste, facilidad de uso, retención, capacidad de consulta, integración con el ecosistema, controles de seguridad y carga operativa. Sí significa que cambiar o combinar plataformas de backend no requiere necesariamente reescribir la instrumentación de la aplicación desde cero.

Varias decisiones de implementación determinan si OpenTelemetry sigue siendo útil a medida que crece su adopción:

• Instrumentación automática frente a manual: la instrumentación automática puede proporcionar una cobertura inicial rápida; la instrumentación manual añade el contexto empresarial necesario para comprender los flujos de trabajo importantes del dominio.
• Propagación del contexto de trazas: garantizar que los identificadores de traza se transmitan a través de llamadas HTTP, mensajes asíncronos, procesadores de trabajos y límites externos compatibles.
• Convenciones semánticas: establecer una nomenclatura coherente para servicios, entornos, despliegues, operaciones y atributos antes de que cada equipo invente un formato diferente.
• Correlación con los despliegues: asociar versiones, lanzamientos, indicadores de funcionalidades y cambios de entorno con la telemetría para que los equipos puedan investigar las regresiones con eficacia.
• Tratamiento de datos: definir qué no debe incluirse nunca en spans, registros o etiquetas de métricas, especialmente datos personales, credenciales, tokens e información de pagos.
• Muestreo: capturar suficientes datos representativos y relacionados con errores para investigar comportamientos importantes sin recopilar indefinidamente todos los eventos.

En un monolito heredado, los cambios amplios en el código no siempre son el mejor primer paso. Instrumenta una ruta de solicitud crítica, los principales límites de integración y las colas de trabajo o tareas que respaldan el flujo de trabajo. Esto produce información útil y, al mismo tiempo, reduce el riesgo de que una iniciativa de instrumentación de gran escala se convierta en un proyecto de reescritura.

La documentación de OpenTelemetry es la referencia técnica principal para sus especificaciones, SDK, recopiladores, opciones de instrumentación y convenciones semánticas.

SLO, alertas y el coste de la telemetría

Los objetivos de nivel de servicio, o SLO, proporcionan al equipo una definición compartida de la fiabilidad aceptable de un servicio o flujo de trabajo. Un SLO útil refleja lo que experimentan los usuarios o los equipos dependientes, como la finalización correcta de una compra, la disponibilidad de una API, la finalización de trabajos en segundo plano o una latencia de respuesta dentro de un umbral acordado.

Es útil distinguir tres conceptos:

• SLI: el indicador de nivel de servicio que se mide, como solicitudes correctas, finalización del flujo de trabajo o latencia p95.
• SLO: el objetivo de fiabilidad para ese indicador durante un periodo definido.
• Presupuesto de errores: la cantidad de falta de fiabilidad que el servicio puede soportar sin dejar de cumplir su objetivo.

No todas las métricas necesitan un SLO, ni todos los SLO necesitan una alerta a un buscapersonas. Empieza por los servicios y recorridos en los que un fallo prolongado tenga una consecuencia clara para el cliente, las operaciones o las finanzas.

Las alertas también deben ser proporcionales. Una alerta útil proporciona al destinatario un motivo para actuar. Si una alerta no indica impacto, urgencia, responsabilidad o un siguiente paso práctico, es probable que se convierta en ruido.

Los errores habituales al configurar alertas incluyen:

• Enviar alertas a personas por cada error aislado en lugar de hacerlo ante una degradación sostenida que afecte a los usuarios
• Crear alertas sobre síntomas de la infraestructura sin relacionarlos con el estado del servicio o del flujo de trabajo
• Enviar alertas a equipos que no pueden emprender ninguna acción significativa
• Crear paneles y alertas sin una respuesta o guía operativa documentada
• Dejar activas alertas obsoletas después de que cambien los servicios, los umbrales o las condiciones operativas

El coste de la telemetría requiere la misma disciplina. Las dimensiones de alta cardinalidad, como los identificadores de usuario o de solicitud únicos asociados a cada etiqueta de métrica, pueden generar costes considerables de almacenamiento y consulta. Los identificadores detallados aún pueden ser útiles en trazas y registros estructurados para flujos críticos seleccionados. La decisión debe ser deliberada: utiliza dimensiones que faciliten la investigación, aplica muestreo cuando corresponda, establece políticas de retención y revisa el coste junto con el valor operativo.

La observabilidad requiere responsabilidad y prácticas de gestión de incidentes

La telemetría solo resulta útil cuando las personas pueden actuar basándose en ella. Un panel sin responsable, una alerta sin una ruta de escalado o una traza que requiere acceso especializado durante cada incidente no crean una capacidad operativa eficaz.

La responsabilidad debe ser explícita sin convertir a un único equipo de plataforma en el cuello de botella permanente para cada investigación. En muchas organizaciones:

• Equipos de aplicaciones son responsables del estado, la instrumentación, los procedimientos operativos y los objetivos de servicio de las aplicaciones que desarrollan y mantienen.
• Equipos de plataforma, DevOps o SRE proporcionan herramientas compartidas, estándares, patrones de incorporación, controles de acceso y orientación operativa.
• Líderes de producto y operaciones ayudan a identificar qué recorridos son importantes, qué significa un rendimiento aceptable y cómo debe evaluarse el impacto en los clientes o las operaciones.
• Responsables de seguridad y cumplimiento orientan sobre los requisitos de tratamiento de datos, conservación, acceso y auditoría cuando corresponda.

Los equipos también necesitan tiempo para practicar. Una revisión de incidentes no debe ser una búsqueda de culpables. Debe examinar qué reveló el sistema, qué fue difícil de determinar, qué decisiones se retrasaron y qué cambio en la instrumentación, los procedimientos operativos, la arquitectura o los procesos facilitaría la gestión del próximo incidente.

Esto depende de que los equipos de ingeniería tengan suficiente autonomía para investigar y actuar dentro de los límites acordados. Nuestro artículo sobre la autonomía de ingeniería y la cultura de equipo explica por qué la responsabilidad clara y la confianza son importantes cuando los equipos responden de los resultados, en lugar de limitarse a ejecutar tareas asignadas.

Plan práctico para desplegar la observabilidad de aplicaciones

La observabilidad de aplicaciones se implementa mejor por etapas. El objetivo es establecer un patrón técnico y operativo reutilizable antes de ampliarlo a todo el entorno.

1. Elige los flujos críticos. Identifica dos o tres recorridos de usuario u operativos cuyo fallo genere un impacto significativo. Utiliza el historial de incidentes, el volumen de solicitudes de soporte, la dependencia del negocio y los riesgos de las próximas entregas para orientar la elección.
2. Mapea el flujo. Documenta las aplicaciones, los servicios, los almacenes de datos, las colas, la infraestructura, las dependencias externas, los equipos y las transferencias involucradas desde el inicio hasta la finalización correcta.
3. Define las señales de éxito y fallo. Identifica los eventos, las métricas, las trazas y los resultados visibles para el usuario necesarios para determinar si el flujo funciona correctamente.
4. Establece la responsabilidad y las expectativas de respuesta. Define el responsable del servicio, la ruta de guardia o escalado, los destinatarios de las alertas, los derechos de decisión y los pasos iniciales de investigación o recuperación.
5. Instrumenta la ruta crítica. Añade instrumentación de OpenTelemetry o compatible en los límites de la aplicación, la integración y el procesamiento asíncrono. Aplica nombres, atributos y contexto de despliegue coherentes.
6. Crea paneles y alertas específicos. Crea vistas para el flujo y alertas vinculadas a una degradación significativa. Evita paneles generales que intenten representar todas las condiciones posibles.
7. Prueba la investigación y la recuperación. Utiliza un fallo controlado, una prueba de carga, una versión o un ejercicio de incidentes para verificar que el equipo puede encontrar las evidencias pertinentes y seguir la ruta de respuesta.
8. Revisa y amplía. Mejora las etiquetas, el muestreo, las alertas, los procedimientos operativos, el acceso y los controles de costes antes de pasar a flujos de trabajo adyacentes.

Todo despliegue tiene dependencias que van más allá de la tecnología. Los ingenieros necesitan acceso a las señales de producción. Los responsables de producto y operaciones deben ayudar a definir resultados significativos para los usuarios. Los equipos necesitan tiempo para revisar los hallazgos y ajustar el sistema. Un plan que solo tenga en cuenta el esfuerzo de instrumentación, ignorando la responsabilidad, el acceso, la toma de decisiones y la práctica de gestión de incidentes, normalmente se estancará después de crear el primer panel.

Dónde suelen fallar los esfuerzos de observabilidad

La mayoría de los problemas de observabilidad son predecibles. Abordarlos pronto cuesta menos que intentar recuperar la adopción después de que los equipos hayan perdido la confianza en las señales.

Instrumentarlo todo primero

Una cobertura amplia parece exhaustiva, pero a menudo genera costes elevados y poca claridad. Empieza por los flujos críticos, demuestra que el equipo puede utilizar las señales y, después, amplía el alcance siguiendo un patrón coherente.

Recopilar datos sin contexto

Una métrica o un registro son mucho menos útiles cuando no pueden vincularse al servicio, el entorno, la versión, la solicitud, el flujo de trabajo, el inquilino o el contexto de las dependencias. Define convenciones antes de que las etiquetas incoherentes resulten costosas de depurar.

Alertas sin una vía de actuación

Si una alerta no tiene un responsable, un manual de procedimientos, una vía de escalado o un umbral de decisión, se convierte en otra fuente de ruido. La solución no consiste simplemente en subir o bajar el umbral, sino en diseñar la alerta en torno a una decisión operativa.

Tratar la observabilidad únicamente como un proyecto de plataforma

Las herramientas centralizadas son valiosas, pero los equipos más cercanos a la aplicación entienden qué eventos del dominio, modos de fallo y resultados para el usuario son importantes. La observabilidad funciona mejor cuando los estándares de la plataforma y la responsabilidad a nivel de aplicación se refuerzan mutuamente.

Ignorar el coste de la telemetría y el riesgo de los datos

La recopilación ilimitada, las métricas con alta cardinalidad, la retención prolongada y los datos sensibles en los registros pueden perjudicar el programa. Incluye desde el principio en el diseño el muestreo, la retención, las reglas de atributos, el acceso y la revisión de costes.

Cuándo puede ayudar un socio externo

El apoyo externo puede ser útil cuando las carencias de observabilidad son síntomas de un problema más amplio de ingeniería y entrega: aplicaciones heredadas difíciles de instrumentar, infraestructura fragmentada, responsabilidades de servicio poco claras, prácticas de gestión de incidentes inexistentes, un proceso de lanzamiento poco fiable o un riesgo inmediato para la fiabilidad que el equipo interno no puede posponer de forma segura.

Ridiculous Engineering ayuda a las organizaciones a evaluar su nivel actual de madurez en observabilidad, identificar flujos de alto valor, establecer patrones prácticos de instrumentación, mejorar las prácticas de entrega y gestión de incidentes, y crear un modelo de transferencia que el equipo interno pueda operar. El objetivo no es crear una dependencia permanente de una consultoría o de una herramienta específica, sino facilitar la comprensión de los sistemas y aumentar la capacidad de los equipos para mejorarlos.

Este trabajo suele realizarse junto con una mejora más amplia de DevOps, infraestructura como código, y prácticas de despliegue fiables.

Preguntas frecuentes

¿Qué es la observabilidad de aplicaciones?

La observabilidad de aplicaciones es la capacidad de comprender el comportamiento de una aplicación examinando telemetría correlacionada, como registros, métricas y trazas. Ayuda a los equipos a investigar por qué ocurrió un problema, dónde falló una solicitud o un evento y qué condición del sistema contribuyó al resultado.

¿Cuál es la diferencia entre observabilidad y monitorización?

La monitorización identifica condiciones conocidas que requieren atención, como una tasa de errores elevada o una disponibilidad baja. La observabilidad proporciona el contexto necesario para investigar comportamientos desconocidos o complejos explorando registros, métricas, trazas, lanzamientos, dependencias y eventos del flujo de trabajo relacionados.

¿Cuáles son los principales tipos de datos de observabilidad?

Los tres tipos principales de telemetría son los registros, las métricas y las trazas. Los equipos también pueden utilizar la monitorización de usuarios reales, la telemetría del navegador, los perfiles, los eventos, el contexto de sesión y las pruebas sintéticas cuando esas señales ayudan a explicar la experiencia de un flujo de trabajo crítico.

¿Por qué deberían utilizar OpenTelemetry los equipos?

OpenTelemetry proporciona especificaciones abiertas, API, SDK, recopiladores y convenciones semánticas para la telemetría. Puede ayudar a los equipos a estandarizar la instrumentación y reducir la dependencia de un único backend de observabilidad, al tiempo que les permite elegir herramientas que se adapten a sus necesidades operativas.

¿Cómo iniciamos una iniciativa de observabilidad?

Empieza con dos o tres flujos de usuario u operativos críticos. Mapea los sistemas y las dependencias implicados, define los resultados correctos e incorrectos, identifica la telemetría necesaria para investigar los problemas, asigna responsabilidades, instrumenta el recorrido crítico y prueba el proceso de respuesta antes de ampliar el alcance.

¿Qué provoca el aumento de los costes de observabilidad?

Los costes pueden aumentar debido a un volumen elevado de eventos, atributos de alta cardinalidad sin límites, periodos de retención prolongados, recopilación duplicada, trazas amplias con fidelidad completa y telemetría que ningún equipo utiliza. El muestreo, las políticas de retención, unas reglas claras para los atributos y las revisiones periódicas de costes ayudan a mantener la recopilación en proporción con el valor operativo.

Fuentes

• Documentación de OpenTelemetry
• Cuaderno de SRE de Google: implementación de objetivos de nivel de servicio
• Cuaderno de SRE de Google: alertas sobre los SLO

Recomendado

• Los días difíciles de DevOps: optimización del desarrollo y las operaciones
• Infraestructura como código: guía de un ingeniero de DevOps para 2026
• Implementaciones sin tiempo de inactividad: guía práctica para ingenieros
• Transmisión de eventos con Kafka: guía práctica para ingenieros
• Consultoría de software y asistencia para la entrega