E-Commerce Exitosos en Black Friday con AWS – Parte 2

Por Adler Oliveira, Arquitecto de Soluciones AWS y Bruno Laurenti, Arquitecto de Soluciones AWS.

Bienvenidos a la segunda parte de este blog post dedicada a los e-commerce y a las fechas comerciales de alta demanda.

En la primeira parte nos enfocamos en estrategias de corto y mediano plazo, ahora es momento de seguir evolucionando.

El Largo Plazo

Finalmente hemos llegado al largo plazo, una etapa que pretende transformar la arquitectura del e-commerce en una solución moderna en todos los niveles, en donde los principales objetivos serán:

• Desacoplar y modularizar el front-end.
• Adoptar un modelo asincrónico de comunicación entre micro servicios.
• Reducir costos y simplificar la operación.
• Hacer un uso mas eficiente de las bases de datos.

Vale la pena mencionar que el conjunto de recomendaciones, servicios y tecnologías presentadas a continuación, aborda los principales desafíos encontrados en retailers globales y esta pensado para escalar hasta los cientos de miles de usuarios comprando simultáneamente.

Comencemos observando el diseño de arquitectura propuesto para esta etapa.

Como pueden ver los grandes cambios se encuentran en el front-end. Hablemos ahora sobre cada unos de los cambios.

Mejorar las Comunicaciones del Front-end Mediante Colas y Mensajería.

En las arquitecturas de los e-commerce suelen haber diferentes procesos que son asincrónicos por naturaleza, tales como procesamiento de ordenes, notificación a los sistemas de logísticas, gestión de los estados de compra, comunicación con sistemas de terceros y muchos otros. Esta naturaleza asincrónica no quiere decir que su back-end opera de esta manera pero sin dudas es un excelente candidato para re-arquitectar la comunicación y transformarla en asincrónica.
Para logarlo se puede implementar un paradigma de arquitectura desacoplada. Este paradigma tiene como principal beneficio el permitir que sus componentes individuales operen de forma independiente y al mismo tiempo seguir funcionando aún cuándo otros componentes fallen o queden sin poder brindar servicio.

Ahora viene la pregunta, ¿Como lo hacemos?

La técnica mas utilizada que les recomendamos para alcanzar este objetivo es la utilización de colas de mensaje y bus de eventos. Estos componentes se ubican entre medio de diferentes servicios y almacenan temporalmente las peticiones enviadas por un micro servicio de origen, hasta que el micro servicio de destino este listo para consumirlas. De esta manera, frente a algún problema o demora en el micro servicio consumidor, los datos no se pierden y pueden ser consumidos apenas se restablezca su disponibilidad. Otra de las ventajas de este tipo de arquitecturas es la capacidad de escalar de forma independiente los componentes individuales. Al no tener comunicación sincrónica, los aumentos de demanda de recursos en un componente especifico no se traducen directamente en un aumento de demanda hacia los demás servicios ya que los motores de mensajería y eventos sirven como un «Buffer» que pueden crecer de manera elástica en caso de un aumento repentino en la cantidad de transacciones. AWS cuenta con diferentes alternativas para cumplir con esa necesidad tales como Amazon SQS, Amazon SNS y Amazon EventBridge que ofrecen diferentes formas para integrar servicios y permitir una comunicación desacoplada.

Afinar el Uso de las Bases de Datos Según el Propósito.

En una arquitectura basada en micro servicios, recomendamos el uso de bases de datos especializadas y descentralizadas debido a que pueden ayudar a que las aplicaciones móviles y los portales web puedan obtener mejoras significativas de performance de manera costo-eficiente en especial en situaciones de grandes variaciones de demanda.
En la sección de mediano plazo vieron como recomendamos desacoplar la capa de base de datos incorporando diferentes servicios que buscaban aumentar la escalabilidad, disponibilidad y el rendimiento, sin embargo, no especificamos detalles sobre como los servicios de back-end serian capaz de utilizarlos. Es por eso que en la etapa de largo plazo les recomendamos hacer una re-ingeniería de su back-end para que puedan identificar que micro servicios funcionarían mejor con otras bases de datos.

Veamos algunos ejemplos que podrían ayudarlos en este proceso.

La utilización de bases de datos llave-valor, como DynamoDB, puede facilitar el acceso rápido a datos como los catálogos de productos, promociones activas o el carrito de compras. Aquellos micro servicios que requieran una capa de persistencia de datos podrían perfectamente tener su propia tabla de DynamoDB.

Para los perfiles de clientes y cupones de descuentos, las bases de datos basadas en documentos tales como DocumentDB ofrecen la posibilidad de buscar e indexar archivos JSON de forma ágil y escalable.

Extender el uso de las bases de datos en memoria como Amazon ElastiCache para entregar acceso a datos con baja latencia y alto grado de procesamiento, ideal para las búsquedas frecuentes, catálogos, inventarios y todo tipo de datos que deban consultarse constantemente de forma reiterada.
Sin duda hay muchos mas ejemplos, pero queda claro el objetivo. Recordaran que estas recomendaciones las mencionamos en el mediano plazo, pero ahora la idea es profundizar su utilización al máximo. Sabemos que cuando se logra, los resultados colaboran notablemente en el desempeño global de todo el e-commerce.

Incorporar Servicios Serverless en el Front-end

En esta etapa de largo plazo, posiblemente su e-commerce ya cuenta con una complejidad de componentes y carga operacional importante. En este escenario debemos buscar una solución mas eficiente para poder seguir escalando y ampliando las capacidades del e-commerce sin perder velocidad y eficiencia. Por estas razones, nuestra principal recomendación es la de re-arquitectar con un paradigma de construcción de arquitectura ampliamente conocido como Serverless. Este paradigma trae sustanciales beneficios en la operación y mantenimiento del e-commerce, ya que al no tener que administrar ningún tipo de infraestructura, estas responsabilidades son delegadas a AWS y se ahorra tiempo que puede ser invertido en la innovación y construcción de nuevas funcionalidades que brinden mejores experiencias para los clientes.
Ese tipo de servicio además, estan muy alineados con la construcción de arquitecturas basadas en micro servicios, ya que estan diseñados para funcionar de forma desacoplada. Hay que destacar también que la utilización de estos, se da a través de API y SDKs y traen herramientas de monitoreo, logs, tunning y parametrización que son fundamentales para una operación de un e-commerce a gran escala, tema que hablaremos con mayor profundidad mas adelante.
Queremos destacar además que estos servicios serverless en su gran mayoría tienen el modelo de pago por uso, lo que entrega eficiencia de costo al momento de utilizarlos.

Como han podido observar, a lo largo de las diferentes etapas evolutivas, hemos ido recomendando incorporar servicios serverless como: CloudFront, S3, DynamoDB, Fargate, API Gateway, Cognito, Route53, Lambda, SQS y Event Bridge y que hoy día, constituyen los pilares fundamentales de arquitecturas modernas para un e-commerce.

Hora de Medir el Rendimiento y las Capacidad del E-Commerce

Luego de haber definido la arquitectura a ser utilizada, el siguiente paso consiste en la definición de las pruebas de carga, la validación de los limites y el monitoreo.
Para alcanzar ese objetivo, nuestros clientes realizan todo tipo de pruebas de carga en los diferentes componentes de la arquitectura, buscando encontrar limites que no hayan podido identificar previamente, para luego incrementarlos con anticipación. Les recomendamos revisar los «Soft Limits» fácilmente modificables utilizando las «Service Quotas» o creando un ticket de soporte y los «Hard Limits» no modificables, ligados a las funcionalidades y arquitectura de cada servicio.

Los limites existen por una simple razón: Proteger al cliente de usos indebidos y de patrones de diseño incorrectos que puedan consumir recursos inadecuadamente.

A nadie le gustaría tener una arquitectura perfecta cuyos limites no hayan podido ser validados y analizados y en consecuencia experimentar perdidas de servicio por este tema. El éxito de un evento masivo depende de realizar esta etapa con planificación y tiempo.

Operando Durante el Evento

Para los equipos de TI, atravesar un evento de alta demanda puede ser análogo a la situación que experimenta una tripulación en un barco que tiene que navegar por una gran tormenta en el medio del mar. Tienen claro que viene la tormenta, tienen información pero hay incertidumbre sobre lo que puede pasar.

Hay una realidad. Por muchas pruebas que se le hagan a la solución, siempre hay que estar preparado para eventos inesperados y tener la suficiente visibilidad de saber cómo actuar en consecuencia. Por esta razón recomendamos que construyan dashboards de monitoreo en ambientes multi cuenta haciendo uso del servicio Amazon CloudWatch que mencionamos anteriormente.
Algunos ejemplos de los dashboards mas comunes son:

• Uso de CPU y memoria del computo.
• Cantidad de llamadas de APIs.
• Cantidad de conexiones a las bases de datos.
• Latencia entre micro servicios

Y la lista puede seguir mucho mas, tanto como cada área de TI lo requiera.
Veamos como se ven algunos de estos ejemplos.

El ultimo paso, es definir como operar durante el evento y para estas situaciones mencionaremos algunas practicas operacionales que son común denominador en nuestros clientes.

• Utilizan War Rooms en donde hay equipos de diferentes verticales de tecnología durante todas las horas que dura el evento con la capacidad de compartir sus dashboards de monitoreo.
• Cuando se trabaja con Enterprise Support de AWS, el Technical Account Manager (TAM) trabaja y lidera un programa pro-activo denominado Infraestructure Event Managament (IEM) el cual se enfoca en la planificación y definición de actividades para mitigar riesgos asociados a eventos críticos como los son un Black Friday. De igual forma un cliente con Business Support puede acceder a este servicio pagando por cada IEM.
• Es posible que llegada la fecha del evento, puede que no se haya podido implementar todos los cambios deseados, teniendo que aceptar los riesgos de que ciertos componentes de la infraestructura posean únicos puntos de falla o problemas que puedan afectar el servicio. Llegado el caso, lo que se hace es tener planes de contingencia y que todo el equipo conozca como actuar para mitigar y remediar cada incidente con velocidad.

¿Se Puede Continuar Mejorando?

La respuesta corta es: Claro que si. Ahora profundicemos.

Vieron en la sección de definición de arquitectura, que dividimos los cambios evolutivos en tres etapas que les permitirán madurar su e-commerce a lo largo del tiempo. Una vez alcanzadas todas las etapas o en paralelo de alguna de ellas, pueden buscar puntos de mejoras relacionados con:

• Reducción de costos. Principalmente nuestros clientes hacen un uso intensivo de recursos de cómputo por lo que hay una gran inversión de tiempo en como optimizar esta capa. Y para lograrlo, buscan utilizar modelos de pago por cómputo basado en Instancias Reservadas, Saving Plans y Spot. Por una cuestión de espacio y por lo amplio de este tópico, nos gustaría recomendarles este Blog post sobre optimización, que tiene varios de las principales recomendaciones.
• Seguridad y gobierno es otro punto de mejora continua en donde la base de este pilar comienza por la estructura multi cuenta capaz de ayudar a controlar mas eficientemente la seguridad y los costos de los diferentes ambientes y sobre esta estructura recomendamos ir incorporando diversos servicios de seguridad para lograr el objetivo de un e-commerce mas seguro.
• Implementar practicas de CI/CD para agilizar los despliegues en todo el stack de su e-commerce. Pueden complementar estas practicas con funcionalidades como el «Serverless Appplication Model», el «Cloud Development Kit» y herramientas de terceros.
• Optimizar las comunicaciones del back-end con servicios como: AppMesh, CloudMap y VPC Endpoints que ayudaran en gran manera a mejorar la visibilidad y aportarán mayor control, flexibilidad e inteligencia a las comunicaciones entre micro servicios.
• Incorporar Route53 Resolver para mejorar la resolución de nombres entre los ambientes del centro de datos local y AWS será clave para simplificar la integración con sistemas legados.
• Y finalmente la implementación de un datalake como repositorio principal de la información para la toma de decisiones y funcionamiento del e-commerce.

Como ven existen muchos puntos de mejoras, y según las prioridades, cada empresa identificará que camino seguir. Sin embargo estos apuntan a un objetivo común: Acompañar los objetivos de crecimiento del negocio, construir, desplegar y operar con mayor agilidad al mismo tiempo que se reducen los costos, se mejora el gobierno de los servicios en la nube y se cuenta con mayor información para tomar decisiones.

Nuestras Conclusiones

Operar e innovar para un e-commerce sin duda tiene sus desafíos, siendo el principal, poder contar con una plataforma robusta. Sin duda existen otros desafíos igual de complejos, que van mas allá de los aspectos tecnológicos, como la logística y el manejo de inventarios entre muchos otros. Sin embargo la base para brindar una gran experiencia de compra, comienza por el nivel de madurez que su arquitectura ha podido adquirir a lo largo del tiempo.
Hemos visto como gradualmente se puede transformar un e-commerce en una arquitectura altamente escalable, ágil, capaz de adaptarse a los cambios, desacoplada, Serverless y con foco en micro servicios capaces de sostener los mas altos niveles de disponibilidad que el negocio requiere.
Esperamos que estos dos blogs post les permitan diseñar su propio camino hacia una mejor experiencia de compra para sus clientes y no duden en contactarnos si necesitan nuestro apoyo para hacerlo.

Sobre los Autores

Adler Oliveira es Arquitecto de Soluciones en AWS con foco en clientes del segmento Enterprise Retail.

Bruno Laurenti es Arquitecto de Soluciones en AWS con foco en clientes del segmento Enterprise Financiero y Retail.

Sobre los Revisores

Sergio Barraza es Technical Account Manager en AWS con foco en clientes del segmento Enterprise Retail.

Angel Goñi es Arquitecto de Soluciones en AWS con foco en SAP y la industria CPG (Consumer Packaged Goods)