Las plataformas e-commerce son cada vez más importantes en el día a día de las personas. En Hiberus creemos que son la evolución natural de los comercios tal y como los conocemos. Permiten hacer compras altamente personalizadas, desde donde queramos y cuando queramos, ya que su lugar es la web y están siempre abiertas para el público. La población joven, que generalmente se desenvuelve mejor en el mundo digital, ha incrementado en un 29% el número de compras online en los últimos 10 años.
¿Qué es el Black Friday?
El Black Friday se originó en E.E.U.U. en el siglo pasado y en los últimos años ha llegado a España, haciéndose altamente popular. Este fenómeno consiste en que los comercios realizan grandes descuentos durante unos pocos días (que coinciden con el cuarto viernes de noviembre, día posterior al Día de Acción de Gracias), para dar el pistoletazo de salida al inicio de las compras navideñas. Estos descuentos se traducen en un aumento de ventas extraordinario, del que no se salvan tampoco las grandes plataformas de e-commerce, pues han de ser capaces de atender a muchas más peticiones sin que el servicio se degrade (QoS), o, en casos extremos, se desvanezca.
El reto que supone el Black Friday
La variación de tráfico que tienen que tener en cuenta las plataformas e-commerce para estos días es abrumadora. Por ejemplo, en España, hay un aumento del 706% de las ventas online con respecto a un día normal, que no es nada en comparación con el 3501% de Austria. Es por esto que, a día de hoy, las plataformas e-commerce se idean, se diseñan y se implementan teniendo en cuenta, sobre todo, la existencia de días como el Black Friday.
De poco sirve que el servidor funcione bien el 95% del tiempo cuando el 5% restante es tiempo en el que puedes facturar cantidades mucho mayores de dinero. Ese 5% es un tiempo nada despreciable, pues supone un coste de oportunidad muy alto, además del precio a pagar en términos de malos comentarios (todos hemos visto redes sociales plagadas de memes cuando alguna plataforma deja de estar disponible).
Monolitos: simples pero limitados
Históricamente, los monolitos han sido la solución más usada por pequeños, medianos y grandes retailers a nivel mundial. Técnicamente, un monolito consiste en una única pieza de código, esto es, encapsular todas las funcionalidades del sistema en un único lugar: gestión de usuarios, gestión de catálogo, gestión de promociones, etc. Puede parecer la solución más natural, de hecho, es la más sencilla y directa a un mínimo producto viable (MVP) a cambio de sacrificar otros aspectos como la escalabilidad horizontal, alta disponibilidad, etc.
En una arquitectura monolítica…
¿Qué ocurre si se realizan muchos pedidos en el Black Friday?
Todas las funcionalidades están gestionadas por una única máquina, por lo que, si esta falla, todo falla. Incluso puede fallar “parcialmente”, es decir, el servidor no se cae, pero no dispone de suficientes recursos para aguantar la demanda, por lo que el resto de funcionalidades se ven afectadas, desembocando en una falta de disponibilidad.
¿Qué se puede hacer?
Si el servidor se queda sin recursos, siempre se pueden añadir más a la máquina (RAM, CPU, disco…). A esta solución se le denomina como “escalabilidad vertical”.
¿Qué ocurre con los recursos que hemos comprado para soportar el pico de demanda del Black Friday y que ahora no necesitamos?
Es muy probable que estos recursos no se puedan devolver. Han sido comprados, y, ahora, se va a estar operando con un sistema capaz de soportar las horas punta en un Black Friday aunque realmente sea un martes de marzo a las 05:48 de la mañana, con mucha menos demanda. Con otro tipo de soluciones, el sistema podría reescalar sus recursos automáticamente en función de la demanda, es decir, podría ser elástico.
¿Qué ocurre si ahora nuestra plataforma e-commerce añade una integración con otra empresa de paquetería?
Lamentablemente, con la solución monolítica, es necesario reiniciar todo el sistema para poder incluir cambios en él (mejoras, nuevas características, arreglo de bugs…). Esto supone un corte del servicio, que podrá afectar a la economía de la empresa.
Error 404… ¿y ahora qué?
Los usuarios parten de la idea de que todo está abierto las 24 horas en Internet. En una arquitectura monolítica es prácticamente imposible estar el 100% del tiempo disponible. Puesto que lo ideal es un uptime del 100%, un porcentaje menor no es admisible en muchos casos. No hay que olvidar que un uptime del 99% implica que la web esté caída durante 3 días y medio al año. ¿Y si estos 3 días y medio fueran los del Black Friday?
Microservicios: así lo hacemos en Hiberus
La arquitectura de microservicios se fundamenta, básicamente, en romper el monolito. Una aproximación podría pasar por diseñar tantos microservicios como entidades (usuarios, pedidos, productos, etc.) tenga el sistema. Esta aproximación favorece la segregación de responsabilidades, la cohesión de todas las partes de la solución, la simplicidad de cada de uno de los microservicios (principio KISS) y la evolución individual de cada uno de los mismos. Permite el desacople de los equipos de trabajo pudiendo centrarse cada uno en una parte específica del dominio del problema.
En una arquitectura basada en microservicios…
¿Qué ocurre si se realizan muchos pedidos en el Black Friday? ¿Irá lento todo el sistema?
Casi por definición, el resto de funcionalidades no se ven afectadas si no dependen de la funcionalidad de pedidos. Esto se traduce en que el registro de usuarios o la inserción de nuevos productos al catálogo funcionarán exactamente igual haya 1, 10 o 10000000 de pedidos a la hora.
¿Irá lenta toda la parte de pedidos?
No necesariamente, ya que un microservicio debería ser fácilmente encapsulable en un contenedor. Estos contenedores pueden replicarse (sí, hacer clones), permitiendo tener varias instancias/copias de un microservicio. Esto favorece el reparto de trabajo (distribuyendo las peticiones a un contenedor o a otro) y la alta disponibilidad (teniendo un número de instancias de un contenedor en marcha como mínimo). Para esto se utilizan herramientas como OpenShift o Kubernetes, que además también permiten escalar de manera automática el número de microservicios en función de la demanda (elasticidad), lo que se traduce por:
Mucha demanda de pedidos -> Se levantan más contenedores del microservicio que gestiona los pedidos
Poca demanda -> Se dejan en marcha tantos contenedores como marque la política de QoS (Quality of Service)
¿Cómo se coordinan/comunican para llevar a cabo sus tareas?
Un microservicio puede depender de otro(s), por ejemplo si necesita información para realizar la operativa. Esta arquitectura se basa en un sistema distribuido conformado por una red de comunicaciones. Esta red será más o menos densa dependiendo del número de microservicios que haya y las dependencias entre ellos.
Existen dos grandes aproximaciones:
- Aproximación síncrona: si un microservicio depende de otro hace una llamada y espera la respuesta para continuar con su tarea.
- Aproximación asíncrona: si un microservicio depende de una información que tiene otro microservicio, éste último publica esa información cada vez que cambia, por ejemplo, mediante eventos. Esto se denomina arquitectura de microservicios basados en eventos (event-driven architecture).
¿Qué ocurre si uno cae?
Depende en gran parte de la aproximación elegida. Sin embargo, no hay que olvidar que un gran número de interacciones entre distintos microservicios implica que nuestro sistema tiene muchas partes acopladas entre sí. Y este acoplamiento tiene que ser evitado en la medida de lo posible. Evidentemente, en casos como una arquitectura basada en microservicios muchas de (o todas) estas interacciones van a ser necesarias (por ejemplo, para realizar un pedido se necesita saber si se dispone de stock suficiente).
En la aproximación síncrona se puede hacer uso del patrón circuit breaker, que evitará una caída en cascada. Este patrón, a grandes rasgos, impide que, durante un tiempo, se realicen llamadas a un microservicio que anteriormente ha dado problemas: no ha contestado.
En la aproximación asíncrona no pasa nada. En este caso no se necesita que ambos microservicios estén acoplados temporalmente, pues utilizando soluciones como colas (Apache Kafka, RabbitMQ…) se sabrá en base a eventos cuántos artículos quedaban antes de que se cayera el microservicio de stock, entre otros.
¿Qué ocurre si ahora nuestra plataforma e-commerce añade una integración con otra empresa de paquetería?
Si se ha planteado bien la arquitectura, nada. Solamente habría que lanzar nuevas instancias de la parte de integraciones con terceros (que puede y debería ser fácilmente un microservicio).
Nuestra visión es ser el socio tecnológico en microservicios de nuestros clientes. Esta visión se plasma en aportar a cada cliente la mejor solución y el mejor servicio que necesita en cada momento. Supone compartir toda nuestra experiencia y capacidades, crecer con nuestros clientes y estar preparados para aportarles el “impulso” necesario en cada momento.
Ser “socio tecnológico” de nuestros clientes también supone entender su negocio y asegurar el alineamiento de la tecnología y de nuestros servicios para potenciar sus objetivos de negocio. Contáctanos con tu caso y nuestro equipo te dará la mejor solución.
Autores: Ángel Cañal, Alejandro Gómez y Raúl Javierre.
¿Quieres más información sobre nuestra área de Microservicios?
Contacta con nuestro equipo de Microservicios
