Aprende a gestionar los requisitos de observabilidad como parte de tu ecosistema de microservicios
“Que vivas en tiempos interesantes” es la traducción al inglés de la maldición china, y esto no podría ser más cierto como descripción de los tiempos en los que vivimos en cuanto a nuestra arquitectura de aplicaciones y desarrollo de aplicaciones.
Todos los cambios del enfoque nativo de la nube, incluyendo todas las nuevas tecnologías que vienen con él, como contenedores, microservicios, API, DevOps, etc., han transformado completamente la situación para cualquier arquitectura, desarrollador o administración de sistemas.
Es algo similar si te fuiste a la cama en 2003 y te despiertas en 2020, todos los cambios, todas las nuevas filosofías, pero también todos los desafíos únicos que vienen con los cambios y nuevas capacidades son cosas con las que necesitamos lidiar hoy.
Creo que todos podemos estar de acuerdo en que el presente es políglota en términos de desarrollo de aplicaciones. Hoy no se espera que ninguna gran empresa o corporación encuentre una tecnología disponible, un lenguaje disponible para soportar todos sus productos internos. Hoy todos seguimos y estamos de acuerdo con el principio de “la herramienta adecuada para el trabajo adecuado” para intentar crear nuestro conjunto de herramientas de tecnologías que vamos a usar para resolver diferentes casos de uso o patrones que necesitas enfrentar.
Pero ese acuerdo y movimiento también vienen con su desafío respecto a cosas en las que usualmente no pensamos, como el rastreo y la observabilidad en general.
Cuando usamos una sola tecnología, todo es más sencillo. Definir una estrategia común para rastrear tus flujos de extremo a extremo es fácil; solo necesitas incrustar la lógica en tu marco de desarrollo común o biblioteca que todos tus desarrollos están usando. Probablemente definir una arquitectura de encabezado típica con todos los datos que necesitas para poder rastrear efectivamente todas las solicitudes y definir un protocolo estándar para enviar todos esos rastros a un sistema estándar que pueda almacenarlos y correlacionarlos todos y explicar el flujo de extremo a extremo. Pero intenta mover eso a un ecosistema políglota: ¿Debería escribir mi marco o biblioteca para cada lenguaje o tecnología que necesitaría usar, o también puedo usar en el futuro? ¿Tiene sentido eso?
Pero no solo eso, ¿debería ralentizar la adopción de una nueva tecnología que puede ayudar rápidamente al negocio porque necesito proporcionar desde un equipo compartido este tipo de componentes estándar? Ese es el mejor caso en el que tengo suficiente gente que sabe cómo funcionan los internos de mi marco y tiene las habilidades en todos los lenguajes que estamos adoptando para poder hacerlo rápidamente y de manera eficiente. Parece poco probable, ¿verdad?
Entonces, a nuevos desafíos también nuevas soluciones. Ya he estado hablando sobre Service Mesh respecto a las capacidades que proporciona desde una perspectiva de comunicación, y si no lo recuerdas, puedes echar un vistazo a esas publicaciones:
Pero también proporciona capacidades desde otras perspectivas y el rastreo y la observabilidad es una de ellas. Porque cuando no podemos incluir esas características en cualquier tecnología que necesitemos usar, podemos hacerlo en una tecnología general que sea compatible con todas ellas, y ese es el caso con Service Mesh.
Como Service Mesh es la forma estándar de comunicar sincrónicamente tus microservicios en una comunicación de este a oeste cubriendo la comunicación de servicio a servicio. Entonces, si puedes incluir en ese componente también la capacidad de rastreo, puedes tener un rastreo de extremo a extremo sin necesidad de implementar nada en cada una de las diferentes tecnologías que puedes usar para implementar la lógica que necesitas, así que, has cambiado de la Figura A a la Figura B en la imagen a continuación:
Y eso es lo que la mayoría de las tecnologías de Service Mesh están haciendo. Por ejemplo, Istio, como una de las opciones predeterminadas cuando se trata de Service Mesh, incluye una implementación del estándar OpenTracing que permite la integración con cualquier herramienta que soporte el estándar para poder recopilar toda la información de rastreo para cualquier tecnología que se use para comunicarse a través de la malla.
Entonces, ese cambio de mentalidad nos permite integrar fácilmente diferentes tecnologías sin necesidad de ningún soporte excepcional de esos estándares para cualquier tecnología específica. ¿Significa eso que la implementación de esos estándares para esas tecnologías no es necesaria? En absoluto, eso sigue siendo relevante, porque las que también soportan esos estándares pueden proporcionar aún más información. Después de todo, el Service Mesh solo conoce parte de la información que es el flujo que está sucediendo fuera de cada tecnología. Es algo similar a un enfoque de caja negra. Pero también agregar el soporte para cada tecnología al mismo estándar proporciona un enfoque adicional de caja blanca como puedes ver gráficamente en la imagen a continuación:
Ya hablamos sobre el cumplimiento de algunas tecnologías con el estándar OpenTracing como TIBCO BusinessWorks Container Edition que puedes recordar aquí:
Entonces, también, el soporte de estas tecnologías de los estándares de la industria es necesario e incluso una ventaja competitiva porque sin necesidad de desarrollar tu marco de rastreo, puedes lograr un enfoque de Datos de Rastreo Completo adicional a lo que ya proporciona el nivel de Service Mesh en sí mismo.
