Arquitectura de sistemas de información: servidores, virtualización, contenedores, microservicios y serverless
La arquitectura de un sistema de información define cómo se organizan sus componentes para procesar, almacenar y servir información con el rendimiento, la disponibilidad y la seguridad necesarios. En una aplicación empresarial suelen existir capas de presentación, lógica de negocio y datos, pero su despliegue ha evolucionado desde servidores físicos dedicados hacia máquinas virtuales, contenedores, microservicios y plataformas serverless.
Conviene distinguir entre arquitectura lógica, que reparte responsabilidades entre componentes, y arquitectura de despliegue, que determina dónde se ejecutan. En este artículo de Tecnoic sobre diseño arquitectónico y diagramas de despliegue se explica esa diferencia con más detalle.
Servidores de datos y servidores de aplicaciones
En una arquitectura de tres capas, el servidor de aplicaciones ejecuta la lógica de negocio y actúa como intermediario entre clientes y datos. Puede gestionar autenticación, sesiones, reglas de negocio, APIs, transacciones e integración con otros sistemas.
El servidor de datos se especializa en persistencia: bases de datos, sistemas de ficheros, motores de búsqueda u otros repositorios. En un SGBD entran además funciones como control de acceso, transacciones, índices, concurrencia, copias de seguridad y recuperación. Tecnoic dispone de una guía sobre SGBD y arquitectura de bases de datos.
Esta separación es lógica, no necesariamente física. Ambas funciones pueden ejecutarse en máquinas distintas, en varias VM sobre el mismo host o consumirse como servicios gestionados en la nube.
Virtualización de servidores: varias máquinas sobre el mismo hardware
La virtualización de servidores utiliza un hipervisor para ejecutar varias máquinas virtuales (VM) independientes sobre un servidor físico. Cada VM dispone de CPU virtual, memoria, almacenamiento, red y su propio sistema operativo invitado.
Los hipervisores de tipo 1 o bare metal se ejecutan directamente sobre el hardware y son habituales en centros de datos. Los de tipo 2 funcionan sobre un sistema operativo anfitrión y se utilizan sobre todo en escritorio, desarrollo y pruebas.
La virtualización permite consolidar cargas, mejorar el aprovechamiento del hardware y simplificar el aprovisionamiento, las plantillas, las instantáneas y la recuperación. Su contrapartida es que cada VM mantiene un sistema operativo completo y, por tanto, consume más recursos que un contenedor.
Virtualización del sistema operativo y contenedores
Los contenedores aplican la virtualización a nivel de sistema operativo. En lugar de emular una máquina completa, aíslan procesos que comparten el kernel del anfitrión. En Linux, este aislamiento se apoya en namespaces y cgroups, que separan recursos y limitan consumos de CPU o memoria. Docker describe precisamente los contenedores como procesos aislados que aprovechan estos mecanismos del kernel.
Por ello suelen arrancar con rapidez y ofrecer mayor densidad que las VM. Además, una imagen empaqueta la aplicación con sus dependencias, facilitando reproducir el entorno entre desarrollo, pruebas y producción.
No son, sin embargo, sustitutos exactos de una VM. Esta permite ejecutar kernels diferentes y ofrece una frontera de aislamiento distinta. En contenedores, los datos persistentes deben mantenerse en volúmenes o almacenamiento externo, no en la capa efímera de la imagen.
Cuando el número de contenedores crece, entra en juego la orquestación. Kubernetes automatiza el despliegue, escalado y gestión de aplicaciones contenerizadas; su unidad desplegable mínima es el Pod, que puede agrupar uno o varios contenedores.
Microservicios: arquitectura, no virtualización
Un error frecuente es confundir contenedores y microservicios. Un microservicio es una decisión de diseño: la aplicación se divide en servicios pequeños, débilmente acoplados y desplegables de forma independiente, normalmente comunicados mediante APIs o mensajería.
Los contenedores encajan bien con este modelo, pero no son obligatorios. Un microservicio puede ejecutarse en una VM, y una aplicación monolítica puede desplegarse dentro de un contenedor.
La ventaja es que cada componente puede evolucionar y escalar por separado. El coste aparece en la complejidad distribuida: comunicaciones de red, descubrimiento de servicios, observabilidad, consistencia de datos, tolerancia a fallos y gestión de versiones. Por eso un monolito bien diseñado puede ser más adecuado para aplicaciones pequeñas o equipos reducidos.
Serverless: infraestructura abstraída
Serverless no significa que no existan servidores, sino que el desarrollador deja de aprovisionarlos y administrarlos directamente. La plataforma se ocupa de asignar recursos, escalar y operar buena parte de la infraestructura.
El caso más conocido es FaaS (Function as a Service): funciones que se ejecutan ante eventos como una petición HTTP, la llegada de un mensaje o la subida de un fichero. La CNCF distingue FaaS de serverless: este último es un concepto más amplio que también puede abarcar bases de datos, colas y otros servicios gestionados.
Serverless encaja especialmente bien con cargas variables, procesos orientados a eventos, APIs ligeras y automatizaciones. A cambio, puede introducir límites de ejecución, dependencia del proveedor, latencias de arranque y menor control operativo.
En este artículo de Tecnoic tenéis disponible una guía específica sobre IaaS, PaaS, SaaS y tipos de nube, útil para situar estos modelos dentro del cloud computing.
¿Qué modelo conviene elegir?
No existe una opción universalmente mejor. Las VM encajan con software legado, requisitos de aislamiento o cargas que necesitan controlar el sistema operativo. Los contenedores destacan por portabilidad, rapidez y densidad. Los microservicios tienen sentido cuando aplicación y organización necesitan escalar componentes independientemente. Serverless reduce la gestión de infraestructura en cargas compatibles con un modelo gestionado y orientado a eventos.
En sistemas reales es habitual combinarlos: aplicaciones heredadas en VM, servicios nuevos en Kubernetes, bases de datos gestionadas y funciones serverless para procesos puntuales. La arquitectura adecuada es la que equilibra control, coste, escalabilidad, seguridad y complejidad operativa.
Conclusión
La evolución desde el servidor físico hasta serverless no elimina las capas anteriores: las abstrae. Las VM virtualizan hardware; los contenedores aíslan procesos sobre un kernel compartido; los microservicios reorganizan la aplicación; y serverless oculta buena parte de la infraestructura.
La cuestión clave es qué problema resuelve cada enfoque. ¿En tu entorno predominan todavía las máquinas virtuales o ya estáis trasladando cargas a contenedores y serverless?
