Marco de Referencia Arquitectura Backend

Owned by Onesait Platform
12/05/23
3 min read

Propósito

El objetivo de este marco de referencia es servir de guía de arquitectura backend desde el punto de vista técnico y lógico en el desarrollo de soluciones Onesait.

Entre otros datos, se puede encontrar Información y referencias para, bajo un framework tecnológico común, iniciar el desarrollo de un nuevo producto o trazar una estrategia de convergencia a tecnologías open source comunes con objetivos de homogeneización, mejora de eficiencia y eliminación de puntos de obsolescencia.

Desde este punto se podrá acceder tanto a estándares como arquetipos y aceleradores que ponen en práctica los principios teóricos y que sirve de aceleración.

Visión Cloud Native

La visión global de Arquitectura Onesait tiene un orientación muy próxima a Cloud Native (nube nativa). Cloud Native es un patrón de arquitectura de software para desarrollar aplicaciones usando principios esenciales de cloud computing como la escalabilidad, velocidad/agilidad y ahorro. 

Estrategia de microservicios

Cloud Native implica un nuevo concepto y estrategia como es la de microservicios, con el objetivo de entrega de software, evitando la lentitud y riesgos de los desarrollos monolíticos. 

Una "arquitectura de microservicio" es un enfoque al desarrollo de aplicaciones software como una serie de pequeños servicios, cada uno de ellos corriendo autónomamente y comunicándose entre sí, por ejemplo, a través de peticiones HTTP a sus APIs - Martin Fowler

Al ser independientes, los microservicios pueden usar diferentes lenguajes o plataformas, ser liderados por equipos distintos y en general ser mucho más agresivos para lanzar nuevas funcionalidades sin afectar las demás. Interactúan entre sí a través de la exposición de API's y mantienen su independencia. Una de las ventajas de usar Microservicios es que adaptan su escala fácilmente a la demanda del sistema, así como generan el embrión de una arquitectura modular global con lo que podemos conseguir interoperabilidad y sinergias entre todos los productos.

Principios y buenas prácticas

  • Principios SOLID - Conceptos de la Ingeniería del Software, SOLID  (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency investment)

  • BBDD distribuidas e independientes. Cada servicio con su BBDD

  • Comunicación simple (API Rest)

  • Versionado por servicio

  • Descubrimiento de servicios

  • OpenApi. APIs documentadas (swagger)

  • Vigilancia, centralización de los archivos de registro

  • Automatización de los test y despliegue (CI / CD)

 

"The Twelve-Factor App" como una metodología para construir aplicaciones nativas en la nube:

  1. Base de código: Usa una base de código, incluso cuando estas construyendo aplicaciones multiplataforma. Añade las especificaciones de cada plataforma con el versionado de control.

  2. Dependencias: Explícitamente declara y aísla todas las dependencias.

  3. Configuración No guardes la configuración como constantes en el código. En vez, diseña la aplicación para que lea la configuración de su entorno.

  4. Servicios de respaldo Trata a los servicios back-end como recursos adjuntos a los que se accede con una URL u otro localizador guardado en la configuración.

  5. Construye, Lanza, Ejecuta Separación estricta de la construcción y ejecución en fases.

  6. Procesos Ejecuta la app como uno o mas procesos sin estado. Los datos que deban de ser persistentes deben de ser guardados en un servicio de respaldo con estado.

  7. Redirección de puertos Usa la redirección de puertos para exportar servicios.

  8. Concurrencia Escala las aplicaciones horizontalmente, no verticalmente.

  9. Disposición Usa rápidos inicios y agraciados apagados para maximizar la robustez.

  10. Paridad Facilita el despliegue continuo asegurándote que los entornos de desarrollo, de pruebas y de producción sean lo mas similares.

  11. Archivos de registro Trata los archivos de registro como eventos continuos. No deberían de preocuparse del enrutado o el guardado de la salida de la aplicación.

  12. Procesos de administrador Ejecuta los tareas del administrador como un proceso de una sola vez desde una máquina en el entorno de producción que esta corriendo el último código de producción.

Beneficios generales

  • Menos acoplamiento, más cohesión

  • Comunicación usando APIs HTTP

  • No afecta otros servicios

  • Mejor control, desarrollando una necesidad de negocio

  • Más manejable e independiente

  • Permite equipos independientes, especializados y geodistribuidos

  • Cambios rápidos

  • Despliegues independientes (lectura, testing, despliegue, retroceso). Riesgos controlados

     

    Optimización de recursos y operaciones y mejora del time to market

Desventajas y Complejidad

Pero ten cuidado, hay una alta posibilidad de fracasar sin tener experiencia o meticulosidad.

  • Debes tener una vista general de todos los microservicios y un orquestador de sistema.

  • La comunicación entre microservicios y administración de posibles fallos en algunos de ellos.

  • Despliegues distribuidos.

  • Transacionabilidad entre microservicios.

  • Configuración distribuida (claves, certificados...)

  • Testing complejo.

Estrategia de migración a una arquitectura de microservicios

Si tienes un producto más tradicional tecnológicamente te recomendamos que leas el siguiente post.