VolverBack

Infraestructura - E-commerceInfrastructure - E-commerce

Repositorio Infraestructura Aplicaciones Repositorio Infraestructura Almacenamiento Repositorio Infraestructura Analítica

Resumen

Diseño de la arquitectura en la nube de un e-commerce sobre Azure y su aprovisionamiento como infraestructura como código con Terraform, organizado en tres repositorios por responsabilidad: aplicaciones, almacenamiento y analítica.

Logros clave

  • Arquitectura completa justificada componente por componente: dos UI (FrontOffice y BackOffice), una API compartida, base de datos OLTP, Blob Storage, caché y Datawarehouse.
  • Procesamiento asíncrono con Queue Storage y Azure Functions para tareas que no requieren respuesta inmediata, como la confirmación de pedidos.
  • Azure Cache for Redis para carrito, sesión y datos frecuentes, buscando una experiencia fluida.
  • Datawarehouse y ETL con Azure Data Factory para el análisis estratégico del negocio.
  • Infraestructura en Terraform separada en tres repositorios con responsabilidad única, referenciando recursos compartidos entre ellos.

Stack

Azure (App Service, Queue Storage, Functions, SQL Database, Blob Storage, Cache for Redis, Data Factory), Terraform.

Descripción del Sistema E-commerce

  • Infraestructura escalable y robusta en la nube.
  • Gestión de operaciones de venta en línea.
  • Soportar alto volumen de transacciones.
  • Proporcionar experiencia de usuario fluida a través de un portal principal.
  • Permitir la gestión interna de productos y pedidos desde un BackOffice.
  • Ofrecer capacidades analíticas avanzadas sobre los datos de venta para la toma de decisiones estratégicas.
  • Plataforma capaz de manejar tareas intensivas o que no requieren una respuesta inmediata al usuario de forma eficiente en segundo plano.
  • Asegurar que la experiencia de usuario no se vea afectada por procesos de larga duración, como confirmación de pedidos, actualización de inventarios complejos o generación de notificaciones masivas.

Servicios identificados a usar

  • Azure App Service - Webapp FrontOffice

  • Azure App Service - WebApp BackOffice

  • Azure App Service - WebApp API

  • Queue storage - Cola de tareas sin respuesta inmediata

  • Azure Functions - Serverless para ejecución de tareas en segundo plano

  • Azure SQL Database - DB OLTP

  • BLOB Storage - Almacenamiento de multimedsia

  • Azure Cache for Redis - Almacenamiento de datos volátiles

  • Azure SQL Database - Datawarehouse

  • Azure Data Factory - Orquestador del ETL

Diseño de la Solución

Diagrama Arquitectura

Justificación de los componentes arquitectónicos

  • Dos WebServer para UI. Separar responsabilidades entre un FrontOffice, BackOffice, y mejorar la seguridad.
  • DB SQL OLTP. Alojar la información transaccional del negocio.
  • BLOB Storage. Almacenar contenido estático y todos los archivos multimedia del negocio.
  • Webserver para API. Maneja el acceso a los almacenamientos de datos del negocio. Una API compartida por ambas UI, ya que la UI del negocio no exige un costo computacional tan grande como para realizar una API única.
  • Queue Storage y Azure functions. Manejar tareas en segundo plano y que no requieren respuesta inmediata, para evitar una alta carga de trabajo en el servidor que aloja la API.
  • Azure Cache for Redis. Para alojar data frecuentemente visitada, carrito de compras, sesión del cliente, para lograr una UX fluida.
  • Azure Data Factory y DW. Un orquestador para manejar el proceso ETL entre la DB OLTP del negocio y el Datawarehouse que guardará los datos listos para realizar análisis estratégico.

Justificación más detallada del uso de los servicios (opcional)

  • Cada tipo de usuario (clientes, editores) podrá acceder desde una UI en un servidor dedicado (FrontOffice y BackOffice).
  • Las UI toman información de la base de datos SQL por medio de una única API (se ha decidido dejar una sola API, porque la gestión del negocio requiere de un costo computacional mucho menor que el realizado por los clientes).
  • La UI de cliente prioriza la eficiencia y experiencia de usuario fluida, entonces la UI de cliente podrá enviar mensajes en Queue storage para pedidos, transacciones, etc., que luego serán ejecutadas en segundo plano por un Serverless.
  • UI de cliente usará el almacenamiento en caché (Azure Cache for Redis) para alojar información como el carrito de compras, datos de sesión e información frecuentemente visitada, asegurando una experiencia de usuario sin retardos.
  • Para el análisis de negocio se usa el orquestador Data Factory, para hacer el proceso ETL entre la base de datos OLTP y el Datawarehouse, para que luego la información del Datawarehouse pueda ser solicitada por la API o una herramienta externa (Power BI), y que la gestión del negocio pueda realizar el análisis estratégico.

Evidencias de Despliegue

Despliegue de los servicios de la infraestructura de aplicaciones

Creación del grupo de recursos:

Grupo de recursos

Grupo de recursos 2

Creación de los tres Service Plan y sus respectivas Web Apps:

Service Plan 1

Service Plan 2

Service Plan 3

Creación de los servicios Queue Storage y Azure Functions (Servicios Serverless):

Queue Storage

Azure Functions

Despliegue de los servicios de la infraestructura de almacenamiento

Creación de la DB OLTP

DB OLTP 1

DB OLTP 2

Creación del BLOB Storage

BLOB 1

BLOB 2

Creación de Azure Redis for Cache:

Redis 1

Redis 2

Despliegue de los servicios de la infraestructura de analítica

Creación de DB para Datawarehouse

OLAP 1

OLAP 2

Creación de Azure Data Factory (Orquestador ETL)

Data Factory 1

Data Factory 2

Código en Tres Repositorios Independientes

Se ha decidido separar los recursos en módulos del negocio, en tres repositorios diferentes:

  • Módulo de aplicaciones
  • Módulo de almacenamiento
  • Módulo de analítica

Al descubrir que se puede optar por compartir recursos (e.g. servicio de base de datos puede ser compartido por la base de datos DW y OLTP, servicio de cuentas de almacenamiento puede ser compartido por Queue Storage y Azure Functions), la separación de los repositorios depende de más comunicación sobre los servicios que se crean.

Repositorio Infraestructura de Aplicaciones

UI y tareas asíncronas

  • Azure App Service - Webapp FrontOffice
  • Azure App Service - WebApp BackOffice
  • Azure App Service - WebApp API
  • Queue storage - Cola de tareas sin respuesta inmediata
  • Azure Functions - Serverless para ejecución de tareas en segundo plano

Repositorio Infraestructura de Almacenamiento

Todo lo que tiene que ver con datos en tiempo real y caché.

  • Azure SQL Database - DB OLTP
  • BLOB Storage - Almacenamiento de multimedia
  • Azure Cache for Redis - Almacenamiento de datos volátiles

Repositorio Infraestructura de Analítica

Para Datawarehouse y orquestación ETL.

  • Azure SQL Database - DW
  • Azure Elastic Jobs - Orquestador del ETL

Reflexiones Finales

Separación de la Infraestructura en Repositorios

  • Inicialmente se consideró la idea de hacer la separación estrictamente por los servicios ofrecidos (e.g. todo lo relacionado con almacenamiento en un repositorio, todo lo relacionado con UI en otro repositorio y todo lo relacionado con funcionalidad serverless en el tercer repositorio).
  • Finalmente los servicios se agruparon en tres categorías de actividades realizadas (UI, almacenamiento y analítica), de esta forma cada repositorio tiene una responsabilidad única.
  • Con este tipo de separación entre los repositorios, habían recursos que se deseaba ser compartidos, pero estaba en repositorios distintos. Esta problemática fue el escenario perfecto para poner en práctica la referencia de servicios desde un repositorio diferente.

Sistema implementado para el procesamiento asíncrono de tareas en segundo plano

  • La aplicación está compuesta por una sola API que es consumida por dos UI, se ha tomado esta decisión porque la UI BackOffice no representará una carga computacional tan grande como la UI FrontOffice.
  • Para reducir aún más el consumo de la API por parte del FrontOffice se hace uso de un servicio de Redis Cache. Puede ser usado para manejar la sesión, el carrito de compras e incluso data frecuentada por el cliente.
  • También se hace uso de servicio Queue Storage, para guardar en cola las tareas de los usuarios que no exigen una respuesta inmediata (e.g. confirmación de compra, transacciones). Estas tareas o mensajes luego serán ejecutadas por el servicio Azure Functions, que funciona de manera serverless logrando mitigar la carga innecesaria en la API general de la aplicación.

Uso de un Datawarehouse y herramienta de orquestación ETL

  • Una base de datos OLTP donde se guarda toda la información transaccional del negocio, un servicio llamado Azure Data Factory (orquestador) y el Datawarehouse para guardar la información procesada para análisis del negocio, son las herramientas involucradas para la toma de decisiones a partir de los datos.
  • Los procedimientos almacenados que forman parte del ETL están alojados en el Datawarehouse, el orquestador simplemente se encarga del flujo de trabajo realizado por el ETL.
  • El uso de estos elementos para el desarrollo de un DW es una opción excelente y más económica que otras opciones (desarrollo de IA para análisis de negocio o Azure Synapse Analytics), además, se puede identificar con precisión las estadísticas del negocio por medio de la data procesada.

Experiencia Personal Sobre el Proyecto

  • Personalmente, es la primera vez que utilizo servicios en la nube profesionales.

  • El desarrollo de una infraestructura en la nube y la creación de los servicios en Terraform para un proyecto de este tipo, es sencillo cuando ya se conocen los servicios que se necesitan crear.

  • El análisis de los servicios requeridos es un proceso complejo, ya que existen muchas opciones y muchas tecnologías (algunas podrían ser las indicadas, pero la inexperiencia en ella la puede descartar como posible opción) para satisfacer las necesidades de los negocios.

  • Como opinión personal, la clave para saber que servicios se pueden usar es identificar el costo de los servicios que esté dentro de las posibilidades de los clientes, y también conocer como funciona una tecnología e identificar si es la correcta para cubrir una necesidad en la aplicación que se va a implementar.

Overview

Design of an e-commerce cloud architecture on Azure and its provisioning as infrastructure as code with Terraform, organized into three repositories by responsibility: applications, storage and analytics.

Key achievements

  • Complete architecture justified component by component: two UIs (FrontOffice and BackOffice), a shared API, an OLTP database, Blob Storage, a cache and a data warehouse.
  • Asynchronous processing with Queue Storage and Azure Functions for tasks that do not need an immediate response, such as order confirmation.
  • Azure Cache for Redis for the cart, session and frequently accessed data, aiming for a fluid experience.
  • Data warehouse and ETL with Azure Data Factory for the business’s strategic analysis.
  • Terraform infrastructure split into three repositories with a single responsibility each, referencing shared resources across them.

Stack

Azure (App Service, Queue Storage, Functions, SQL Database, Blob Storage, Cache for Redis, Data Factory), Terraform.

E-commerce System Description

  • Scalable and robust cloud infrastructure.
  • Management of online sales operations.
  • Support a high volume of transactions.
  • Provide a fluid user experience through a main portal.
  • Allow internal management of products and orders from a BackOffice.
  • Offer advanced analytical capabilities over sales data for strategic decision making.
  • A platform able to efficiently handle intensive tasks, or tasks that do not require an immediate response to the user, in the background.
  • Ensure the user experience is not affected by long-running processes, such as order confirmation, complex inventory updates or mass notification generation.

Services Identified for Use

  • Azure App Service - FrontOffice WebApp

  • Azure App Service - BackOffice WebApp

  • Azure App Service - API WebApp

  • Queue storage - Queue for tasks without an immediate response

  • Azure Functions - Serverless for running background tasks

  • Azure SQL Database - OLTP DB

  • BLOB Storage - Media storage

  • Azure Cache for Redis - Volatile data storage

  • Azure SQL Database - Data warehouse

  • Azure Data Factory - ETL orchestrator

Solution Design

Architecture Diagram

Justification of the Architectural Components

  • Two web servers for the UI. Separate responsibilities between a FrontOffice and a BackOffice, and improve security.
  • SQL OLTP DB. Host the business’s transactional information.
  • BLOB Storage. Store static content and all of the business’s media files.
  • Web server for the API. Handles access to the business data stores. One API shared by both UIs, since the business-side UI does not demand enough computing cost to justify separate APIs.
  • Queue Storage and Azure Functions. Handle background tasks that do not require an immediate response, to avoid a high workload on the server hosting the API.
  • Azure Cache for Redis. Host frequently visited data, the shopping cart and customer session, to achieve a fluid UX.
  • Azure Data Factory and DW. An orchestrator to handle the ETL process between the business’s OLTP DB and the data warehouse that stores data ready for strategic analysis.

More Detailed Justification of the Services (optional)

  • Each type of user (customers, editors) can access from a UI on a dedicated server (FrontOffice and BackOffice).
  • The UIs take information from the SQL database through a single API (it was decided to keep a single API because business management requires a much lower computing cost than that generated by customers).
  • The customer UI prioritizes efficiency and a fluid user experience, so it can send messages to Queue storage for orders, transactions, etc., which are then executed in the background by a Serverless service.
  • The customer UI will use caching (Azure Cache for Redis) to host information such as the shopping cart, session data and frequently visited information, ensuring a delay-free user experience.
  • For business analysis, the Data Factory orchestrator runs the ETL process between the OLTP database and the data warehouse, so the data warehouse information can then be requested by the API or an external tool (Power BI), and business management can perform strategic analysis.

Deployment Evidence

Deployment of the application infrastructure services

Creation of the resource group:

Resource group

Resource group 2

Creation of the three Service Plans and their respective Web Apps:

Service Plan 1

Service Plan 2

Service Plan 3

Creation of the Queue Storage and Azure Functions services (Serverless services):

Queue Storage

Azure Functions

Deployment of the storage infrastructure services

Creation of the OLTP DB

DB OLTP 1

DB OLTP 2

Creation of the BLOB Storage

BLOB 1

BLOB 2

Creation of Azure Cache for Redis:

Redis 1

Redis 2

Deployment of the analytics infrastructure services

Creation of the DB for the data warehouse

OLAP 1

OLAP 2

Creation of Azure Data Factory (ETL orchestrator)

Data Factory 1

Data Factory 2

Code in Three Independent Repositories

The resources were separated into business modules, in three different repositories:

  • Applications module
  • Storage module
  • Analytics module

On discovering that resources can be shared (e.g. a database service can be shared by the DW and OLTP databases, a storage account service can be shared by Queue Storage and Azure Functions), the separation of repositories depends on more communication about the services being created.

Applications Infrastructure Repository

UI and asynchronous tasks

  • Azure App Service - FrontOffice WebApp
  • Azure App Service - BackOffice WebApp
  • Azure App Service - API WebApp
  • Queue storage - Queue for tasks without an immediate response
  • Azure Functions - Serverless for running background tasks

Storage Infrastructure Repository

Everything related to real-time data and cache.

  • Azure SQL Database - OLTP DB
  • BLOB Storage - Media storage
  • Azure Cache for Redis - Volatile data storage

Analytics Infrastructure Repository

For the data warehouse and ETL orchestration.

  • Azure SQL Database - DW
  • Azure Elastic Jobs - ETL orchestrator

Final Reflections

Splitting the Infrastructure into Repositories

  • Initially the idea was to split strictly by the services offered (e.g. everything related to storage in one repository, everything related to the UI in another and everything related to serverless functionality in a third).
  • In the end the services were grouped into three categories of activity (UI, storage and analytics), so each repository has a single responsibility.
  • With this kind of separation, some resources that were meant to be shared ended up in different repositories. This problem was the perfect scenario to practice referencing services from a different repository.

System Implemented for Asynchronous Background Task Processing

  • The application is made of a single API consumed by two UIs. This decision was made because the BackOffice UI will not represent as large a computing load as the FrontOffice UI.
  • To further reduce API consumption by the FrontOffice, a Redis Cache service is used. It can be used to manage the session, the shopping cart and even data frequently visited by the customer.
  • A Queue Storage service is also used to queue user tasks that do not demand an immediate response (e.g. purchase confirmation, transactions). These tasks or messages are then executed by the Azure Functions service, which works serverlessly and mitigates unnecessary load on the application’s general API.

Use of a Data Warehouse and an ETL Orchestration Tool

  • An OLTP database that stores all of the business’s transactional information, a service called Azure Data Factory (orchestrator) and the data warehouse that stores the information processed for business analysis are the tools involved in making decisions from data.
  • The stored procedures that are part of the ETL are hosted in the data warehouse; the orchestrator simply handles the workflow run by the ETL.
  • Using these elements to build a DW is an excellent and cheaper option than others (developing AI for business analysis or Azure Synapse Analytics), and business statistics can be identified precisely through the processed data.

Personal Experience with the Project

  • Personally, this is the first time I use professional cloud services.

  • Developing a cloud infrastructure and creating the services in Terraform for a project like this is straightforward once you know which services you need to create.

  • Analyzing the required services is a complex process, since there are many options and many technologies (some could be the right ones, but lack of experience with them may rule them out as an option) to satisfy business needs.

  • As a personal opinion, the key to knowing which services can be used is to identify the cost of the services within the client’s means, and also to understand how a technology works and whether it is the right one to cover a need of the application to be implemented.

Tecnologías utilizadas:Technologies used: