Desde que Tim Berners-Lee inventó la World Wide Web, casi todos los tipos de servicios físicos se han trasladado a la ecología en la nube. El número de sitios web y aplicaciones web comenzó a crecer exponencialmente, y en la arquitectura de cada aplicación web moderna hay componentes comunes de la computación en la nube que todo desarrollador debe conocer. Los proveedores de servicios en la nube pueden llamar a estos componentes de diferentes maneras, pero su esencia sigue siendo la misma.
He estudiado las arquitecturas de aplicaciones web de varios gigantes tecnológicos modernos (Netflix, Medium y Airbnb) y he destacado los siguientes componentes:
#1. Servidor
Un servidor es un ordenador que proporciona algún servicio (o varios servicios) en una red privada o en Internet. Otros dispositivos, también llamados clientes, pueden conectarse al servidor a través de diferentes puertos para obtener este servicio. Los servidores suelen recibir el nombre del servicio que proporcionan. Por ejemplo, si un servidor acepta solicitudes a través del puerto 80 y entrega páginas web a los clientes, este servidor suele llamarse servidor web. También existen servidores de archivos, servidores de correo, servidores de autenticación, servidores de bases de datos, servidores de aplicaciones, etc.
Actualmente, los servidores virtuales son más populares que los físicos. Los proveedores de servicios en la nube crean máquinas virtuales sobre su hardware físico utilizando hipervisores y software de virtualización. Por ejemplo, algunos proveedores populares utilizan el hipervisor Xen de tipo 1 para crear sus máquinas virtuales.
#2. Cliente
Un cliente es un dispositivo que se conecta a los servidores para utilizar sus servicios o recursos. Un cliente puede ser un ordenador, un sitio web, un software o un sistema integrado. Por ejemplo, cuando accedes a un sitio web, tu navegador se convierte en un cliente. De forma análoga a la denominación de los servidores, los clientes también se denominan en función del servicio que utilizan: existen clientes de correo electrónico, clientes web, clientes de bases de datos o clientes de chat online.
En el modelo cliente-servidor se utilizan métodos como la autenticación para abrir un servicio concreto sólo a clientes específicos. Los clientes pueden ser delgados o gruesos. Un cliente delgado depende completamente del servidor, como una aplicación de una sola página (SPA – Single Page Application). Un cliente grueso, sin embargo, no depende del servidor. Es similar a una aplicación autónoma que guarda los datos en el servidor.
#3. Microservicio
La arquitectura cliente-servidor monolítica no está exenta de inconvenientes. Los fallos en los sistemas monolíticos afectan a todo el sistema, y su mantenimiento es bastante complejo. Con el enfoque de microservicios, los desarrolladores dividen un gran sistema monolítico en pequeños servicios: microservicios. Así se denomina a un servicio aislado y débilmente acoplado que se encarga de algún proceso.
Si estás desarrollando un sistema de gestión de usuarios, los microservicios pueden encargarse del registro de usuarios, la generación de informes y el proceso de pago. En los sistemas web reales, la mayoría de los microservicios son API RESTful que funcionan en una máquina virtual o en un contenedor.
Roy Fielding, científico estadounidense y autor del término REST, propuso seis principios de la arquitectura REST, entre los que se encuentran el modelo cliente-servidor, el almacenamiento en caché, la ausencia de estado y otros.
#4. Función en la nube
Con el aumento de la complejidad del código, los microservicios pueden volverse más pesados y difíciles de mantener. Además, los costes de infraestructura pueden aumentar drásticamente, ya que los microservicios estarán esperando constantemente la conexión de los clientes a las máquinas virtuales o contenedores. El concepto sin servidor (serverless) permite dividir los sistemas grandes en funciones más pequeñas y fáciles de mantener, las llamadas funciones sin servidor o funciones en la nube.
#5. Equilibrador de carga
El equilibrio de carga es la distribución de la carga entre diferentes módulos de computación. En la arquitectura web, un equilibrador de carga es un componente que redirige el tráfico a diferentes servidores en función de su disponibilidad.
Hay dos tipos principales de equilibradores de carga: basados en hardware (HLB – hardware-based load balancer) y basados en software (software-based). Los basados en software son más populares porque los HLB son caros y requieren servidores físicos.
Casi todos los proveedores de servicios en la nube ofrecen equilibradores de carga como servicio (as-a-service).
#6. API Gateway
Una aplicación web puede tener varias API, y cada una debe protegerse de la sobrecarga mediante la limitación de la velocidad de procesamiento de las solicitudes (rate limiting). Un API Gateway proporciona un único punto de acceso para varias API y otros servicios.
Su funcionamiento es similar al de un equilibrador de carga: redirige cada solicitud de cliente a los servicios correspondientes. Un API Gateway suele proporcionarse como parte de una solución de gestión de API (API management solution), que también incluye una interfaz gráfica de usuario (GUI) para gestionar las API desde un panel de administrador seguro.
En los API Gateway se integran servicios de monitorización de API, limitación de la velocidad de procesamiento de las solicitudes, monetización de API y control de versiones. Normalmente, los API Gateway se utilizan con API RESTful, pero pueden admitir los protocolos SOAP, GraphQL, gRPC y TCP.
#7. Cola de mensajes
La arquitectura web moderna se compone de componentes gestionados individualmente: microservicios. Los microservicios utilizan API RESTful o colas de mensajes para interactuar entre sí. Las colas de mensajes organizan un canal de intercambio de mensajes asíncrono entre dos microservicios del tipo «publicador-suscriptor» (pub-sub).
Las colas de mensajes tienen varias ventajas sobre las interfaces RESTful asíncronas. Por ejemplo, si se produce un error durante una solicitud REST, el iniciador de la solicitud (cliente) debe poder manejarlo. Además, un mensaje REST incorrecto simplemente se rechazará y no se guardará en ningún lugar. Sin embargo, las colas de mensajes almacenan todos los mensajes.
Incluso si se envía un mensaje en el momento de un fallo del receptor, éste lo recibirá después de reiniciarse. Por lo tanto, los arquitectos web prefieren las colas de mensajes en los casos en que la fiabilidad de las transacciones es crucial.
#8. CDN
Una red de entrega de contenido (Content Delivery Network, CDN) consta de servidores geográficamente distribuidos que almacenan en caché contenido estático (por ejemplo, imágenes o scripts) para mejorar el rendimiento, la disponibilidad y la seguridad de las aplicaciones web.
Una aplicación web típica suele tener imágenes, vídeos, estilos y archivos JavaScript. Cada vez que un usuario accede a tu aplicación, su navegador descarga estos recursos del servidor. Si el usuario vive lejos de la ubicación física del servidor, la página tardará mucho en cargarse. La CDN almacena en caché el contenido estático en numerosos servidores de todo el mundo y lo entrega rápidamente a los clientes geográficamente más cercanos.
Además, la CDN puede mitigar los daños de los ataques DDoS, ya que los servidores de almacenamiento en caché de la CDN actúan como proxy para tu servidor original.
En este tipo de ataque, la CDN se convierte en una barrera adicional, protegiendo los ordenadores objetivo del impacto directo de los atacantes.
#9. Base de datos
Una base de datos es un componente que almacena información de varios tipos. Existen diferentes tipos de bases de datos: SQL, en la nube, clave-valor, gráficas e jerárquicas (documentadas). Los servidores de bases de datos permiten a los clientes interactuar con las bases de datos mediante protocolos especiales. Por ejemplo, el servidor de bases de datos MySQL utiliza el protocolo MySQL.
Los arquitectos web eligen el tipo de base de datos en función de las necesidades reales. Por ejemplo, si necesitas almacenar muchas sesiones de usuario con identificadores únicos, una buena opción sería una base de datos de tipo clave-valor.
#10. Servicios
Las aplicaciones web necesitan autenticación, intercambio de correos electrónicos, registro, monitorización, aprendizaje automático, sistema de pagos y otros servicios. Además, necesitan servicios relacionados con el desarrollo, el diseño y la implementación, como el alojamiento de repositorios, la integración/entrega continua (CI/CD), la base de datos, el alojamiento de aplicaciones, la búsqueda/indexación, etc. Los requisitos clave para estos servicios se pueden implementar utilizando muchos frameworks de código abierto. Pero aún así se necesitará infraestructura para instalar y utilizar estos servicios.
Muchas empresas y startups que trabajan con el modelo «como servicio» (as-a-service) proporcionan casi todos estos servicios en la nube para el desarrollo web. Además, algunas grandes empresas tecnológicas han creado sus propios ecosistemas de desarrollo, en los que han integrado numerosos servicios en la nube.
