El mundo sin servidor está creciendo constantemente con conjuntos de características y el número de adoptantes. Si bien esto puede parecer genial, puede conducir a problemas de crecimiento rápido como perder el verdadero significado de serverless.
Como comunidad, necesitamos volver a lo básico. Hemos aprendido y establecido patrones cómodos, pero no los hemos compartido. Al menos, no lo suficiente. Obtendrás dos respuestas muy diferentes si coges a dos desarrolladores serverless y les preguntas cómo realizar una tarea.
Cada vez más la industria nos invita a centraremos en las mejores prácticas, normalizar los patrones arquitectónicos y diseñarlos para el crecimiento.
Debemos familiarizarnos con las mejores prácticas establecidas, las normas de arquitectura y los principios de diseño de fuentes acreditadas como Serverless Land y refactorizar gradualmente nuestras aplicaciones para adherirnos a ellas.
Uno de los componentes más importantes que debemos tener en cuenta e incorporar a nuestras aplicaciones es el enfoque del ejercicio. Tenemos que centrarnos en la observabilidad.
¿Por qué observabilidad?
Muchos de nosotros nos dejamos llevar por la atracción de construir aplicaciones rápidamente con serverless y olvidamos algunos de los fundamentos de la soportabilidad. Yo no soy una excepción. He construido muchas arquitecturas de referencia que no incluyen ninguna forma de observabilidad en la plantilla.
Si tu quieres profundizar en esto, te dejo el siguiente video
Sé que no soy el única 😁
Veo todo el tiempo arquitecturas de referencia que omiten la observabilidad. Como resultado, los desarrolladores que utilizan estos proyectos de referencia como base para su trabajo tampoco la incluyen. Luego esos proyectos se utilizan como base para proyectos posteriores y no incluyen herramientas de observabilidad. Y así sucesivamente.
Antes de que nos demos cuenta, estamos a dos semanas de la entrada en producción 😰, pasando por una revisión de la disponibilidad operativa, y nos damos cuenta de que no tenemos forma de supervisar la aplicación.
Volviendo a lo básico y creando una mentalidad de observabilidad, podemos evitar situaciones como ésta y crear aplicaciones sólidas y mantenibles desde el principio.
¿Qué tipo de observabilidad?
La compilación inicial de una aplicación es sólo una pequeña parte de su vida. Una vez finalizada, entra en el ciclo de vida de mantenimiento. Aquí es donde los equipos de soporte y mantenimiento resuelven los problemas y realizan mejoras.
Para muchas aplicaciones, el ciclo de vida de mantenimiento será >90% de su tiempo en el campo. Esto significa que las herramientas de soporte deben estar a punto.
La mejor forma de mejorar la capacidad de soporte de una aplicación sin servidor es crear capacidades de supervisión que permitan a los usuarios rastrear los flujos de trabajo a través del sistema. Debe ver las cargas útiles que llegan a través de la solicitud inicial y realizar un seguimiento de la ruta que sigue a través de su infraestructura.
Ver cómo los datos atraviesan el sistema y cómo se transforman entre servicios es fundamental para identificar y resolver problemas. Los datos se mueven rápidamente por las arquitecturas basadas en eventos. Confiar en los registros de una única función Lambda a menudo no es suficiente para aislar un problema.
Pero no es lo único que necesitamos.🤪
Para ofrecer la mejor experiencia a nuestros usuarios, queremos proporcionar el menor número posible de degradaciones o interrupciones del servicio. Desde el punto de vista de la observabilidad, necesitamos implementar una monitorización proactiva para vigilar y encontrar problemas antes de que lo hagan los usuarios.
Con serverless, la monitorización proactiva se consigue normalmente mediante alarmas. Estas alarmas podrían vigilar colas de letra muerta, detectar anomalías métricas, rastrear latencias, monitorizar códigos de respuesta 5XX, etc. Las alarmas adecuadas para construir en su aplicación son las que aseguran que usted está golpeando su SLA y KPIs.
Cómo empezar
Sería fácil lanzarse e instrumentar sus aplicaciones con uno de los muchos proveedores de Application Performance Monitoring (APM) disponibles hoy en día. Pero le animo a que no lo haga inmediatamente.
Antes de escribir ningún código, realiza un análisis.
¿Cuáles son tus KPI? ¿Qué aspecto tienen sus cargas de trabajo? ¿Reintenta los fallos o los envía a DLQ? ¿Sabe cómo fluyen los datos por su sistema?
Comprender tu sistema es el primer paso para una observabilidad adecuada.
Cuando empecé a desarrollar sin servidor, me entusiasmaba la idea de enviar registros y datos de seguimiento a una herramienta APM de terceros. Lo añadimos al principio, y los datos comenzaron a fluir en la herramienta. Después de la palmadita inicial en la espalda, me quedé pensando, "¿y ahora qué?"
Resumen
Hemos aprendido mucho en 2022. Probablemente avanzamos un poco más rápido de lo que deberíamos. Este año revisaremos nuestro trabajo, analizaremos lo que hemos hecho y utilizaremos las herramientas adecuadas para construir software altamente mantenible.
Volvemos a la base. Tomar las lecciones que hemos aprendido y construir las mejores prácticas a partir de ellas. Converger en patrones y arquitecturas probadas.
La observabilidad es a menudo una idea tardía. No debería ser así. Es una parte fundamental de una arquitectura sin servidor.
Seguir las cargas de trabajo en los procesos de extremo a extremo le proporcionará una soportabilidad inmejorable. Las métricas de infraestructura alarmantes que se salen de sus KPI proporcionan una disponibilidad inigualable.
La soportabilidad y la disponibilidad proporcionan a nuestros usuarios finales la mejor experiencia posible, que es realmente de lo que se trata.
Dediquemos tiempo a considerar la observabilidad en primer lugar, comprendamos lo que estamos construyendo y ofrezcamos el mejor software posible.
¡Feliz programación! ✌🏻
