OpenTelemetry (I): un edge cada vez menos distante
Hay muchos motivos por los que confiar en Fastly, y uno de ellos es que siempre estamos al lado de los usuarios finales: tenemos una capacidad de respuesta de apenas milisegundos. Quizá por eso podrías pensar que Fastly está fuera de tu sistema, en el frontend. Si quieres sentir que de verdad forma parte de la arquitectura de tu aplicación, tienes que observar el sistema como un todo, desde un solo lugar. Y aquí es donde entra en juego OpenTelemetry, un nuevo estándar que te puede resultar muy útil.
Al principio, cuando se crearon las primeras aplicaciones descentralizadas para la web, había que tener en cuenta todos los componentes de la arquitectura de la aplicación: los servidores físicos, los sistemas operativos, el software del servidor, las bases de datos y, por último, el código.
Ahora, gracias a la revolución de los entornos sin servidores, todo es mucho más simple: ya no hace falta instalar nada para escribir código con las funcionalidades de la nube, suscribirse a una base de datos de un proveedor SaaS o enviar consultas con el código que has escrito hace un segundo.
Puedes ejecutar tu código en muchos más sitios, incluso en plataformas que a menudo tienen una vida más corta. Por ejemplo, si no se ha aprovisionado correctamente el entorno en que se ejecuta tu código y solo dura unos segundos, eso ya no es un problema. Pero no es oro todo lo que reluce, dado que este panorama conlleva un nuevo desafío: llevar un seguimiento de qué se ejecuta, dónde y para quién. Además, si algo falla, ¿qué falla exactamente? ¿Dónde? ¿Por qué?
Supongamos que tienes una arquitectura de microservicios creada para el sitio web de un periódico con esta estructura:
Es una arquitectura más o menos simple, pero tiene aspectos interesantes:
Las peticiones que se distribuyen a nivel global se concentran en un punto cercano a tu infraestructura central mediante dos capas de Fastly. Esta es nuestra funcionalidad de protección.
Mientras algunas peticiones se procesarán por completo en una ubicación del edge, otras necesitarán una llamada a un servicio no relacionado con Fastly que se realiza desde el edge.
Un servicio de puerta de enlace que se ejecute en tu plataforma de nube troncal tocará múltiples microservicios.
Pueden ser de tres tipos: servicios SaaS de proveedores «opacos», servicios propios y servicios con un frontend de Fastly o alojados allí.
Diversos proveedores, un número de capas indeterminado o imposible de determinar, servicios opacos, referencias aparentemente circulares… ¡No temas! Si todos estos componentes entienden el lenguaje de OpenTelemetry (OTel), es posible plantear un viaje completo por este sistema mediante una única interfaz que aglutina toda esta información:
No solo instrumenta los componentes de tu sistema; OpenTelemetry te permite usar más de un proveedor de observabilidad. El seguimiento que hemos visto antes se presenta con Honeycomb, un servicio que está muy bien. Pero si prefieres otro, también puedes usar Lightstep o New Relic; e incluso podrías ejecutar el análisis por tu cuenta con una herramienta autohospedada de código abierto como Zipkin. Todos estos servicios pueden leer el mismo formato de telemetría, por lo que dispones de un amplio abanico de posibilidades.
El ejemplo anterior muestra intervalos de los servidores del edge de Fastly que anidan en torno a otros intervalos de una instancia de Google App Engine. La ventaja de tener un estándar abierto es que cualquier sistema puede generar los datos de seguimiento en cualquier lenguaje y el propio recopilador puede leerlos y analizarlos. Existen bibliotecas para la mayoría de ellos. En el caso de nuestro ejemplo, utilizo la instrumentación estándar de NodeJS, que puede recopilar intervalos de forma automática con una aplicación de ExpressJS.
OpenTelemetry y Fastly
Disponemos de dos métodos para ejecutar las aplicaciones en la red del borde de Fastly: la plataforma VCL y Compute. Aunque puedes obtener datos de ambas para OpenTelemetry, el proceso es distinto en cada caso:
Con el servicio VCL, debes usar nuestro registro en tiempo real y un punto de conexión HTTPS para enviar un seguimiento de OpenTelemetry en formato JSON a un recopilador de OpenTelemery que esté configurado para aceptar OTLP mediante HTTP.
Con Compute, hay que usar las bibliotecas de OpenTelemetry de Fastly para JavaScript, que hemos creado especialmente para facilitar el uso de OpenTelemetry en proyectos de Compute.
Ambos métodos están bastante extendidos entre los clientes de Fastly, de varios sectores y países. Yo mismo he colaborado en la telemetría de Condé Nast, la editorial que publica revistas como Wired, GQ o Vogue. Todos nuestros clientes presentan arquitecturas complejas y diversas que combinan tecnología local, informática en la nube, PaaS de proveedores y SaaS con servicios sin servidores, aplicaciones de una página de frontend y aplicaciones nativas.
Poco a poco, todos los engranajes de esta maquinaria tan compleja propia de la era digital empiezan a utilizar el mismo lenguaje de OpenTelemetry. Cada uno de estos elementos puede contribuir ahora a la misma historia de las transacciones o peticiones que recorren los sistemas de esta maquinaria.
Somos conscientes de que Fastly no será la única plataforma que uses, y tampoco queremos acaparar toda tu atención: no siempre tenemos la mejor solución para todos los problemas. Lo que más nos gusta de OpenTelemetry es que hace brillar a Fastly como parte integrante de la arquitectura que quieres crear:
No te ata a un único proveedor (ni siquiera a nosotros).
Te permite elegir la herramienta de análisis e información que mejor se adapte a ti.
Convierte a Fastly en un componente destacado de la arquitectura de tu sistema.
En las próximas semanas publicaremos las siguientes partes, con más detalles sobre cómo extraer OpenTelemetry de los servicios de VCL y . También veremos un caso práctico en el que usamos OpenTelemetry para supervisar nuestra propia herramienta de Fiddle.
Ya están publicadas las cuatro partes de nuestra serie de artículos sobre OpenTelemetry:
