Análisis, diseño e implementación de un servicio de comercio electrónico en la nube

Resumen

En el contexto actual, se han identificado, por un lado, ciertas iniciativas que manifiestan que el software en el contexto empresarial no es accesible para las pequeñas empresas (debido a ello se plantean planes estatales de inversión como AceleraPyme). Por otro lado, que ciertas tecnologías, sobre todo el despliegue en la nube, permiten crear servicios baratos y eficientes. Así, dado una pyme, primero Breadfree (breadfree.es), una tienda de venta de pan sin gluten y luego Piedad León Art (piedadleon.art), una artista de arte hiperrealista a grafito, el objetivo de este proyecto es analizar, diseñar e implementar un servicio de comercio electrónico en la nube.
A continuación, se discuten tres puntos. Cada pregunta está relaciona con el método del “design thinking”, una metodología para favorecer la innovación que consta de 4 fases.
La primera se llama “what is?” Y se elabora en la sección de captura de requisitos y estado del arte. Básicamente sobre la realidad, sobre el mercado, ¿qué usuario ha identificado qué necesidades? ¿Qué hay? Para ello primero se describen los procesos de negocio que se han identificado (caso de uso de tienda online y de gestor de inventarios) con el fin de plantear un marco de comparación de soluciones basado en métricas objetivas (una relacionada con cada caso de uso, una relacionada con la disponibilidad, otra con la seguridad y otra con el precio de la solución). A continuación, se describen las herramientas o soluciones existentes en el mercado en base a ese marco. Para entender las soluciones se realiza una taxonomía en función de los paradigmas de despliegue, desde on premise, IaaS, PaaS y SaaS. Se descarta “On premise” por precio, se identifican soluciones posibles como combinación de SaaS, por ejemplo, Shopify o Wix que permiten el caso de uso de tienda online, con Katana o Odoo que permiten la gestión de operaciones. Y se focaliza la investigación en despliegues IaaS o PaaS como “Container as a Service” que permiten desplegar un proyecto de código libre que permita ambos casos de uso.
En el siguiente apartado de análisis y diseño: se identifica el caso de estudio como resumen de la fase anterior, respondiendo así a la fase. “what if?”, y se plantea un diseño de posibles tecnologías. Hipotéticamente ¿qué es lo que busca la pyme? Una solución que permita estos dos casos de uso al menor precio posible. Se plantea un diagrama de casos de uso y varios diseños en cada fase de la sección posterior.
A continuación, en el apartado de implementación se desarrolla la evolución de la propuesta de soluciones, describiendo en cada artefacto el “what wows?” el qué de beneficio tiene cada artefacto en función de este marco de referencia propuesto.
- Fase 0: comparativa despliegues: jenkinsX(eks, gke), cloudformation. El objetivo de esta fase inicial no es implementar una solución entera, sino comprar en cuanto a la
6
parte de infraestructura las dos soluciones más extendidas IaaS, sobre todo para comparar precio: kubernetes y arquitecturas de cloud formation, resultando ser kubernetes la solución a elegir, si bien ambas son válidas y plantean un coste de 60€/mes, la gran ventaja de kubernetes frente a cloud formation es que no es una solución propietaria. Primero se realiza un prototipo de despliegue de servicio en alta disponibilidad, de un servicio con frontend y backend genérico en kubernetes, usando Jenkins X para implementar despliegue e integración continua sobre el repositorio de github. Por un lado, por otro lado, se plantea un despliegue de un sistema en cloud formation, definiendo las redes, los servidores y las bbdd.
- Fase 1: FaaS shop: en una segunda fase. Se diseña e implementa un artefacto lo más barato posible. Primero, se implementa un frontend básico en html y se encuentra lambda como el hosting más barato, pues el primer millón de peticiones se ofrece gratis. Luego, se plantea que para que el gestor de la tienda no sepa programar es necesario implementar más lógica. Para ello se implementa una demo de tienda serverless sobre lambda usando el stack serverless. Básicamente con la funcionalidad de un servicio de “todos” ampliado. Con una base de un frontend en angular y un backend en typescript también usando dynamo db. Este artefacto en fase Alpha no permite los casos de uso 1 y 2, pero cumple de por sí cumple la métrica de disponibilidad y la de precio, pero no la de seguridad.
- Fase 2: saleor + gcp (cloud run + cloud sql): en esta fase se desarrollan los distintos casos de uso que implementan esta “lógica” que se describe en el apartado anterior y se plantea un despliegue en un servicio Container as a Servicice, cloud run, en el que el primer millón de peticiones es gratis. Así, el coste del despliegue únicamente recae en la base de datos. Se despliega un proyecto de código libre llamado saleor, un frontend en react y un backend en Python. Se personaliza la tienda para breadfree usando figma como herramienta de prototipado. Se llega a la conclusión que es una solución que permite alta personalización en el frontend, pero le falta de integración de gestión de inventarios. Se lleva a fase beta, cumple 1 a medias porque no permite CMS pero no cumple el caso de uso 2, y no cumple las métricas de seguridad y disponibilidad para una métrica de precio aceptable.
- Fase 3: odoo ce + aws (fargate + auroraserverless): en una tercera fase, en cuanto a despliegue se encuentra una base de datos serverless en aws, pero resulta que los despliegues en aws a diferencia de gcp necesitan de un balanceador de carga 24/7 que ya por sí sólo consume 15€/mes. Así que, tras un planteamiento inicial, se replantea el despliegue en GCP. En cuanto al código se plantea modificar el proyecto de código libre más grande después de saleor, odoo, que no sólo incluye un módulo de tienda sino otro de gestor de inventarios. Este artefacto no pasa de la fase alpha.
7
- Fase 4: odoo ce + gcp (cloud run + cloud sql) y vm: en esta fase se despliega primero odoo ce en cloud run y cloud sql, de un coste de 10€/mes, pero se encuentra que odoo persiste en su memoria la sesión y cloud run son contenedores efímeros. De forma que se replantea el despliegue a un nodo vm para pasar a un futuro despliegue en kubernetes en alta disponibilidad. Se despliega, el código implementa los casos de uso, pero el presupuesto para un usuario es de 60€/mes, mayor que el coste de wix o Shopify. Es decir, en cuanto al marco, cumple con los casos de uso 1 y 2, y no cumple con las métricas de disponibilidad y seguridad para la métrica precio propuesta.
- Fase 5: (wp + wc + plugins) + namecheap: finalmente se plantea un despliegue de woocommerce en namecheap, buscando implementar los casos de uso que se han definido. Se llega a un coste de 4€/mes, es decir permite cumplir las 5 métricas.
Finalmente, en una fase de conclusión se desarrolla el “what works?” De los artefactos que se han elaborado qué funciona de cada uno. Se resume que de los artefactos que han llegado a la fase beta, los de la fase 2, 4 y 5, es el artefacto 5 el que mejor queda en la comparación de métricas: si bien un despliegue en kubernetes de 2 y 4 pueden presentar más grado de personalización que 5, 5 ofrece mejor resultado en el resto de las métricas a menor precio. 1 es una buena propuesta, pero desarrollarla implica elevado coste. Así, se destaca también que se han cumplido los objetivos se han evaluado 15 herramientas, discutido 15 stacks IaaS/PaaS distintos, trabajado con 4 proyectos de código libre, proponiendo 3 soluciones en fase beta.