Escribiendo Aplicaciones Serverless Testeables Utilizando Arquitectura Hexagonal

¿Qué pasa con el desarrollo local y la depuración? Eso todavía es algo realmente difícil de hacer pero las herramientas están mejorando cada día así que ya no es tan aterrador. Pero hay una cosa que todos mencionan, es perder el control. Sí, tal vez, pero por otro lado, al perder el control, estás ganando velocidad y algunas otras cosas. Así que no creo que eso sea lo más aterrador. Pero nuevamente, hay una cosa de la que todos tienen miedo y no importa si hablas con un desarrollador o una persona de negocios, todos mencionarán el temido bloqueo del proveedor. Es realmente aterrador, ¿verdad?

Pero veamos qué es el bloqueo del proveedor. Si vas a Wikipedia, verás que en economía, el bloqueo del proveedor hace que un cliente dependa de un proveedor para productos o servicios sin poder usar otro proveedor sin costos de cambio sustanciales. No me gusta mucho la definición así que intentemos explicarlo con algunos diagramas. Así que digamos que necesitas un servidor. No sé por qué, pero simplemente quieres tener un servidor y construir algún tipo de aplicación. Puedes comprarlo o alquilarlo, pero nadie compra servidores en estos días. Así que decides alquilarlo. Encuentras a un tipo que tiene muchos servidores en su sótano, llamémosle Jeff, y alquilas un servidor de Jeff y eso ahora es tu cloud. Estás usando ese servidor y después de un tiempo, Jeff es muy inteligente y sabe cómo usar sus servidores y sabe que estás construyendo bases de datos, almacenamiento en caché y cosas así. Así que comienza a construir servicios para ti. Puedes usar solo una database sin el servidor o simplemente usar caché o tal vez machine learning o funciones. Y es aún mejor porque puedes pagar por estas cosas solo cuando las usas. Es realmente increíble y ahora amarás los servicios de tu cloud. Pero ¿qué pasa si Jeff en realidad es un villano y en algún momento dependes tanto de sus servicios y aumenta los costos de todos estos servicios. Y por supuesto, tu billetera no estaría feliz en ese momento y seguramente tú tampoco estarías feliz. Pero afortunadamente tienes algunas opciones. Por ejemplo, puedes encontrar a otro tipo que tiene muchos servidores en su sótano o lo que sea, llamémosle Bill Y Bill también tiene una database y computación y machine learning y todo lo demás. Y los costos son más o menos los mismos que los costos de los servicios de Jeff antes de que aumentara los precios. Pero lo que es costoso es la migración porque la database de Jeff no es exactamente la misma que la database de Bill. Así que necesitas invertir mucho tiempo para mover tu aplicación de un servicio a otro. Y eso es básicamente el bloqueo del proveedor en la nube. Vimos otro ejemplo recientemente con Parler, pero eso es probablemente diferente porque no pueden migrar a ningún proveedor importante.

Este es un caso extremo, pero esta presentación no lo cubrirá. En cuanto al bloqueo del proveedor, realmente creo que Mark Schwartz, estratega de enterprise en AWS, tiene razón. Él piensa que el término bloqueo es engañoso porque en realidad estamos hablando de costos de cambio. Tan pronto como nos comprometemos con una plataforma o proveedor, tendremos costos de cambio si luego decidimos cambiar ese proveedor o plataforma. Por ejemplo, si construyes tu aplicación en PHP, y luego en algún momento quieres migrar eso a Node.js o Go o algo más, tendrás un gran costo de cambio porque necesitas hacer una pausa por un tiempo, reconstruir todo en un lenguaje diferente, y luego continuar desde ese punto.

Entonces, ¿cómo combatimos el bloqueo del proveedor, o mejor aún, hagamos la mejor pregunta, ¿cómo mantenemos nuestros costos de cambio razonables? Bueno, podemos hacer algunas cosas. Primero, necesitamos planificación y análisis. Por ejemplo, necesitamos responder algunas preguntas como ¿qué tan probable es que necesite cambiar a otra plataforma o servicio? ¿Cuál sería el costo de ese cambio? Si no hay muchas posibilidades de cambiar a otra cosa, por ejemplo, elegiste tu database y no crees que necesitarás cambiar en el futuro cercano, está bien tener un costo de migración ligeramente más alto, pero para algunas otras cosas, necesitas mantener ese costo más bajo. Necesitas tener una buena arquitectura, por supuesto. Y finalmente, necesitas tener procedimientos de implementación porque si no los tienes, será realmente, realmente difícil migrar a cualquier lugar.

Eso nos lleva a nuestro tema de hoy, y eso es escribir aplicaciones serverless testables y prevenir el bloqueo del proveedor utilizando la arquitectura hexagonal. Pero antes de continuar, permítanme presentarme. Soy Slobodan Stanovich, CTO y socio de Cloud Horizon y VacationTracker, VacationTracker es un sistema de gestión de seguimiento de clientes y Cloud Horizon es básicamente una agencia que crea aplicaciones web para otras personas. También escribí el libro, Aplicaciones serverless con Node.js con mi amigo Alexander Simovich, y está publicado por muchas editoriales. Y también soy un héroe serverless de AWS. Puedes seguirme en mi sitio web. Escribo mucho sobre serverless y también sobre pruebas. Así que volvamos a nuestro tema porque eso es definitivamente más interesante que yo. Hablaremos sobre cómo escribir aplicaciones serverless testables utilizando la arquitectura hexagonal. Pero primero, centrémonos en la parte de las pruebas. ¿Por qué son importantes las pruebas para las aplicaciones serverless? Básicamente, externalizas algunas partes de tu aplicación a un proveedor, pero eso no cubre todo. Ellos administrarán la infraestructura por ti, pero aún eres dueño de tu código y tu lógica empresarial. Entonces, necesitas probar esa parte de la aplicación. Y la mayoría de las veces, las aplicaciones serverless no son monolitos completamente aislados sin integraciones. En cambio, contienen muchos servicios pequeños que interactúan entre sí todo el tiempo, y tienen muchas dependencias externas. Mencioné VacationTracker, así que aquí tienes un ejemplo. Nuestra aplicación es una WebApp que también tiene un chatbot de Slack. Y dentro de Slack, puedes escribir /vacation y solicitar vacaciones con solo unos pocos clics. Es muy fácil, puedes hacerlo en solo unos minutos, en realidad, unos pocos segundos. Pero en segundo plano, se ve algo como esto.

Slack envía algunas solicitudes a nuestra puerta de enlace de API de Amazon. La puerta de enlace de API recibe esa solicitud HTTP y decide qué función de Lambda ejecutar. Esa función de Lambda analizará esa solicitud, la enviará a algo llamado Amazon EventBridge, que se comunicará con nuestra lógica empresarial en segundo plano, es un bus de servicios empresariales. Y luego, inmediatamente, la función de Lambda de AWS devolverá la respuesta a través de la puerta de enlace de API de Amazon a Slack y le dirá a Slack que recibió el mensaje. En segundo plano, nuestra lógica empresarial capturará ese mensaje y hará algo con él, por ejemplo, solicitar un permiso para ti o hacer algo así.

Hay muchas cosas que pueden cambiar o fallar en cualquier momento, por ejemplo, Slack puede cambiar la carga útil. Ha sucedido algunas veces en los últimos años. O por ejemplo, Slack puede estar inactivo. Luego, la puerta de enlace de API de Amazon puede cambiar su carga útil o algo así. Luego, la función de Lambda de AWS, tal vez nuestra función de Lambda, no está enviando el mensaje correcto a Amazon EventBridge o no tenemos los derechos para enviar ese mensaje. Entonces eso puede fallar. Y finalmente, tal vez Amazon EventBridge no pueda activar nuestra lógica empresarial por alguna razón. Por lo tanto, hay muchos cambios que pueden ocurrir todo el tiempo y las pruebas no evitarán estos cambios con seguridad. Pero se asegurarán de que los cambios que estamos haciendo no sean accidentales.

Entonces, ¿cómo prevenimos los cambios? No podemos, nuestra aplicación necesita adaptarse muy rápido y comenzar a funcionar con una carga útil diferente o lo que sea. Entonces, ¿cómo sabemos qué parte de la aplicación qué debemos probar realmente en nuestra aplicación sin servidor? En las aplicaciones tradicionales, hay algo llamado pirámide de pruebas. Está definida por Michael Cohen, en su libro, Succeeding with Agile. Y se ve algo así. En la parte inferior de la pirámide, hay pruebas unitarias porque son rápidas y realmente económicas. No necesitas nada externo para estas pruebas. Entonces son baratas y rápidas por eso. Y necesitas escribir muchas pruebas unitarias. Luego, para las pruebas de integración, son un poco más caras y más lentas porque necesitan conectarse a algún tipo de base de datos u otros servicios. Entonces necesitas menos pruebas de integración, pero también son un poco más caras. Y finalmente, las pruebas de interfaz de usuario o de extremo a extremo son las más caras y las más lentas porque necesitas tener toda la aplicación y todo. Y por eso no quieres tener demasiadas de ellas. Finalmente, muchos equipos tienen alguna sesión manual de pruebas basada en sesiones. Esa es la más lenta porque las personas necesitan hacer eso y son las más caras. Con sin servidor, en realidad la pirámide de pruebas sin servidor se parecería más a una pirámide maya en lugar de una pirámide egipcia. Entonces, las pruebas unitarias son las mismas, pero las pruebas de integración y las pruebas de interfaz de usuario son un poco más rápidas y un poco más económicas porque es más barato iniciar otra instancia de tu aplicación y puedes hacer cosas en paralelo.

Por eso son un poco más rápidas. Las pruebas de integración en aplicaciones sin servidor son más económicas y rápidas que nunca. Pero también son más importantes porque la aplicación sin servidor común se divide en muchas piezas pequeñas.

Entonces mencionamos la arquitectura. ¿Qué arquitectura es la mejor para las aplicaciones sin servidor? Básicamente, no hay una arquitectura única. Puedes utilizar cualquier arquitectura que te permita probar fácilmente tu aplicación sin servidor y mantener bajos los costos de cambio. Porque tarde o temprano necesitarás cambiar o migrar partes de tu aplicación, no a otro proveedor de servicios en la nube, pero la mayoría de las veces utilizarás otro servicio o cambiarás alguna integración y cosas así.

Hay algunas cosas que debes tener en cuenta al construir una aplicación sin servidor y elegir una arquitectura. Tienes riesgos de configuración. Si tu función está configurada como debería, riesgo de flujo de trabajo técnico, si manejas los errores y las respuestas de éxito como deberías, riesgos de lógica empresarial, si tu lógica empresarial funciona como debería, y finalmente riesgos de integración. Por ejemplo, si estás conectado a la base de datos correcta y si tienes los permisos para esa base de datos y cosas así. Una de las arquitecturas que se adapta muy bien a estas necesidades es la arquitectura hexagonal o puertos y adaptadores.

Hablemos de eso por un segundo. Su creador Alistair Coburn lo explica como una arquitectura que permite que una aplicación sea impulsada tanto por programas de usuarios, pruebas automatizadas o scripts por lotes, como para ser desarrollada y probada de forma aislada de su entorno de ejecución y bases de datos finales, lo cual es realmente bueno para las aplicaciones sin servidor porque, como dijimos al principio, la depuración y el desarrollo local a veces pueden ser un poco más complejos que antes. Se llama puertos y adaptadores porque funciona de la misma manera que los puertos y adaptadores. Por ejemplo, si viajas a otros países, necesitas un enchufe de corriente diferente para tu computadora portátil y no quieres comprar otro cable de carga. En su lugar, puedes comprar un adaptador pequeño y simplemente usar tu cable de carga regular. Queremos hacer lo mismo para nuestras aplicaciones y lo hacemos aislando la lógica empresarial en el centro. Y luego tenemos ciertos puertos para nuestros eventos, básicamente para eventos. Y luego tenemos adaptadores para diferentes servicios. Por ejemplo, cuando estamos probando nuestro servicio localmente, podemos usar un adaptador de activación local y con la aplicación sin servidor, podemos usar algún tipo de adaptador de evento Lambda o algo así. Así que veamos esto en un ejemplo. Volvamos a este ejemplo y centrémonos en una función Lambda. Si queremos construir nuestra aplicación de manera que sea fácilmente probable, podemos hacer algo como esto. Podemos tener un archivo Lambda JS. No hacemos pruebas para ese archivo, pero tiene solo unas pocas líneas de código. Luego tenemos nuestro archivo principal JS o varios archivos que representan nuestra lógica empresarial. Esta lógica empresarial tiene sus propias pruebas unitarias y también su propia prueba de integración. Pero, por ejemplo, tenemos muchas funciones conectadas a EventBridge.

No queremos probar cada función contra EventBridge. Tenemos un repositorio para eso y las pruebas de integración probarán esto contra algún tipo de repositorio local con la misma API y básicamente la misma interfaz que el repositorio real de EventBridge. Y luego tenemos el repositorio de EventBridge con sus propias pruebas unitarias y pruebas de integración. Y aquí queremos probar eso contra el servicio real de Amazon EventBridge para asegurarnos de que funcione. Y podemos tener algunos archivos de ayuda, por ejemplo, un analizador de eventos que básicamente se ejecutará solo en pruebas unitarias porque no está conectado a nada fuera de nuestra función.

Veamos el código para esto. Esto puede representar nuestro archivo Lambda.js. Requerimos algunas cosas de nuestra lógica empresarial y algunas cosas de nuestra carpeta común o lo que sea. Y luego, dentro de la función, queremos crear una instancia de nuestro repositorio de EventBridge. Y finalmente, la parte más importante de este código es esta línea, invocamos nuestra lógica empresarial, pasamos el evento que recibimos, pasamos el analizador que podrá analizar este evento. Ese es nuestro adaptador, por ejemplo, el disparador Lambda. Y finalmente, pasamos la instancia de nuestro repositorio de notificaciones.

Con las pruebas unitarias, podemos probar fácilmente esto pasando algunos valores estáticos para el evento, podemos simular el analizador y el repositorio de notificaciones. Para las pruebas de integración, podemos pasar nuevamente algunos valores estáticos para el evento y luego podemos pasar alguna función de análisis y bloquear un adaptador de notificaciones. Y, por supuesto, como dijimos, el verdadero adaptador de notificaciones tendrá su propia prueba de integración, por lo que realmente no nos importa si esta función puede comunicarse con EventBridge. En cambio, solo queremos verificar si esta función puede comunicarse con el adaptador de notificaciones.

Es simple y agradable, pero al principio mencionamos el temido bloqueo del proveedor. Estoy bastante seguro de que todavía lo recuerdas. Bueno, ¿cómo nos ayuda esta arquitectura hexagonal a combatir el bloqueo del proveedor o, como dijimos, a mantener nuestros costos de cambio razonables? Veamos otra historia. Nuevamente, un rastreador de vacaciones. Así que construimos el prototipo sin servidor al principio. Teníamos un equipo pequeño con un desarrollador a tiempo completo. El producto inicial era un chatbot sin servidor más express.js y MongoDB, y estaba creciendo rápidamente después de unos meses. Teníamos más de 200 equipos usándolo. Ahora tenemos muchos más que eso. Y, por supuesto, tuvimos muchas malas decisiones como bonificación que tomamos durante ese proceso. Hicimos muchas migraciones en los últimos meses y años. Por ejemplo, reemplazamos la API de Express con una API sin servidor. Reemplazamos MongoDB con DynamoDB y reemplazamos el API Gateway ahora con AppSync y GraphQL. Centrémonos en MongoDB a DynamoDB.

Es realmente, realmente difícil cambiar la database, pero con la arquitectura hexagonal, básicamente puedes comenzar con la misma interfaz como dijimos. Entonces, por ejemplo, nuestro MongoDB, cada vez que quieras obtener el usuario, puedes invocar db.getUser y devolverá el objeto de usuario. Lo que hicimos con DynamoDB, creamos la misma interfaz. Entonces, básicamente tiene la misma función getUser. Cuando pasas el ID de ese usuario, tendrás el mismo objeto de retorno. Así que el usuario uno será igual al usuario dos. Entonces hicimos lo siguiente. Todavía tenemos nuestra función y está conectada al repositorio de MongoDB en algún punto. También conectamos esa función al repositorio de DynamoDB y simplemente cambiamos ese adaptador en la aplicación. Eso fue solo una pequeña parte, por supuesto, que es utilizada por nuestro código. Pero esto es, por supuesto, necesitábamos migrar los data y todo. Pero es realmente importante hacer esto porque de esta manera, nuestra lógica empresarial permanece igual. No importa realmente para nuestra lógica empresarial si los data están dentro de DynamoDB o MongoDB y cómo funcionan en el fondo.

Y si volvemos a estas pruebas de integración, podemos hacer algo así de simple. Antes de todo, podemos crear una base de datos de prueba con serverless y al final, podemos destruirla. El código es realmente sencillo. Se ve algo así. Creamos la tabla, esperamos a que se cree la tabla. Esto puede tomar de 15 a 20 segundos, y luego al final, simplemente podemos destruir esa tabla y esperar unos dos o tres segundos para que se destruya esa tabla. Y solo pagas por esta tabla cuando estás ejecutando pruebas y después de eso, tu cuenta está clara. Y sí, te conviertes en un superhéroe de las pruebas.

Básicamente, hagamos un breve resumen para finalizar esta presentación. Una buena arquitectura te ayuda a mantener bajos los costos de cambio, o al menos razonables si no puedes evitarlos en algunas situaciones. La arquitectura hexagonal es buena para las aplicaciones serverless porque te ayuda a probar estas aplicaciones de forma aislada. Y realmente debes probar las integraciones con las aplicaciones serverless. Y por supuesto, debes probar otras partes de tu aplicación, pero las integraciones son más importantes que nunca. Y a veces las pruebas no son suficientes, así que necesitarás agregar un poco de monitoreo y seguimiento de errores para asegurarte de que todo funcione todo el tiempo.

Y eso es todo por hoy. Como dije, hablo y escribo mucho sobre serverless. Puedes visitar mi sitio web y ver el contenido. Y también estoy haciendo un taller de pruebas de aplicaciones serverless pronto. Así que si estás interesado en eso, podrás ir a mi sitio web y obtener más información. Muchas gracias. Eso es todo por hoy. Hola, bienvenidos. Es genial tenerte aquí. Gracias por la increíble charla. Gracias. Vi que el 29% de las personas utilizan serverless, así que estoy realmente feliz con ese número porque serverless todavía es nuevo. Así que tomará algunos años más hasta que tengamos un mayor porcentaje de personas utilizando serverless pero hasta ahora, casi una de cada tres personas que utilizan serverless es mejor de lo que esperaba. Así que sí, estoy contento con ese número. Supongo que depende un poco de tu mercado. Siempre siento que el mercado estadounidense está un poco adelante del mercado europeo.

Y así me sorprendió un poco que sea solo alrededor de un tercio, pero sí, supongo que depende. Es un buen número. Sí. Por supuesto, por supuesto. Pero recuerdo los días en que teníamos un porcentaje realmente pequeño de personas que utilizaban serverless como menos del 5% o algo así. Así que 29 es un número realmente bueno. Sí, cuando recién comenzó. Ha crecido mucho en los últimos años y la aceptación también ha crecido mucho. Así que esperemos que el número siga aumentando.

Tenemos algunas preguntas del público para ti. Aaron quiere saber dónde colocas Docker en la escala entre lo tradicional y serverless. Probablemente no sea la persona adecuada para responder preguntas sobre contenedores porque no estoy usando realmente contenedores tanto, pero sí, lo único para lo que uso Docker es para probar algunas de las funciones serverless. Veo otra pregunta relacionada con AWSM y esta es exactamente la parte donde uso Docker de vez en cuando. No estoy seguro de dónde encaja en esa pirámide serverless. Y sí, las pruebas, probablemente estén en algún punto intermedio, pero ahora hay algunos contenedores administrados que están muy cerca de serverless. Así que sí, realmente depende. No soy la mejor persona para responder preguntas sobre contenedores en este momento. De acuerdo. Entonces pasemos a la siguiente pregunta. Jamatask quiere saber, ¿utilizas AWS SAM y sus capacidades locales para probar varias aplicaciones localmente? ¿Esa era la pregunta a la que te referías, verdad? Sí, exactamente. Entonces, AWS SAM o modelo de aplicación serverless es una herramienta muy útil que te ayuda a implementar, pero también a ejecutar localmente algunas partes de tu aplicación serverless. Y lo usamos de vez en cuando para probar... No realmente para ejecutar una prueba automatizada, sino para ver si la función realmente funciona de la manera que queremos que funcione. Pero no lo uso todos los días. Así que cuando necesito probar algo localmente, es mucho más fácil para mí escribir algunas pruebas unitarias o algo así, o pruebas de integración que iniciar Docker, probablemente actualizar Docker porque no lo uso todos los días. Así que puede ser realmente útil, especialmente cuando estás comenzando con serverless. Pero para mí, no es una herramienta que use todos los días, pero usamos AWS SAM para la implementación y básicamente para nuestra infraestructura como código. De acuerdo, genial. DammaTask también pregunta, ¿intentaste migrar AWS AppiStack a Kubernetes más Istio o Google Cloud o Microsoft Azure? Oh, definitivamente no.

Por otro lado, no tenemos planeado hacer eso. Entonces, la siguiente pregunta de seguimiento es básicamente qué tan práctica es la arquitectura hexagonal. Así que si queremos hacer alguna migración importante, necesitaríamos escribir mucho código, eso seguro. Pero lo bueno de la arquitectura serverless es que la lógica empresarial de tus funciones sigue siendo la misma. Así que sé que la lógica empresarial de la función, por ejemplo, hablo de nuestro producto, Location Tracker, la forma en que solicitas una licencia o apruebas una licencia seguirá siendo la misma. Lo que cambiará son básicamente los conectores, cómo se almacenan esos datos en una base de datos y cosas así. Así que adaptadores y cosas así. Pero la lógica empresarial es independiente de la plataforma. Por eso, cuando mencionaste los puertos y los adaptadores al principio, esa es una muy buena explicación. Por ejemplo, si viajas en verano, por supuesto, no este año, pero esperemos que pronto en el futuro, no quieres comprar un nuevo adaptador. Por ejemplo, cuando vas a los Estados Unidos u otro país con enchufes de corriente diferentes, no quieres comprar todo el cable de alimentación para tu Mac o algo así y pagar mucho dinero. En su lugar, compras un adaptador pequeño solo para permitir que tu computadora, en realidad, use tu adaptador de corriente existente con una fuente de alimentación en tu hotel o algo así. Quieres hacer lo mismo con tu código. Exactamente, porque no solo terminarías comprando un adaptador de corriente para tu computadora portátil, sino que necesitarías uno para todos tus dispositivos electrónicos. Entonces, es mucho más barato obtener el adaptador agradable y compacto. Es lo mismo con el código. No quieres reescribir tu lógica empresarial porque debe ser independiente de la plataforma en la que estás ejecutando tu aplicación. Entonces, no, nunca intentamos migrar todo a Kubernetes, pero por otro lado, intentamos migrar nuestra lógica empresarial a GraphQL, y eso cambió muchas cosas. Pero muchas funciones siguieron siendo las mismas. Afortunadamente, logramos eliminar muchas funciones y reemplazarlas con otros servicios, pero la lógica empresarial siguió siendo la misma. De acuerdo, creo que tenemos tiempo para una última pregunta. Aaron quiere saber, he escuchado que MongoDB tiene un mal rendimiento en implementaciones serverless. ¿Es por eso que migraste a DynamoDB? No, no experimentamos ese mal rendimiento, al menos no en nuestra aplicación. Pero ¿cuál era el problema? El problema con MongoDB era que todavía éramos dueños de la infraestructura de esa MongoDB. Necesitábamos escalar esa base de datos. Y a veces teníamos mucho tráfico porque, por ejemplo, Slack nos enviaba muchos webhooks y la gente usaba nuestras aplicaciones. Así que en lugar de tener una base de datos no serverless, intentamos migrar a DynamoDB porque esa base de datos es completamente serverless, se escalará automáticamente. Tuvimos un error y en un mes, tuvimos alrededor de 250 millones de solicitudes de escritura a nuestra base de datos además de lo que normalmente tenemos. Y sí, simplemente funcionó. Nuestra factura fue de $300 más, pero sí, todo funcionó. De acuerdo, genial. Gracias por responder todas las preguntas. Hubo algunas preguntas más y para responder a esas, únete a Slobodan en la sala de oradores en spatial chat. Muchas gracias por acompañarnos esta noche. Gracias.