Servidores, sistemas operativos, máquinas virtuales, contenedores y servicios en la nube

Un servidor es simplemente una computadora que sirve

Un servidor es una computadora cuya tarea es esperar solicitudes y responderlas: páginas web, llamadas a una API, consultas a una base de datos, archivos. La palabra describe una función, no un tipo especial de máquina. Una computadora portátil que ejecuta una pequeña aplicación web es un servidor mientras responde solicitudes; una máquina montada en un rack de un centro de datos es un servidor porque no hace otra cosa. La misma palabra se usa también para el programa que sirve (un "servidor web" como nginx), así que el contexto importa.

El hardware de un servidor tiene las mismas piezas que cualquier computadora (consulta qué es el software): procesadores, memoria, almacenamiento y tarjetas de red. Lo que cambia es el énfasis. Los servidores suelen tener muchos núcleos de procesador, grandes cantidades de memoria, fuentes de alimentación y discos redundantes para que una pieza averiada no detenga la máquina, administración remota para que nadie tenga que estar en la sala, y ninguna pantalla ni teclado. Están hechos para funcionar durante años sin apagarse.

La mayoría de los servidores de internet ejecutan Linux u otro sistema operativo tipo Unix; Windows Server es habitual en organizaciones que dependen de productos de Microsoft. Un sistema operativo de servidor hace las mismas tareas que el de tu computadora portátil (ejecutar procesos, gestionar la memoria y los archivos, comunicarse con la red), pero normalmente se administra mediante una línea de comandos de texto a través de una conexión remota, y se configura para poder reconstruirlo automáticamente en lugar de a mano.

Centros de datos: donde viven los servidores

Los servidores se guardan en un centro de datos: un edificio diseñado en torno a sus necesidades. Miles de máquinas se alojan en racks, refrigeradas por aire o por líquido, porque convierten casi toda su electricidad en calor. La energía llega por más de un suministro, respaldada por baterías durante los primeros segundos de un corte y después por generadores diésel. Las conexiones de red provienen de varios proveedores. Las puertas exigen tarjeta de acceso y, a menudo, huella dactilar.

Una organización puede tener su propio centro de datos o alquilar espacio en racks en el de otra (lo que se llama colocation), y antes de 2006, aproximadamente, esa era casi la única opción. Gestionar tus propios servidores (on-premises, en instalaciones propias) significa comprar máquinas meses antes de necesitarlas, adivinar cuántas, pagarlas tanto si están ocupadas como si están inactivas, y emplear a personas que cambien discos averiados de noche. Ese costo y esa rigidez son el problema que la nube se propuso resolver.

Máquinas virtuales: muchas computadoras dentro de una

Un servidor típico pasa la mayor parte del tiempo inactivo si ejecuta una sola aplicación. Una máquina virtual (VM) permite que una máquina física se haga pasar por varias. Cada VM cree que es una computadora completa con sus propios procesadores, memoria, disco y tarjeta de red, y ejecuta su propio sistema operativo, llamado huésped. Una capa de software llamada hipervisor reparte el hardware real entre las VM y las mantiene separadas, de modo que un fallo o un ataque en una no llegue a las demás. Algunos hipervisores se ejecutan directamente sobre el hardware (VMware ESXi, Microsoft Hyper-V, KVM, que forma parte de Linux); otros se ejecutan como una aplicación sobre un sistema operativo normal (VirtualBox).

La virtualización cambió la economía de los servidores. Una sola máquina puede llenarse de VM de distintos equipos o clientes. Una VM es un conjunto de archivos, así que se puede copiar, respaldar, trasladar a otra máquina y crear en minutos, en lugar de pedirla y esperar a que llegue. Ten en cuenta que este es un uso de "máquina virtual" distinto del de las VM de lenguaje, como la Java Virtual Machine mencionada en qué es el software: aquellas ejecutan programas; estas imitan computadoras completas.

Contenedores: enviar la aplicación con todo lo que necesita

Todo desarrollador ha oído "en mi máquina funciona". El programa depende de una versión concreta del lenguaje, de bibliotecas concretas y de una configuración concreta, y el servidor tiene otras ligeramente distintas. Un contenedor resuelve esto empaquetando una aplicación junto con todo lo que necesita para ejecutarse (su runtime, sus bibliotecas, su configuración) en una unidad estándar que funciona igual en una computadora portátil, en un servidor de pruebas o en la nube. El nombre viene de los contenedores de transporte: cajas estándar que cualquier grúa, barco o camión puede manejar sin saber qué hay dentro.

El paquete es una imagen de contenedor: un archivo de solo lectura y con versión, construido a partir de una receta breve (con Docker, un Dockerfile). Una copia en ejecución de una imagen es un contenedor. Docker, lanzado en 2013, hizo esto práctico para los desarrolladores del día a día, y su formato de imagen es hoy un estándar abierto mantenido por la Open Container Initiative, de modo que otras herramientas pueden construir y ejecutar las mismas imágenes.

La diferencia clave con una VM es qué se comparte. Una VM imita el hardware y ejecuta un sistema operativo huésped completo. Un contenedor es un proceso aislado: comparte con otros contenedores el kernel del sistema operativo anfitrión (el núcleo del sistema operativo, que controla el hardware, la memoria y los procesos), y las funciones de aislamiento del kernel le dan su propia vista de los archivos, los procesos y la red. Por eso los contenedores arrancan en segundos o menos y ocupan megabytes en lugar de gigabytes, así que pueden ejecutarse docenas donde cabrían unas pocas VM. El precio es un aislamiento más débil, porque todos los contenedores dependen del único kernel compartido; por eso los proveedores de nube suelen ejecutar los contenedores de sus clientes dentro de VM, combinando ambos.

# Start from an image that already has Python installed
FROM python:3.12-slim
WORKDIR /app
# Bake the libraries into the image
COPY requirements.txt .
RUN pip install -r requirements.txt
# Add the application code
COPY . .
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Ejecutar un contenedor es fácil. Ejecutar cientos en docenas de máquinas, reiniciar los que fallan, añadir copias cuando sube el tráfico y desplegar nuevas versiones sin tiempo de inactividad no lo es. Esa tarea la hace un orquestador, del que Kubernetes es el más conocido; se trata en contenedores y orquestación.

La nube: alquilar capacidad de cómputo por minutos

La computación en la nube consiste en alquilar recursos de cómputo a través de internet, bajo demanda, a un proveedor que gestiona enormes centros de datos: Amazon Web Services (AWS), Microsoft Azure y Google Cloud son los más grandes, entre muchos otros. El Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST) publicó en 2011 la definición que más se cita, la Special Publication 800-145. En ella enumera cinco características esenciales: autoservicio bajo demanda (creas los recursos tú mismo, desde un sitio web o una API, sin llamar a nadie), amplio acceso por red, agrupación de recursos (muchos clientes comparten el hardware del proveedor), elasticidad rápida (la capacidad crece y se reduce con rapidez) y servicio medido (pagas por lo que usas).

La analogía es la electricidad. Antes las fábricas tenían sus propios generadores; ahora se conectan a la red y pagan por kilovatio-hora. Con la nube, una startup puede alquilar cien servidores durante una tarde para probar un lanzamiento y dejar de pagar cuando los devuelve. Eso es el precio de pago por uso (pay-as-you-go). Convierte una gran compra inicial en un costo continuo, y premia los sistemas que pueden apagar capacidad cuando no se necesita. También crea un riesgo nuevo: costos que crecen sin que nadie lo note, porque nada impide que cualquiera cree recursos y se olvide de ellos.

IaaS, PaaS, SaaS y serverless: ¿cuánto gestionas tú?

Los servicios en la nube se diferencian sobre todo en cuánta parte de la pila gestiona el proveedor por ti. El NIST definió tres modelos de servicio; un cuarto, serverless, se popularizó después de que AWS lanzara su servicio Lambda en 2014. Una forma popular de recordarlos es la pizza: puedes hacerla en casa, comprar una lista para hornear, pedirla a domicilio o comer fuera. Cada paso delega más trabajo en otra persona y te quita algunas opciones.

"Serverless" no significa que no haya servidores; significa que nunca los ves ni los gestionas. Subes una función, indicas qué eventos la activan (una solicitud HTTP, la llegada de un archivo, un mensaje en una cola) y el proveedor ejecuta tantas copias como hagan falta y cobra por ejecución y por milisegundo. Es barato para tráfico irregular o bajo y casi no requiere trabajo de operaciones. Sus costos aparecen en otros sitios: la primera llamada tras un periodo tranquilo puede ser lenta mientras el proveedor inicia la función (un arranque en frío), hay límites sobre cuánto tiempo puede ejecutarse una función, y con tráfico intenso y constante los costos pueden superar los de un servidor normal. El Capítulo 6 analiza a fondo las arquitecturas serverless.

Entre estos modelos se sitúan los servicios gestionados: bases de datos, colas de mensajes, cachés, almacenamiento de objetos, motores de búsqueda y muchos más, que el proveedor instala, ejecuta, parchea, respalda y escala. Usar una base de datos gestionada en lugar de instalar una en una VM traslada al proveedor una gran cantidad de trabajo operativo. El compromiso, que se analiza en FinOps y dependencia del proveedor, es que cuantos más servicios específicos de un proveedor usa un sistema, más difícil es trasladarlo.

Regiones, zonas de disponibilidad y redes de distribución de contenidos

Los proveedores de nube agrupan sus centros de datos por geografía. Una región es un área geográfica (como Irlanda, Fráncfort o Virginia) con su propio conjunto de centros de datos, aislado de otras regiones. Cada región se divide en varias zonas de disponibilidad: grupos físicamente separados de uno o más centros de datos, cada uno con energía, refrigeración y red independientes, normalmente a kilómetros de distancia entre sí, pero lo bastante cerca para tener conexiones rápidas. Un incendio, una inundación o un corte de energía debería afectar como máximo a una zona.

Esto da a los arquitectos un menú de protección. Ejecutar copias de una aplicación en dos o tres zonas de una región permite sobrevivir a la pérdida de un centro de datos con poca latencia adicional; ejecutarla en dos regiones permite sobrevivir a la pérdida de una región entera, pero hace mucho más difícil mantener los datos sincronizados. Las regiones también importan por la ley y por la latencia: las normas de protección de datos pueden exigir que los datos personales permanezcan en una jurisdicción concreta, y los usuarios reciben un servicio más rápido desde una región cercana, porque ninguna red puede superar la velocidad de la luz (consulta cómo se comunican las computadoras).

Una red de distribución de contenidos (CDN) lleva esto más lejos para el contenido que no cambia según el usuario, como imágenes, hojas de estilo, scripts y video. Guarda copias en servidores de cientos de ubicaciones, llamadas ubicaciones en el borde (edge locations), para que un usuario de Nairobi obtenga las fotos de productos de la tienda desde una ciudad cercana y no desde un centro de datos en Europa. La página carga más rápido y los servidores propios de la tienda atienden muchas menos solicitudes. Muchas CDN también absorben el tráfico de ataques y pueden ejecutar pequeños fragmentos de código en el borde.

Escalado vertical y escalado horizontal

Cuando un sistema necesita manejar más trabajo, hay dos movimientos básicos. El escalado vertical (scaling up) significa una máquina más grande: más núcleos, más memoria. No requiere cambiar el software, que es su gran ventaja, pero hay una máquina más grande que se puede comprar, se vuelve desproporcionadamente cara cerca del límite y una sola máquina sigue siendo un único punto de fallo. El escalado horizontal (scaling out) significa más máquinas que se reparten el trabajo, normalmente detrás de un balanceador de carga que distribuye las solicitudes entre ellas y deja de enviar a las que fallan. Puede crecer mucho más y sobrevivir a fallos de máquinas, pero solo si el software está diseñado para ello: por ejemplo, un servidor no debe guardar la sesión de un usuario solo en su propia memoria, ni guardar los archivos subidos solo en su propio disco, si la siguiente solicitud del usuario puede ir a otro servidor.

La nube hace atractivo el escalado horizontal porque añadir una máquina es una llamada a una API, y el autoescalado puede añadir y quitar copias automáticamente según cambia la carga. Las bases de datos suelen ser la parte más difícil de escalar horizontalmente, y por eso el Capítulo 7 dedica una sección a la replicación y el particionamiento.

Por qué esto importa para la arquitectura

Dónde se ejecuta el software es hoy una decisión arquitectónica, no algo que se piensa al final. La elección entre VM, contenedores, plataformas y funciones determina el costo, la rapidez con la que el equipo puede lanzar versiones, cómo escala el sistema y qué pasa cuando falla un centro de datos. Las regiones y las zonas convierten los objetivos de disponibilidad en planes de despliegue concretos; los servicios gestionados cambian trabajo operativo por dependencia de un proveedor. El Capítulo 9 desarrolla las estrategias de escalado, y el Capítulo 10 trata los modelos de servicio y de despliegue en la nube, los contenedores y la infraestructura con profundidad profesional.