Reducción de costes y rendimiento consistente con AWS Lambda en San Saru

Por Jonatan Nieto Agis, CTO, sansarushop.com y Emanuele Cuoccio, Solutions Architect, Amazon Web Services

San Saru es un e-commerce de joyas de plata de ley 925 nacido en Barcelona en el año 2015. Su core de negocio se basa en la creación a mano de joyas con alma, de estilo boho-étnico y su filosofía es la de brindar un servicio personalizado y muy cercano a todos sus clientes.

Desde un punto de vista tecnológico, la empresa nació con una infraestructura cloud-native, eligiendo desde el principio Amazon Web Services como proveedor cloud para alojar sus cargas de trabajo. Desde sus primeros despliegues, la infraestructura sigue en continuo crecimiento, tanto en términos de gestión de volumen de datos y código fuente, como de rendimiento. Todos los procesos logísticos relativos bien a la fabricación, a la compra, al control de stock, y la venta de productos, como a la preparación de pedidos de San Saru, se gestionan internamente en la compañía y corresponden a cargas de trabajo hospedadas enteramente en la nube.

En este blog post, Jonatan Nieto, CTO de San Saru, nos cuenta con sus palabras como han logrado obtener mejoras en rendimiento, eficiencia operacional y optimización en coste de infraestructura, a lo largo de la evolución de su aplicación de logística, desde el nacimiento de la compañía hasta el día de hoy.

La evolución y sus desafíos

Cuando San Saru creó su aplicación customizada de ERP/back-office para la gestión de los distintos procesos logísticos involucrados en la fase de compra de sus productos, su primera opción fue la de desarrollar un software monolítico, basado en Java, desplegado y administrado por AWS Elastic Beanstalk. El servicio, pensado para reducir el esfuerzo en fase de despliegue y de administración de infraestructura, proporcionó al equipo de TI de San Saru una experiencia gestionada de hosting en servidores Amazon Elastic Compute Cloud (EC2), reduciendo al mínimo el time-to-market de su aplicación.

El crecimiento gradual y constante de la demanda que la compañía tuvo en los años siguientes a su fundación, determinó un aumento exponencial del volumen de ventas de productos y, por consecuencia, también de la cantidad de datos relativos a clientes y pedidos. A este incremento de la complejidad de gestión de los datos de venta, se añadió también la necesidad de ejecutar una serie de operaciones de renderización de imágenes por medio de los servidores de aplicaciones: esto se tradujo en la exigencia de escalar la infraestructura con más recursos de memoria y de cómputo y en la manera más ágil posible.

Como primer paso, el equipo de TI decidió escalar verticalmente la infraestructura, aplicando cambios en la misma configuración del entorno de Elastic Beanstalk e incrementando del 100% el número de vCPUs y la cantidad en GB de RAM por cada servidor empleado.

Aunque en un primer momento la saturación de capacidad se pudo solucionar con el escalado vertical de las instancias en Elastic Beanstalk, para agilizar las operaciones de escalado no solo en momentos de pico de ciclos de CPU predecibles (p.e. durante Black Friday, o acciones en redes por parte de la marca), sino también en caso de picos impredecibles, se adoptó una estrategia de escalado horizontal, por medio de la cual se iban añadiendo nuevos servidores al entorno en lugar de modificar cada vez los recursos de los servidores existentes en la configuración del entorno. Esto fue posible empleando un patrón de arquitectura stateless para la capa de aplicaciones a través del uso de mecanismos de auto escalado y del balanceador de carga Application Load Balancer.

Sin embargo, por la naturaleza de la estructura monolítica del código fuente de la aplicación, también en momentos del día en los cuales no se registraba una alta demanda de CPU, la infraestructura en Elastic Beanstalk implicaba que los servidores EC2 se quedaran operativos 24/7 a causa de procesos que tenían que ejecutarse de manera continua en el tiempo, como por ejemplo la sincronización de pedidos en el ERP con la aplicación web de la tienda online, entre otros. Esta ineficiencia en la utilización de potencia de computación en la infraestructura (que se muestra en la Figura 1), dio lugar a un buen margen de optimización en coste.

Figura 1 – Gráfico de Utilización porcentual de CPU en función del tiempo
en el entorno de Elastic Beanstalk de San Saru

La solución

El equipo de TI vio en el problema de la ineficiencia del coste de los servidores en momentos de infrautilización, la oportunidad de plantear una estrategia de re-factoring del código fuente de la aplicación de back-office y, por lo tanto, de adoptar un patrón distinto de arquitectura del software.

En particular, no solo se decidió pasar desde un patrón de arquitectura monolítico a un patrón a microservicios, sino también se benefició de las múltiples ventajas de servicios de AWS completamente serverless: AWS Lambda, para la ejecución de las operaciones de computo, Amazon API Gateway para la gestión de las APIs, y Amazon DynamoDB como base de datos no-SQL para guardar el estado de las sesiones.

“Al romper el monolito en múltiples microservicios podemos implementar cambios y nuevas funcionalidades asignadas a un servicio sin que esto cause downtime y sin interferir con el ciclo de vida de desarrollo del código del resto de la aplicación.” – dice Jonatan. “Después de investigar varios servicios con la ayuda del equipo de Arquitectura de Soluciones de AWS, la decisión fue la de migrar nuestro código desde los servidores Amazon EC2 de Elastic Beanstalk a AWS Lambda, con la idea de mantener el mismo estándar de escalabilidad, pero solo pagar por el tiempo efectivo de uso de computación.”

Figura 2 – Mapa de microservicios basados en AWS Lambda de San Saru

Respecto del nivel de control sobre una infraestructura aparentemente tan compleja, Jon comenta:

“Con el uso de las tecnologías serverless de AWS hemos podido implementar un sistema de monitoreo basado en el uso conjunto de servicios como Amazon CloudWatch, AWS Simple Notification Service (SNS) y de soluciones como Lumigo, que nos permiten mantener trazabilidad de cada ejecución y alcanzar un nivel de control de coste muy granular por cada transacción. Esto nos da una visión muy concreta de lo que está realmente pasando tanto a nivel de infraestructura – y costes anexos – como a nivel de aplicación.”

Figura 3 – Dashboard de monitoreo de invocaciones, fallos y costes de AWS Lambda en Lumigo

Figura 4 – Dashboard de transacciones y mapa de arquitectura en Lumigo

Con la adopción creciente de tecnologías serverless en la aplicación de gestión de pedidos/procesos de San Saru se ha conseguido un ahorro en costes de infraestructura de hasta el 120% a lo largo de un mes y medio (Figura 5). “Es increíble, con un gasto de solo 4 dólares al mes hemos cubierto un volumen de hasta 1,3 millones de peticiones en AWS Lambda.” – comenta el CTO.

Figura 5 – Reducción de costes en San Saru

Conclusión

El cambio que hubo a nivel de infraestructura se reflejó también en la estructura organizativa del departamento de TI de San Saru: “Los involucrados en este cambio fueron dos desarrolladores en particular, y a posteriori se decidió incorporar a más personas al equipo a medida que fuéramos desgranando piezas del monolito y los microservicios aumentaran coherentemente con las funcionalidades de la misma aplicación.”

Los aprendizajes clave de este proceso todavía en acto, se resumen en las siguientes consideraciones de Jonatan: “Recomendamos el uso de lenguajes como Node.JS o Python para agilizar el arranque de funciones AWS Lambda, ya que, comparado con Java – lenguaje inicialmente elegido por nosotros para el desarrollo de la aplicación – están más optimizadas en el uso de recursos de memoria y se casan perfectamente con la tecnología serverless”. Y añade: “Si os proponéis un cambio y queréis migrar a AWS Lambda desde otro servicio de computación, nuestra recomendación para pasar a un sistema totalmente serverless es seguir siempre la famosa estrategia de divide et impera, especialmente si la estructura de código inicial es monolítica. Empezad por los sistemas menos críticos y seguid con los más críticos, hasta olvidaros del monolito. Recomiendo encarecidamente la lectura del whitepaper intitulado Implementing Microservices on AWS, para entender los distintos patrones de arquitectura y servicios de la plataforma a usar en casos de uso como el nuestro.»

Sobre los autores

	Jonatan Nieto Agis es CTO de San Saru, con más de 10 años de experiencia en el sector TI. Se define una persona inquieta y siempre con ganas de innovar en los proyectos, optimizando al máximo los costes y mejorando su rendimiento.
	Emanuele Cuoccio es Arquitecto de Soluciones de AWS. Apoya clientes de diferentes perfiles en la toma de decisiones a nivel de arquitectura TI, siguiendo las mejores prácticas recomendadas por AWS.
	Ivan Torralbo es Account Manager de AWS en Iberia. Se dedica a ayudar a los clientes a acelerar sus negocios y su proceso de transformación digital en la nube de AWS.