Serverless en Producción, Lecciones desde las Trincheras

Hola a todos, gracias por unirse a esta charla donde les contaré algunas de las lecciones que he aprendido al ejecutar cargas de trabajo en producción con serverless en los últimos cinco años. Mi nombre es Yen Chui. Soy uno de los primeros héroes AWS serverless y actualmente trabajo como defensor del desarrollador en Lumigo, que considero la mejor herramienta para aplicaciones serverless. La otra mitad de mi tiempo trabajo como consultor independiente, donde trabajo con empresas de todo el mundo para ayudarles a tener éxito con serverless, así que he estado ejecutando cargas de trabajo en producción utilizando varias tecnologías desde 2016 y han surgido muchas cosas en el camino, las cuales he categorizado en varias lecciones que creo que serán muy útiles para todos los que estén pensando en utilizar

serverless en 2020, en 2022 más bien. La primera y, posiblemente, la lección más importante es que realmente debes pensar en cómo vas a resolver los problemas de tu sistema desde el principio porque será un problema mucho más difícil de solucionar después. Y la observabilidad es una medida de cuán bien se puede inferir el estado interno de un sistema a partir de su salida externa, y es absolutamente crucial porque sucederán cosas malas en tu sistema. Puede que aún no haya sucedido, pero eventualmente sucederá, porque todo falla todo el tiempo, como dijo famosamente Werner Vogel. Y cuando las cosas salen mal y los usuarios se ven afectados, necesitas poder solucionar los problemas lo más rápido posible. Y eso requiere que podamos identificar el problema, pero también resolverlo de manera oportuna. Pasé muchos años navegando entre los mensajes de registro y llegué a la conclusión de que los registros están sobrevalorados. Son útiles, pero no son el medio más efectivo para resolver problemas cuando estás bajo presión de tiempo. Y creo que en el mejor de los casos, a veces se siente como encontrar una aguja en un pajar cuando estás navegando por enormes cantidades de mensajes de registro. Así que hoy en día he adoptado un enfoque diferente en el que uso una combinación de Lumigo y no escribo muchos registros, pero cuando lo hago, me aseguro de que mis registros estén estructurados y cubran los puntos ciegos que no veo en Lumigo. Y luego también uso CloudWatch para las métricas del sistema y las alertas para complementar las alertas que recibo de Lumigo. Y la mayoría de mis resolución de problemas se realiza dentro de Lumigo, donde recibo notificaciones a través de una alerta de Slack o voy a la página de problemas, donde puedo ver todos los errores recientes y ellos

Se ha capturado y categorizado por función y tipo de error. Puedo ver con qué frecuencia han ocurrido estos errores y cómo han cambiado las tendencias a lo largo del tiempo, si ocurren de manera consistente o si es solo un pequeño problema. A partir de ahí, puedo ver un error específico y encontrar todas las invocaciones fallidas de Lambda que resultaron en ese error específico, y luego unir cada invocación de Lambda, o más bien transacción, porque puede que no sea solo una función de Lambda. Puedo ver el mensaje de error, que en este caso, faltaba algún valor de atributo cuando intentamos comunicarnos con DynamoDB, y puedo ver el evento de invocación de Lambda, que es algo que mucha gente registraría al comienzo de su función. Con Lumigo, no necesito hacer eso yo mismo. Aquí puedo ver que se ha resaltado el problema y que el problema fue causado por una llamada de nuestras funciones de Lambda a la tabla de DynamoDB. Puedo hacer clic en el ícono de Lambda, el ícono de DynamoDB para averiguar qué carga de solicitud enviamos. A partir de eso, puedo ver que era una operación de actualización. Y efectivamente, podemos ver que teníamos el mensaje de estado en la expresión de actualización, pero no se incluyó en los valores de atributo de expresión. De ahí el mensaje de error que obtuvimos en primer lugar. Porque falta ese valor de atributo en el objeto de valores de atributo de expresión, es por eso que estamos obteniendo un error. Y en aproximadamente 30 segundos después de recibir una alerta en Slack, pude identificar la causa raíz y comenzar a trabajar en una solución, que espero que sea simplemente una verificación en mi código. Y como Lumigo captura mucha información sobre las invocaciones de Lambda, incluidas todas las solicitudes que realizo a otros servicios o API de terceros, tengo muchos puntos de control en el camino que me permiten inferir el estado interno de mi aplicación, por eso no tengo que escribir muchos registros yo mismo en estos días. Pero si tengo alguna lógica empresarial compleja que no involucre llamar a otra API o servicio de AWS, todavía tendré que escribir mensajes de registro personalizados para dejarme algunas pistas sobre lo que realmente está sucediendo en mi función, lo que estoy haciendo, tal vez alguna transformación de datos compleja o enriqueciendo algunos de los datos que estamos obteniendo para poder dejar algunas pistas para luego mirar los registros y descubrir qué está sucediendo cuando algo sucede. Afortunadamente, Lumigo muestra tus registros junto con las trazas de lo que tu función ha llamado en términos de otras API o servicios de AWS, por lo que puedo encontrar fácilmente la información que necesito en un solo lugar. Y esto es realmente útil cuando se trata de depurar algunas de las transacciones más complejas y sutiles que abarcan múltiples funciones de Lambda y buses de eventos y DynamoDB o flujos y colas de Kinesis y demás. Por lo tanto, puedes ver múltiples funciones de Lambda en una transacción, obtienes todos los registros relevantes de esas invocaciones de Lambda en un solo lugar junto con tus transacciones. Y para agregar un poco de sabor a todo esto, tengo alertas en muchas de las métricas del sistema. Por ejemplo, si estoy usando DynamoDB, tendré alertas sobre el tiempo de respuesta de DynamoDB y los errores del usuario, y así sucesivamente. Y para cosas como procesar eventos en tiempo real de, digamos, un flujo de Kinesis, entonces tendré métricas y alertas sobre la antigüedad de los mensajes para saber dónde mis funciones se están quedando atrás y no están procesando eventos lo suficientemente rápido. Y esto complementa las alertas incorporadas que recibo de Lumigo, que me avisa cuando algo está mal en mis funciones de Lambda. Pero, por supuesto, no cubre las métricas, el rendimiento de los servicios de AWS, por eso también tengo alertas de CloudWatch para ellos. Y cuando sucede algo, recibo una notificación como esta en mi Slack porque he configurado Lumigo para alertarme a través de Slack. Y al hacer clic en este enlace aquí, también me llevará a la transacción fallida dentro de Lumigo, por lo que nuevamente puedo

Puedo identificar rápidamente la causa raíz del problema que estamos viendo. Y pasando a la segunda lección más importante, realmente deberías usar múltiples cuentas de AWS. Idealmente, tendrás al menos una cuenta de AWS por equipo, por entorno, porque hay muchos límites de servicio a los que puedes enfrentarte si agrupas todo, todos los entornos, en una sola cuenta. Y tienes límites en la cantidad de recursos que puedes tener, como el número de tablas de DynamoDB o el número de fragmentos de Kinesis en la región. Y una vez incluso me encontré con el límite en el número de roles de IAM que puedes tener en una región, que era de 3,000. Pero cuando tienes una empresa con 150 ingenieros ocupados construyendo cosas y creando nuevos servicios y roles de IAM de funciones de Lambda, es probable que alcances esos límites en algún momento, probablemente mucho más rápido de lo que piensas. Y luego están los límites de rendimiento más graves que afectan la escalabilidad de tu aplicación, como el número de solicitudes por segundo de API Gateway o el límite regional de ejecuciones concurrentes de Lambda, que se aplican a todas tus funciones. Por lo tanto, cuanto más cosas tengas en la misma cuenta y en la misma región, es más probable que te veas afectado por uno de estos límites de rendimiento. Por lo tanto, tener múltiples cuentas es una excelente manera de poner algunas barreras alrededor de tus procesos y también ayudarte a compartimentar cualquier violación de seguridad. Si llegara a ocurrir, y supongamos que alguien logró acceder a tu cuenta de AWS, con suerte sería solo tu cuenta de desarrollo para que no tengan acceso a tus datos de usuario de producción, lo que sería una violación más grave. Y tener una cuenta por equipo por entorno también te permite aislar cada entorno entre sí y también aislar cada equipo de otros equipos para que no haya situaciones en las que un equipo esté utilizando demasiados recursos para su servicio y cause que los servicios de otros equipos se vean limitados. Por ejemplo, si realizaras una prueba de carga en tu entorno de preparación y de repente utilizaras demasiados recursos y comenzaras a afectar tu rendimiento y escalabilidad en producción. A partir de aquí, si un equipo es propietario de varios servicios, es posible que también desees aislar los servicios más críticos para el negocio o de alto rendimiento y colocarlos en sus propias cuentas. De esta manera, nuevamente aislas otros servicios propiedad de ese equipo de este servicio en particular, que puede requerir un rendimiento mucho mayor que otros servicios para que no se afecten mutuamente. Y para ayudarte a administrar y aprovisionar todas estas cuentas de AWS, existe AWS Control Tower. Pero encuentro que AWS Control Tower implica demasiados clics en la consola para mi gusto, prefiero mucho más el enfoque de infraestructura como código en todas partes. Afortunadamente, existe esta herramienta llamada Org Formation, que me permite aprovisionar y administrar toda mi organización de AWS con infraestructura como código utilizando una sintaxis muy similar a CloudFormation. Y me facilita también la creación de plantillas para mi zona de aterrizaje, que es básicamente una configuración de qué piezas básicas de infraestructura se deben aprovisionar en una nueva cuenta y una nueva región. Cosas como claves de cifrado de KMS, VPC y las subredes, y así sucesivamente. Utilizando Org Formation, puedo declarar una cuenta maestra de AWS como la raíz de mi organización, nuevamente, utilizando código y una sintaxis muy similar a CloudFormation. Y puedo aprovisionar una nueva cuenta y configurar alarmas y presupuestos con solo un par de líneas de código. Y puedo adjuntar estas cuentas a mis unidades de organización, que también puedo crear mediante código. Y puedo configurar políticas de control de servicio. Por ejemplo, aquí, sé que para este proyecto, la única región que vamos a utilizar es EUS1. Por lo tanto, puedo configurar una política de control de servicio que niegue todas las acciones en las regiones que no sean EUS1 y aplicar esta política a la raíz de mi organización para que se aplique a todas las cuentas. Por lo tanto, no tengo que preocuparme por, por ejemplo, alguien que haya comprometido mi cuenta y luego intente iniciar instancias de EC2 para minar bitcoins en una región que normalmente no uso. Así que no les presto atención hasta que sea demasiado tarde. También puedo configurar mi política de contraseñas para cualquier usuario de AWS que tenga en mis cuentas y utilizar esta política de contraseñas en todas mis cuentas de AWS. Y cada vez que realice cambios, también puedo ejecutar un solo comando para actualizar toda mi organización de AWS y para configurar mis zonas de aterrizaje, puedo configurar lo que se llama una tarea donde especifico una plantilla de CloudFormation. Puedo proporcionar enlaces para cada recurso en mi organización, lo que básicamente dice, ahora crea este recurso a partir de la plantilla en cuentas de AWS específicas y tal vez incluso regiones específicas al vincular este recurso a una unidad de organización o una cuenta de AWS específica.

Y lo genial y poderoso de OrgFormation es que luego puedo hacer referencia a este recurso desde otros recursos en mi plantilla como si fueran parte de la misma pila de CloudFormation, aunque los recursos se pueden crear en diferentes cuentas, pero aún puedo hacer referencia a ellos utilizando una sintaxis similar a la que estoy familiarizado con CloudFormation, como usar ref y getAttribute.

Entonces aquí estoy vinculando este recurso a un subconjunto de mis cuentas de AWS en mi organización utilizando este concepto de enlace de organización. Y luego puedo, más abajo aquí, iterar a través de todas las cuentas de AWS que son proporcionadas por el enlace utilizando esta sintaxis especial que nuevamente se parece a CloudFormation, lo que me permite iterar a través de las cuentas que son identificadas por el enlace, y luego acumular y crear una matriz de AINs para asociar con esta política de assumeRole. Así que no te preocupes por los detalles y cómo se ve, puede parecer un poco extraño al principio. Pero una vez que dediques tiempo a la automatización, comenzará a tener mucho más sentido. Y luego, para actualizar mi zona de aterrizaje, solo tengo que ejecutar otro comando y eso actualizará todas mis cuentas. Así que es una herramienta realmente poderosa y te recomiendo que la revises. Está disponible en GitHub y es mantenida por MoneyU.

MoneyU, que es el banco aquí en los Países Bajos. Y en cuanto a la seguridad, también hay dos temas realmente importantes de los que hablar. El primero de ellos es cómo cargar de forma segura los secretos en tiempo de ejecución. En este punto, creo que la mayoría de las personas saben que deben colocar el secreto en el almacén principal de SSM o en el administrador de secretos y cifrarlos en reposo con KMS. Pero luego, durante la implementación, a menudo descargan esos secretos, los descifran y luego adjuntan los secretos descifrados como variables de entorno para las funciones de Lambda, o para los contenedores en ese caso, que los atacantes podrán escanear una vez que obtengan acceso a su sistema. Porque nuevamente, esto es algo fácil de encontrar desde el punto de vista de un atacante, simplemente mirar lo que tienes en tus variables de entorno y luego extraerlos.

Y hemos visto muchos ataques contra el ecosistema de NPM a lo largo de los años, y en algunos casos, tienes un compromiso o paquetes maliciosos de NPM que pueden ser utilizados por atacantes para robar información de tus variables de entorno. Es por eso que como regla general, nunca debes poner secretos en texto plano en variables de entorno. En su lugar, debes obtener esos parámetros de SSM o, y descifrarlos en tiempo de ejecución durante el inicio en frío. Y luego quieres almacenarlos en caché en la función de lambda y validar la caché de vez en cuando, para que puedas rotar esos secretos en segundo plano sin tener que volver a implementar tu aplicación. Y la forma en que suelo hacer esto es usando MIDI, que es un motor de middleware para funciones de Node.js. Y tiene algunos middlewares incorporados tanto para SSM como para el administrador de secretos que te permiten obtener secretos de esas tiendas y luego almacenarlos en caché. Y también invalidar la caché cada cinco minutos, para que cada cinco minutos, tu función de lambda vaya a SSM o al administrador de secretos y obtenga la copia actualizada del valor actual de esos secretos. Pero una consideración importante con respecto al uso de SSM es que hay un límite de rendimiento de 40 operaciones por segundo de forma predeterminada. Por lo tanto, si deseas ir a producción con esto, debes considerar cambiar tu región a un rendimiento más alto para aumentar ese límite a mil operaciones por segundo. Eso también convierte a SSM en un servicio de pago donde pagas, creo, 10 centavos por cada 10,000 solicitudes, mientras que la configuración predeterminada es gratuita, por eso tiene un límite de rendimiento tan bajo. Y luego también está el administrador de secretos, que tiene soporte incorporado para la rotación de secretos para RDS, así como para el servicio de Amazon DocumentDB, pero puede ser bastante caro en comparación, porque pagas 40 centavos por secreto por mes. Por lo tanto, se acumula cuando tienes muchos secretos multiplicados por la cantidad de entornos y cuentas diferentes que tienes. Por lo general, solo uso el almacén de parámetros de SSM para mis secretos, excepto en los casos en que es específicamente para RDS o para una base de datos de DocumentDB, en cuyo caso, la rotación incorporada del administrador de secretos resulta muy útil. La otra consideración de seguridad importante es que debes seguir el principio de privilegio mínimo y dar a tus funciones de lambda el mínimo de permisos necesario. Por ejemplo, si tu función necesita guardar datos en una tabla de DynamoDB, solo dale el permiso para realizar esa acción solo en la tabla en la que necesitas guardar los datos. Y luego quieres dar a cada función su propio rol de IAM para que puedas adaptar los permisos a lo que esa función necesita. Y si sigues este principio de privilegio mínimo, te ayudará a minimizar el alcance de lo que los atacantes podrán acceder en caso de que de alguna manera logren comprometer tu función y obtener acceso a tu entorno de base de datos, tal vez a través de algún módulo de NPM comprometido que les permita robar credenciales de tus funciones de AWS Lambda o tus contenedores. Y en ese sentido, también debemos hablar sobre la red de confianza cero, que también es un tema importante y relacionado. Mientras que el enfoque tradicional de la seguridad de red es endurecer el perímetro de la red, pero luego todo lo que está dentro de ese perímetro tiene plena confianza y puede acceder a cualquier otro recurso dentro de ese perímetro. La red de confianza cero dice que no a eso, porque un nodo comprometido simplemente daría a los atacantes acceso a todo nuestro sistema. Por lo tanto, con la red de confianza cero, no vamos a confiar en nadie solo porque estén en el límite de la red correcta. En cambio, cada solicitud a nuestras API debe estar autenticada y autorizada. Entonces, para esas API internas que son utilizadas por nuestros otros servicios, quieres utilizar la autorización de IAM de AWS para protegerlas y asegurarte de que el llamante tenga los permisos de IAM adecuados para acceder a esas API. Aún puedes poner estas API detrás de VPC, pero esa capa adicional de seguridad de red debe considerarse una ventaja y no solo la única capa de defensa, la única línea de defensa que tienes. Y para finalizar, también hay algunas ganancias rápidas cuando estás trabajando

En cuanto a la optimización del rendimiento de Lambda, que debería ser ampliamente aplicable para la mayoría de las personas. Cuando se utiliza Node.js y aún se utiliza la versión 2 del AWS SDK, entonces es necesario configurar esta variable de entorno en todas sus funciones de Lambda para habilitar el mantenimiento de la conexión HTTP, lo que le ahorrará aproximadamente de 10 a 20 milisegundos en cada solicitud que realice desde su función de Lambda a otros servicios de AWS.

Si está utilizando Lambda con RDS, entonces debe utilizar los proxies de base de datos para gestionar el agrupamiento de conexiones. De lo contrario, es probable que se encuentre con problemas, ya que tiene demasiadas conexiones al clúster de RDS. En cuanto a los inicios de código, tener artefactos de implementación más pequeños también significa un tiempo de inicio más rápido. Pero desafortunadamente, agregar más memoria en realidad no ayuda a reducir el tiempo de inicio, porque durante el inicio, su función de Lambda ya ejecuta el código de inicialización a plena capacidad de la CPU. Esto es cierto para, hasta donde yo sé, todos los tiempos de ejecución de lenguajes excepto Java, porque en Java parte de la inicialización ocurre durante la primera invocación después de la inicialización. Por eso creo que cuando se trata de Java, los recursos adicionales de la CPU que se obtienen al tener la configuración de memoria más alta también pueden ayudar a reducir el tiempo de inicio. Pero ese no es el caso para ninguno de los otros tiempos de ejecución de lenguajes que he probado. Lo que te ayudará más en términos de reducir el tiempo de inicio es simplemente recortar tus dependencias, tener menos dependencias, eso significa un artefacto de implementación más pequeño, pero también menos tiempo para que el tiempo de ejecución inicialice tus funciones. Y una cosa que encontré realmente útil es empaquetar mis dependencias en una capa de Lambda para que no tenga que cargarlas cada vez cuando no hayan cambiado entre implementaciones. Y es una excelente manera de optimizar el tiempo de implementación, ayudándote a reducir tanto el tiempo de inicio como el tiempo de implementación. Sin embargo, las capas de Lambda no son un buen sustituto de los administradores de paquetes de propósito general como npm o Maven, y no deberías usarlas como la forma principal de compartir código entre proyectos, porque para empezar, hay muchos más pasos para hacer que funcione. Con algo como npm, publicar un nuevo paquete y almacenarlo es muy sencillo, y hay soporte para escanear tus dependencias en busca de vulnerabilidades conocidas, mientras que publicar una nueva versión de una capa de Lambda y luego incorporar esa nueva versión en un proyecto requiere mucho más trabajo, y no tienes versionado semántico ni otras herramientas que obtienes con npm también. Mi forma preferida de usar las capas de Lambda es usar este complemento con el marco del servidor, que empaqueta tus dependencias en una capa de Lambda durante la implementación, la carga en S3 y luego actualiza todas tus funciones para que hagan referencia a esta capa. Y lo genial de este complemento es que detecta cuando tus dependencias han cambiado. Por lo tanto, si no han cambiado en una implementación posterior, no es necesario publicar una nueva versión de la capa, y tu implementación es mucho más rápida como resultado.

Y el truco para reducir el tiempo de inicio es no hacer referencia al SDK completo de AWS. Entonces, si solo necesitas usar un cliente, esto también ayuda a reducir el tiempo que llevará al tiempo de ejecución de nodo inicializar el módulo de tu función, y por lo tanto, hace que tu tiempo de inicio sea más rápido. Y si estás utilizando Lambda para procesar el evento de forma asíncrona, como con SNS, S3 o EventBridge, entonces también necesitas configurar algún tipo de DLQ o DeltaQ para capturar cualquier evento de invocación fallida para que no se pierdan. Hoy en día, se deben utilizar los destinos de Lambda en lugar de los DeltaQ, porque los DeltaQ solo capturan una carga de invocación y no el error. Por lo tanto, debes volver a tus registros o lo que sea para averiguar por qué fallaste en primer lugar para poder decidir si el evento se puede reprocesar ahora o no. Pero con los destinos de Lambda, se captura tanto la carga de invocación como el contexto alrededor de la invocación y la respuesta, que en caso de un fallo, captura el error del último intento. Por lo tanto, no tienes que buscarlos tú mismo.

Y eso concluye mi presentación. Como mencioné antes, paso la mayor parte de mi tiempo como consultor independiente, y si queremos hablar y ver cómo Serverless puede ayudarte y cómo podríamos trabajar juntos, ve a theburninmonk.com para ver cómo podríamos trabajar juntos para ayudarte a tener éxito con Serverless. Y si quieres aprender algunos de los consejos y trucos que he aprendido a lo largo del tiempo, también estoy impartiendo una masterclass en marzo, y puedes obtener un 15% de descuento con el código yenprs15. Y con eso, muchas gracias a todos por su atención. Y si tienen alguna pregunta, no duden en hacérmela saber, y podemos discutirla ahora. ¡Oh, wow, el 27% de nuestra audiencia ha estado utilizando Terraform como su marco de implementación, y en segundo lugar, tenemos un 23% para Serverless, un 18% para CloudFormation, un 14% para CDK, otro 40% para algo más y un 5% para SA. ¿Qué opinas de esto, Jan-Rust?

¿Es esto lo que esperabas? En realidad, no. Encuentro bastante extraño ver este tipo de resultado. No coincide del todo con lo que veo en la práctica. Supongo que personalmente, creo que ver las actualizaciones del marco de trabajo Serverless coincide con lo que veo en la práctica, y CDK se está volviendo mucho más popular. Así que eso también tiene sentido.

Supongo que Terraform es interesante. Hay muchos equipos que se centran en la infraestructura y siguen utilizando Terraform. Sin duda, si la mayor parte de tu trabajo implica escribir infraestructura, aprovisionar VPC y cosas así, entonces Terraform sigue siendo una herramienta muy buena. Pero creo que cuando se trata de construir aplicaciones de servicio, Terraform es demasiado básico. No te proporciona mucha ayuda en términos de construir una API y cosas así. Terminas escribiendo un par de cientos de líneas de código solo para aprovisionar puntos finales de la puerta de enlace de la API cuando deberían ser dos líneas de código en el marco de trabajo del servidor, o SEM o algo más. Así que creo que ese es un resultado interesante. Terraform sigue siendo muy utilizado. Y supongo que también es interesante ver que SEM casi no es utilizado en la actualidad. Supongo que AWS realmente ha cambiado de rumbo en cuanto a lo que promocionan. Hace un par de años, todo era SEM, y luego llegó CDK. Y ahora eso es lo principal que AWS está impulsando. Así que tiene sentido que CDK esté ahí arriba, mientras que SEM se ha quedado atrás. Sí. También veo que la gente sigue respondiendo. Pero afortunadamente, las posiciones no han cambiado. De lo contrario, tendríamos que responder la pregunta de nuevo. Muy bien. Gracias, Jan. Vamos a pasar a las preguntas de la audiencia. No olvides que si tienes más preguntas, aún puedes hacerlas en No Talk Q&A. Y si tienes tiempo, se las preguntaré a Jan. La primera pregunta es de Argentile1990. ¿Qué opinas sobre la integración de SSM, KMS, etc., con la infraestructura como herramientas principales como CloudFormation y Terraform? ¿Cómo se podrían reducir las barreras de entrada para equipos más pequeños con software heredado? Supongo que si estás hablando específicamente de SSM y KMS, creo que son muy fáciles de aprovisionar, estás diciendo infraestructura como código. Supongo que lo único que supongo que es un poco molesto con SSM cuando se trata de usar CloudFormation o cualquier herramienta que se base en CloudFormation, es que no admite las cadenas seguras de forma nativa. Así que lo que siempre he aprendido en el pasado es usar un recurso personalizado para poder aprovisionar cadenas seguras en SSM.

Con Terraform, puedes utilizar los módulos de Terraform. No sé si hay algún módulo público disponible para eso, pero ciertamente con las mismas herramientas como SAM y Desire framework y CloudFormation y CDK, también puedes tener algunos recursos personalizados o módulos que se pueden utilizar para admitir cadenas seguras en SSM. Es una de las cosas extrañas que CloudFormation todavía no admite hoy en día. Parece ser algo obvio que deberían haber hecho, al menos hasta ahora.

En cuanto a reducir la barrera de entrada para equipos más pequeños con software heredado, supongo que no estoy muy seguro de a qué te refieres exactamente. ¿Estás hablando solo de SSM o KMS? ¿O estás hablando de adoptar serverless en general?

Supongo que la primera empresa que realmente hizo mucho trabajo con serverless fue Social Network. En realidad, migramos de ejecutar un montón de instancias de EC2 a serverless y reconstruimos toda nuestra arquitectura. Y seguimos este patrón extraño donde tomamos una parte de la aplicación y luego la escribimos, y luego pasamos a la siguiente parte de la aplicación. Escribimos eso porque la aplicación en sí tenía muchos problemas, tanto en términos de resiliencia como en términos de eficiencia básica de escalabilidad y costos. Así que como parte de la reestructuración y para mejorar la experiencia del usuario, también las reescribimos. Así que tenemos un equipo muy pequeño de seis personas, incluyéndome a mí. En el transcurso de seis meses, básicamente reescribimos todo. Y creo que redujimos aproximadamente el 95% de nuestra facturación de AWS, pero incluso más que eso, básicamente dejamos ir a nuestro equipo de ingenieros de DevOps que básicamente no estaban haciendo muchas cosas. Estaban allí porque tenían que cuidar algunas de las VPC y cosas así. Pero no había suficiente trabajo para ellos. Y una vez que trasladamos todo a Lambda, API Gateway y cosas así, simplemente no había suficiente trabajo de DevOps. Así que en términos de costos de personal, eso probablemente sea uno de los mayores ahorros que hemos logrado porque la empresa era pequeña, pero no podían contratar a personas a tiempo completo, así que contrataron a un grupo de contratistas con tarifas diarias muy altas. Y al final, pudimos hacer que el equipo de aplicaciones fuera autosuficiente porque realmente no necesitaban mucho soporte de DevOps. Bueno, estás siguiendo los principios de DevOps en términos de código de infraestructura y cosas así, pero no necesitas especialistas para cuidar de tu grupo de instancias de EC2 o contenedores. No necesitas personas para cuidar de tu seguridad de red y todas esas cosas porque, nuevamente, al utilizar servicios administrados, todas esas cosas vienen de serie en AWS. Sí, curioso. Nunca lo había pensado. Escucho mucho sobre la optimización de costos de AWS, pero los costos de personal que mencionaste también son una gran optimización. Sí. Entonces, AWS hizo un documento técnico hace un tiempo, creo que en 2018. Descubrieron que al menos para las grandes empresas, los ahorros en los costos de personal son casi mayores que los costos de infraestructura. Ahora estás hablando de cientos de millones para algunas de estas grandes empresas en términos de costos de personal. Y porque tienes que pensar que necesitas un equipo completo para cuidar de tu grupo de máquinas, o simplemente puedes hacer que tus desarrolladores distribuyan algunas de las responsabilidades de guardia, y la mayor parte de la infraestructura será gestionada y asegurada por AWS. Tenemos tiempo para una pregunta más. La pregunta es de Hail to the wood.

Actualmente usamos Honeycomb para la capacidad de servicio. ¿Qué dirías que nos conviene usar Lumigo? Sí, creo que Honeycomb es un gran producto. Realmente me gusta su producto. También los he usado en proyectos similares en el pasado. Creo que lo interesante de Lumigo es que si tienes una aplicación completamente serverless o tal vez un 90% de aplicación serverless y estás haciendo algo más interesante, más avanzado, cosas como, tengo una API aquí, pero luego mientras estoy escribiendo cosas en bases de datos y buses de eventos y muchos otros procesamientos de eventos que ocurren después. Entonces, obtener esa trazabilidad hasta el final, tengo que decir que para Honeycomb, al menos todavía hacen bastante instrumentación manual. Entonces, quieres capturar cada solicitud que envías a algunos servicios de AWS o API de terceros, para que puedas agregar el contexto que necesitas para poder encontrar la información que necesitas en los registros. Y a veces te olvidas, así que tienes que volver y actualizar tu código y todo eso. Con Lumigo, si toda tu aplicación se ejecuta en una Lambda y demás, entonces Lumigo te brinda toda esa visibilidad lista para usar para que realmente no tengas que preocuparte por hacer instrumentación manual en gran medida. Hoy en día, básicamente no tengo que escribir muchos registros en absoluto, porque la mayor parte de lo que necesito, ya lo puedo obtener de Lumigo. La única vez que tengo que escribir algunos registros personalizados es cuando tengo lógica de negocio que no implica llamar a algunas API, en cuyo caso no sé qué está sucediendo porque no veo cosas dentro de Lumigo que me muestren, oh, estás haciendo una llamada a esta API, aquí está el cuerpo de la solicitud y el cuerpo de la respuesta. Así que tengo que poner algunos registros personalizados. Entonces, mi experiencia con Honeycomb y nuestra solución es que todavía necesitas hacer bastante instrumentación manual para darte las migas de pan que necesitas para encontrar tu camino una vez que tu aplicación se está ejecutando en la naturaleza, mientras que Lumigo viene listo para usar. Yo diría que Honeycomb es una gran plataforma de observabilidad para muchas cosas, mientras que Lumigo es una solución mucho más especializada y enfocada para personas que están haciendo aplicaciones más complejas e interesantes utilizando tecnologías serverless. Muy bien. Muchas gracias, Jan. Si tienes más preguntas para Jan, entonces nuestro tiempo ha terminado. Pero Jan estará en su sala de conferencias en SpatialJet. Así que puedes hacer clic en el enlace en la línea de tiempo a continuación, y Jan aparecerá allí en un minuto. Jan, muchas gracias por unirte a nosotros, ha sido un placer tenerte. Espero verte de nuevo pronto. Gracias por tenerme. Saludos chicos. Adiós adiós.