Todo lo que hay que tener en cuenta a la hora de trabajar con AWS Lambda: soluciones, compatibilidad y metodología.
Desde hace ya más de una década, el desarrollo de software basado en microservicios se ha consolidado como la arquitectura favorita para muchas empresas de tecnología. Gran parte de las facilidades que ofrece este enfoque vienen dadas por servicios como AWS Lambda, que permite desplegar funciones como microservicios sin tener que preocuparse por la infraestructura subyacente.
¿Pero es esta la forma más eficiente de desplegar y gestionar aplicaciones? ¿Qué pros y contras ofrece el servicio de AWS Lambda en el desarrollo backend de aplicaciones?
En Codemotion Madrid 2024 tuvimos la suerte de contar con la ponencia “19 micros y 500 lambdas”, donde Isabel Simón, Tech Lead & Backend Developer at Airbus, nos habló sobre lo que hay que tener en cuenta a la hora de elegir esta tecnología como solución y su compatibilidad con arquitecturas de software y metodologías de desarrollo modernas.
Contexto de la charla
Durante una época no muy lejana, el desarrollo de aplicaciones se realizaba principalmente a través de arquitecturas monolíticas, es decir, una única base de código para todos los componentes de la aplicación.
Sin embargo, con el auge de la nube y la necesidad de crear aplicaciones escalables y flexibles, esta estrategia comenzó a dar paso a arquitecturas basadas en microservicios, donde cada componente de la aplicación se desarrolla y despliega de forma independiente.
Junto a este enfoque, muchas empresas pasaron a emplear servicios como AWS Lambda, que permite desplegar funciones individuales como microservicios sin tener que preocuparse por la infraestructura subyacente. Este cambio facilitó una gran agilidad en el desarrollo y despliegue, pero también trajo consigo nuevos desafíos y consideraciones.
AWS es probablemente el servicio más conocido y utilizado para este propósito, pero no es el único. Otras opciones como Google Cloud Functions o Azure Functions también ofrecen soluciones similares. E incluso se puede optar por desplegar nuestras aplicaciones en un servidor privado, ya sea a través de una infraestructura propia o externa. Pero ¿Cómo tomar la decisión acertada para diseñar un aprovisionamiento óptimo según las necesidades de cada proyecto?
Pros y contras de AWS Lambda
Todos conocemos los pros de AWS Lambda. Se trata de un servicio con la capacidad de escalar automáticamente en respuesta al tráfico entrante, pagando solamente por el tiempo de ejecución y recursos empleados. La infraestructura subyacente la gestiona el equipo de Amazon, por lo que no tenemos que preocuparnos por su mantenimiento.
Ofrece un gran rendimiento, incluso en aplicaciones de alta carga gracias a su capacidad para aprovisionamiento simultáneo y duplicado. Además, se integra fácilmente con otros servicios de AWS y el desarrollo de aplicaciones basadas en microservicios, así como su despliegue, se torna más ágil y flexible.
Sin embargo, como cualquier otra tecnología existente, AWS Lambda también tiene sus contras. Por ejemplo, el arranque en frío, debido a la inicialización de la función cuando se invoca después de estar inactiva, puede provocar latencia indeseada, y aunque existen métodos para mitigar este efecto, puede no ser ideal para algunos tipos de aplicaciones.
El tiempo de ejecución, limitado a 15 minutos, también puede ser insuficiente para ciertas tareas que requieran procesamiento prolongado. Por otro lado, la depuración y la monitorización de funciones puede resultar más complejo en comparación con las aplicaciones tradicionales, debido a la naturaleza distribuida de los microservicios. Incluso los límites en el uso de memoria y almacenamiento temporal pueden ser demasiado restrictivos para algunos proyectos.
La charla: 19 micros y 500 lambdas
Con todo este contexto en mente, Isabel Simón nos habló, a partir de su experiencia, del uso de AWS Lambda en combinación con una arquitectura basada en microservicios. Bajo el título de “19 micros y 500 lambdas”, en honor a la conocida canción de Joaquín Sabina, Isabel nos explicó los puntos que hay que tener en cuenta a la hora de seleccionar esta tecnología.
Por otro lado, también nos contó cómo encajan las características de AWS Lambda con arquitecturas de software y metodologías de desarrollo modernas como la arquitectura hexagonal o el Diseño Orientado a Dominios.
Isabel explicó cómo las funciones individuales de AWS Lambda pueden modelarse como los puertos en una arquitectura hexagonal, permitiendo un alto grado de modularidad y flexibilidad, o cómo los principios del Diseño Orientado a Dominios pueden ayudar a estructurar y organizar las funciones de Lambda para maximizar su eficacia.
En un alarde de lógica aplastante, insistió que AWS Lambda no es LA solución, sino que se trata de otra herramienta como cualquier otra. No se trata de una elección por defecto, sino que hay que preguntarse si realmente aporta valor a nuestro proyecto, si estamos dispuestos a lidiar con las limitaciones que impone y si se adapta bien a nuestras necesidades y a la arquitectura de software que hemos elegido.
Además de una amena charla, la cual se celebró durante el primer día de la Codemotion Madrid 2024, Isabel también nos regaló un ratito para responder a preguntas y dudas del público, lo que permitió a los asistentes entender aún mejor cómo y cuándo implementar AWS Lambda en sus propios proyectos.
La ponente: Isabel Simón, Tech Lead & Backend Developer at Airbus
Ingeniera de software especializada en desarrollo backend con Python como lenguaje de programación madre. Centra su carrera en la construcción de aplicaciones basadas en las prácticas del código limpio y la seguridad. Actualmente, trabaja en Airbus como Tech Lead y desarrollador web backend en un equipo internacional con gente de Francia e India. Amante del Poké y las lentejas de la abuela.
