¡Seguimos con la saga! Si en la primera parte aprendimos a construir búnkeres y lasañas, prepárate, porque ahora la cosa se pone «futurista». Vamos a entrar en el terreno de las arquitecturas que parecen sacadas de una película de ciencia ficción: desde funciones que aparecen y desaparecen en el aire hasta núcleos protegidos por escudos hexagonales.
¿Alguna vez has deseado tener una varita mágica para que tu código solo existiera cuando alguien lo necesita y dejara de cobrarte el resto del tiempo? ¿O has soñado con un sistema donde pudieras cambiar la base de datos como quien cambia un neumático pinchado, sin tocar el motor? Bienvenido al mundo de las arquitecturas modernas, donde intentamos que el software sea tan flexible que parezca líquido, pero tan sólido que no se rompa al mirarlo.
Introducción
En esta segunda mitad de la tabla, nos jugamos la eficiencia extrema. Aquí es donde decides:
- Costes: ¿Pagas por un servidor encendido 24/7 o solo por los milisegundos que usas?
- Independencia: ¿Tu lógica de negocio está «casada» con SQL Server o es libre de irse con cualquiera?
- Extensibilidad: ¿Puedes añadir funciones nuevas sin abrir el código principal?
Manos a la Obra
Cerramos el círculo con los últimos 6 estilos de nuestra infografía.
Serverless: El Código Fantasma
Aquí no hay servidores que cuidar (bueno, sí los hay, pero son problema de otro). Son funciones independientes que se ejecutan en la nube bajo demanda.
- Pros: Solo pagas por lo que ejecutas; escalabilidad infinita automática.
- Contras: El «arranque en frío» (latencia inicial) y la pérdida de control total sobre el entorno.
- Ejemplo de la vida real: Un proceso que redimensiona una imagen cada vez que un usuario la sube a tu app.
Microkernel: El Sistema Operativo Personalizado
Tienes un núcleo central mínimo (Kernel) y usas «Plugins» para añadir todo lo demás.
- Pros: Muy flexible y extensible; el núcleo se mantiene limpio y estable.
- Contras: La comunicación entre el núcleo y los plugins puede volverse compleja.
- Ejemplo de la vida real: VS Code. El editor es el núcleo; los lenguajes y temas son los plugins.
Hexagonal (Puertos y Adaptadores): El Búnker Blindado
El dominio (tu lógica de negocio) está en el centro, protegido. Se comunica con el mundo exterior (Base de datos, UI, APIs) a través de adaptadores.
- Pros: Tu código es agnóstico a la tecnología; puedes testear la lógica sin base de datos.
- Contras: Mucho código adicional (boilerplate) para conectar todo.
- Ejemplo de la vida real: Un sistema de pagos que puede cambiar de Stripe a PayPal simplemente cambiando el adaptador.
Peer-to-Peer (P2P): La Democracia Total
No hay un jefe. Todos los nodos están conectados y comparten recursos directamente entre sí.
- Pros: No hay un punto único de fallo; es extremadamente difícil de tumbar.
- Contras: La seguridad y la consistencia de los datos son un dolor de cabeza constante.
- Ejemplo de la vida real: BitTorrent o la red de nodos de una Blockchain.
Basada en Componentes: El Juego de Lego
El sistema se forma ensamblando bloques modulares reutilizables que encajan perfectamente entre sí.
- Pros: Alta reutilización; puedes mejorar un componente sin afectar al resto si la interfaz es la misma.
- Contras: Si los componentes no están bien definidos, terminas con un rompecabezas que no encaja.
- Ejemplo de la vida real: Desarrollo frontend moderno con React o Angular.
Broker / Pipeline: La Línea de Ensamblaje
Los datos fluyen secuencialmente a través de intermediarios (Procesadores) que transforman la información paso a paso.
- Pros: Ideal para procesar grandes volúmenes de datos de forma ordenada.
- Contras: Si un eslabón de la cadena es lento, frena todo el proceso.
- Ejemplo de la vida real: Un sistema de análisis de datos que limpia, filtra y luego guarda logs.
Notas
Si quieres que tu código sobreviva al paso de los años, dale una oportunidad a la Arquitectura Hexagonal. Sí, escribirás más clases al principio, pero el día que tu jefe diga «Cambiemos Oracle por PostgreSQL para ahorrar costes», serás el único que no estará llorando en el baño. Por otro lado, usa Serverless solo para tareas puntuales; si montas toda tu lógica ahí, tu factura de la nube podría darte un susto de muerte.
Conclusión
Al final, la arquitectura es como un equipo de fútbol: puedes tener a los mejores jugadores (los lenguajes de programación), pero si no tienes una estrategia (arquitectura), cualquiera te mete un gol por la escuadra (un bug en producción).
Reto: Imagina que tienes que construir una app que detecte alienígenas. ¿Usarías Serverless para que solo se active cuando aparezca un OVNI o un Monolito para estar siempre vigilando?
