De Monolito a Micro-frontends

Antes de leer este artículo, es importante entender los principios de los Microfrontends y la naturaleza de un monolito.

Esto te ayudará a comprender mejor la transición de la arquitectura Monolítica a la distribuida que discutiremos a continuación.

El diagrama que presentamos muestra algunas de las evoluciones posibles desde una arquitectura monolítica hacia una distribuida.

Monolito:

En un monolito, generalmente usamos un framework integral que abarca tanto el backend como el frontend, facilitando un desarrollo más ágil.

Sin embargo, esta conveniencia inicial podría derivar en complicaciones a medida que el proyecto escala.

Herramientas: Django(Python), .NET(C#), Spring Boot(Java)

Monolito Front & Monolito Back:

A medida que el proyecto crece, adoptamos una arquitectura de capas.

Comenzamos a separar el stack tecnológico de nuestra aplicación, lo que conlleva una mayor especialización y profesionalización de nuestros equipos, pero al mismo tiempo podría generar complicaciones de comunicación y procesos más lentos.

Herramientas: Nuxt, NextJS y SPAs con Vue o React.

Microservicios & Frontend Monolítico.

Con el aumento de la demanda y la diversificación de las necesidades de nuestro negocio, empezamos a desglosar partes del backend en microservicios independientes, marcando el comienzo de nuestra transición hacia una arquitectura distribuida.

Esta segmentación puede mejorar significativamente el rendimiento, aunque exige una mayor disciplina en la organización, adoptando mejores prácticas, fomentando una comunicación efectiva y promoviendo la responsabilidad de los equipos.

Herramientas: Spring Boot (Java), Docker y Kubernetes, Serverless, AWS Lambdas entre otros

Microservicios & Micro-frontends

En esta fase, la cultura organizacional juega un papel crucial, impulsando a los equipos a asumir la responsabilidad integral de segmentos específicos del negocio.

La distinción entre frontend y backend se desvanece, adoptando un enfoque similar al monolítico en cuanto a la responsabilidad del equipo por una área de negocio, pero dentro del contexto de una arquitectura distribuida.

Esta evolución nos facilita escalar, implementar y responder ágilmente a las necesidades de los clientes, minimizando el riesgo en otras áreas y potenciando la especialización de nuestros equipos con un enfoque centrado en el negocio.

Nuevas Herramientas: Single SPA, Module Federation, Bit

Conclusiones

El desarrollo y crecimiento de un producto de software, junto con la evolución de los equipos y la selección de herramientas, es un proceso complejo y lejos de ser lineal.

Esta dinámica refleja la naturaleza viva del software, un organismo en constante cambio impulsado no solo por quienes lo usan y lo mantienen, sino también por el ecosistema tecnológico que lo rodea.

En el campo de la ingeniería de software, se generan debates sobre temas como contenedores vs serverless, arquitecturas monolíticas vs distribuidas, y la eterna pregunta de qué tan 'micro' debería ser un micro-servicio.

Cada uno de estos temas tiene argumentos válidos de ambos lados, reflejando la continua evolución y adaptación en nuestra disciplina.

Sin embargo, es crucial recordar que todas estas tecnologías y enfoques son herramientas diseñadas para servir a un propósito mayor: satisfacer las necesidades de nuestros usuarios.

La elección y aplicación de estas herramientas deben guiarse por el contexto específico y las demandas únicas de nuestros proyectos.

Nos encontramos perpetuamente desarrollando o migrando de una arquitectura a otra, lo que resalta la importancia de ser ágiles y receptivos a los cambios.

Algunas soluciones pueden ser apropiadas para un uso a corto plazo, mientras que otras pueden formar parte de nuestra base tecnológica a largo plazo.

Lo más importante es comprender cada herramienta, decision y enfoque, aplicándolos sabiamente para abordar los desafíos y objetivos específicos de nuestros proyectos en el momento en el que estamos, siempre conscientes de que el software es un ente en constante evolución, moldeado por sus usuarios, sus constructores, y el entorno tecnológico en el que existe.

Referencias

• Florian Rappl article