Capítulo 5: Servidores Web — Dónde viven realmente las páginas de Internet¶

Objetivos del capítulo¶

Al finalizar este capítulo serás capaz de:

Explicar con claridad qué es un servidor web, cómo funciona internamente y qué ocurre desde que un usuario escribe una URL hasta que ve la página en pantalla.
Comparar y elegir entre los principales servidores web (Nginx, Apache, LiteSpeed, Caddy, IIS) según las necesidades de cada proyecto.
Distinguir los tipos de hosting —compartido, VPS, dedicado, cloud, serverless, edge— y tomar decisiones informadas sobre cuál usar en cada contexto.
Evaluar las plataformas modernas de hosting estático y JAMstack (GitHub Pages, Cloudflare Pages, Netlify, Vercel, Firebase Hosting) con sus precios reales en 2026.
Comprender las arquitecturas web modernas: sitio estático, SPA, SSR, SSG, JAMstack, microservicios y edge computing.
Diseñar la infraestructura básica de un proyecto real, justificando decisiones técnicas y comparando costos con datos actuales del mercado.

Introducción¶

Imagina que Internet es una ciudad gigantesca y tú quieres abrir un restaurante. El nombre de tu restaurante —el letrero en la puerta— es el dominio (como elprofe.org). La guía de teléfonos que le dice a la gente cómo llegar es el DNS. Pero el restaurante en sí, el edificio físico donde están los cocineros, la cocina, los ingredientes y las mesas, eso es el servidor web. Sin ese edificio, el letrero y la guía de teléfonos no sirven de nada: no hay dónde servir la comida.

En el capítulo anterior aprendiste cómo funciona el DNS: ese sistema invisible que convierte nombres amigables como elprofe.org en direcciones IP numéricas que las máquinas entienden. Pero una vez que el navegador sabe a qué IP dirigirse, ¿qué ocurre exactamente? ¿Quién responde? ¿Qué procesa la petición? ¿Dónde viven los archivos HTML, las imágenes y los videos? La respuesta a todo eso es el servidor web, y entenderlo a fondo te convertirá en un desarrollador o emprendedor tecnológico con criterio real para tomar decisiones de infraestructura.

Este capítulo es, en muchos sentidos, el corazón del libro. Todo lo demás —dominios, DNS, HTTPS, CDN— gira alrededor del servidor. Aquí aprenderás desde los fundamentos físicos del hardware hasta las arquitecturas más modernas como edge computing, pasando por los tipos de hosting, los servidores más populares del mundo y cómo elegir la plataforma correcta para cada proyecto. Ya sea que estés construyendo elprofe.org, una tienda online, una API para credenciales digitales o el sitio de la primaria del barrio, este capítulo tiene la respuesta.

Prepárate para un viaje que va desde los cables físicos en los centros de datos hasta las funciones serverless que corren en cientos de ciudades al mismo tiempo. Al final, podrás mirar cualquier sitio web y entender, con precisión técnica, dónde y cómo vive realmente en Internet.

5.1 ¿Qué es un servidor?¶

La definición que sí tiene sentido¶

Un servidor es, en esencia, una computadora que espera peticiones y las responde. Nada más. Nada menos. Pero esa definición tan sencilla esconde una cantidad enorme de matices que vale la pena explorar.

Piénsalo como un cajero automático: está ahí, disponible las 24 horas, esperando que alguien llegue y haga una petición (retirar dinero, consultar saldo). Cuando llega una petición, la procesa y devuelve una respuesta. El cajero no va a buscarte a tu casa; espera a que tú vayas a él. Exactamente así funciona un servidor: espera peticiones, las procesa y responde.

Cliente y servidor: el modelo fundamental de Internet¶

Internet funciona sobre un modelo llamado cliente-servidor. El cliente es quien inicia la conversación: tu navegador, tu app móvil, un script de Python. El servidor es quien responde: la máquina que tiene los archivos, la lógica y los datos.

┌─────────────────────────────────────────────────────────┐
│                MODELO CLIENTE-SERVIDOR                  │
├─────────────────┬─────────────────┬────────────────────┤
│     CLIENTE     │    INTERNET     │      SERVIDOR      │
│                 │                 │                    │
│  Tu navegador   │  ─── petición──▶│  elprofe.org       │
│  (Chrome/FF)    │                 │  (IP 104.21.x.x)   │
│                 │  ◀── respuesta──│                    │
│  Muestra HTML   │                 │  Envía HTML/CSS/JS │
└─────────────────┴─────────────────┴────────────────────┘

Este modelo es asimétrico: hay muchos más clientes que servidores. Cuando miles de estudiantes acceden a elprofe.org al mismo tiempo, todos ellos son clientes haciendo peticiones al mismo servidor.

Servidor físico vs. servidor lógico¶

Aquí hay una distinción crucial que confunde a muchos principiantes:

Servidor físico: una máquina real con hardware concreto: CPU, RAM, discos, cables. Está en algún centro de datos en algún lugar del mundo.
Servidor lógico (o proceso servidor): un programa que corre en esa máquina y escucha peticiones. Nginx, Apache, Node.js son servidores lógicos.

En una misma máquina física pueden correr decenas o cientos de servidores lógicos. Un solo rack en un centro de datos puede alojar miles de sitios web. Esta distinción es fundamental para entender la virtualización que veremos más adelante.

Los cuatro grandes tipos de servidor (por dónde corren)¶

┌──────────────────────────────────────────────────────────────────┐
│                    TIPOS DE SERVIDOR                             │
├──────────────┬──────────────┬──────────────┬────────────────────┤
│  DEDICADO    │     VPS      │  COMPARTIDO  │       NUBE         │
│              │              │              │                    │
│  Máquina     │  Máquina     │  Máquina     │  Máquinas          │
│  física      │  virtual     │  física      │  virtuales         │
│  entera      │  propia      │  compartida  │  elásticas         │
│              │              │              │                    │
│  Control:    │  Control:    │  Control:    │  Control:          │
│  Total       │  Alto        │  Bajo        │  Variable          │
│              │              │              │                    │
│  $80-300/mes │  $5-40/mes   │  $3-15/mes   │  $10-200+/mes      │
└──────────────┴──────────────┴──────────────┴────────────────────┘

Cada tipo tiene su lugar. Un blog personal funciona perfectamente en hosting compartido por $3/mes. Una plataforma educativa con 10,000 usuarios necesita algo más robusto. Una empresa de comercio electrónico con tráfico variable debería estar en la nube. A lo largo de este capítulo exploraremos cada uno en detalle.

5.2 Cómo funciona un servidor web: el flujo completo¶

El viaje de una petición¶

Cuando escribes https://elprofe.org/cursos en tu navegador y presionas Enter, ocurre una secuencia de eventos que dura apenas milisegundos pero que involucra decenas de sistemas cooperando en perfecta sincronía. Vamos paso a paso.

Paso 1 — Resolución DNS: Tu navegador pregunta al sistema DNS (capítulo 4): "¿Cuál es la IP de elprofe.org?" El DNS responde: "104.21.x.x". (Si ya visitaste el sitio recientemente, tu navegador tiene esta información en caché y se saltará este paso.)

Paso 2 — Conexión TCP: Tu navegador establece una conexión TCP con esa IP en el puerto 443 (HTTPS). Es como marcar un número de teléfono y esperar que contesten.

Paso 3 — Handshake TLS: Antes de enviar datos sensibles, navegador y servidor negocian un canal cifrado. Esto es el TLS, el tema del capítulo 6. Dura pocos milisegundos.

Paso 4 — Petición HTTP: Tu navegador envía la petición: GET /cursos HTTP/2. Incluye cabeceras con información sobre tu navegador, idioma preferido, cookies, etc.

Paso 5 — El servidor web recibe y procesa: Nginx (o Apache, o Caddy) recibe la petición. Puede servir un archivo estático directamente (HTML, imagen) o pasar la petición a una aplicación (Node.js, PHP, Python).

Paso 6 — La aplicación procesa: Si es una página dinámica, la aplicación consulta la base de datos, procesa la lógica de negocio y genera el HTML.

Paso 7 — Respuesta HTTP: El servidor envía de vuelta: HTTP/2 200 OK seguido del HTML, CSS, JavaScript y recursos.

Paso 8 — El navegador renderiza: Tu navegador interpreta el HTML, descarga los recursos adicionales y pinta la página en pantalla.

┌─────────────────────────────────────────────────────────────────────┐
│              FLUJO COMPLETO DE UNA PETICIÓN WEB                     │
│                                                                     │
│  USUARIO                                                            │
│    │                                                                │
│    │ 1. Escribe elprofe.org/cursos                                  │
│    ▼                                                                │
│  ┌──────────┐    2. ¿IP de        ┌────────────┐                   │
│  │Navegador │────elprofe.org?─────▶│  DNS       │                  │
│  │(Chrome)  │◀───104.21.x.x───────│  (Cap. 4)  │                  │
│  └────┬─────┘                     └────────────┘                   │
│       │                                                             │
│       │ 3. Conexión TCP + TLS (Cap. 6)                             │
│       │                                                             │
│       ▼                                                             │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    SERVIDOR (104.21.x.x)                    │   │
│  │                                                             │   │
│  │  ┌──────────────┐    ┌──────────────┐    ┌──────────────┐  │   │
│  │  │  Servidor    │───▶│  Aplicación  │───▶│  Base de     │  │   │
│  │  │  Web (Nginx) │    │  (Node.js/   │    │  Datos       │  │   │
│  │  │              │◀───│  PHP/Python) │◀───│  (MySQL/     │  │   │
│  │  └──────────────┘    └──────────────┘    │  Firestore)  │  │   │
│  │         │                                └──────────────┘  │   │
│  └─────────┼───────────────────────────────────────────────────┘   │
│            │                                                        │
│            │ 4. Respuesta HTTP (HTML + CSS + JS)                   │
│            ▼                                                        │
│  ┌──────────┐                                                       │
│  │Navegador │ 5. Renderiza la página                               │
│  │(Chrome)  │                                                       │
│  └──────────┘                                                       │
└─────────────────────────────────────────────────────────────────────┘

Este flujo conecta directamente con lo que aprendiste sobre DNS en el capítulo 4. El servidor web es el destino final de ese viaje DNS.

5.3 Hardware de un servidor¶

CPU: el cerebro que procesa las peticiones¶

La CPU de un servidor no es como la de tu laptop. Mientras que en casa puede bastarte con un procesador de 4 núcleos para navegar y editar documentos, un servidor que atiende miles de peticiones simultáneas necesita muchos más núcleos y una arquitectura optimizada para multitarea.

Núcleos y concurrencia: Cada núcleo puede procesar una instrucción al mismo tiempo. Un servidor con 8 núcleos puede, teóricamente, manejar 8 operaciones en paralelo. Los servidores modernos de alta gama tienen 64, 96 o incluso 128 núcleos físicos. Para elprofe.org, un VPS con 2-4 vCPUs es más que suficiente en sus inicios.

Frecuencia: Se mide en GHz. Mayor frecuencia = cada instrucción se ejecuta más rápido. Para bases de datos con muchos cálculos, la frecuencia importa. Para servidores web de alto tráfico, los núcleos importan más.

RAM: la memoria de trabajo¶

La diferencia entre tener 512 MB, 4 GB o 32 GB de RAM en un servidor es enorme:

512 MB: Suficiente para un blog estático con muy poco tráfico. Apenas aguanta un servidor Nginx básico y poco más. En 2026 es prácticamente obsoleto para producción seria.
4 GB: El punto de entrada real. Permite correr Nginx + Node.js/PHP + una base de datos pequeña simultáneamente. Ideal para proyectos en crecimiento.
16-32 GB: Servidores de producción medianos. Pueden cachear grandes cantidades de datos en memoria, reduciendo drásticamente las consultas a disco.
128+ GB: Servidores de base de datos de alto rendimiento, donde cachear todo en RAM es la estrategia principal.

Disco: SSD vs HDD y la revolución NVMe¶

El almacenamiento es quizás el componente que más ha cambiado en los últimos años:

Tipo	Velocidad lectura	IOPS	Latencia	Uso ideal
HDD	~150 MB/s	~200	~10 ms	Backups, archivos históricos
SSD SATA	~500 MB/s	~50,000	~0.1 ms	Servidores web estándar
NVMe	~3,500 MB/s	~500,000	~0.02 ms	Bases de datos, alta carga

El Hetzner CX23 que veremos en la sección de VPS incluye 40 GB NVMe por $3.49/mes. Ese NVMe es uno de sus grandes atractivos: las lecturas y escrituras son casi instantáneas comparadas con un SSD SATA, y ni hablar comparado con un HDD.

Red y ancho de banda¶

La red es el conducto por donde salen tus respuestas HTTP. Un servidor con 1 Gbps de conexión puede transferir ~125 MB/segundo. Para la mayoría de proyectos, esto es más que suficiente. Lo que más importa no es la velocidad máxima, sino la latencia: el tiempo que tarda en llegar el primer byte.

La regla de la latencia: cada 100ms de latencia adicional reduce las conversiones de e-commerce en ~1% (dato consolidado del sector). Por eso la ubicación geográfica del servidor importa: si tus usuarios están en México y tu servidor está en Frankfurt, hay ~140ms de latencia transatlántica desde el cable físico.

Centros de datos: dónde viven los servidores¶

Un centro de datos (data center) es, en pocas palabras, un edificio diseñado para albergar servidores. Pero decir "edificio" es quedarse muy corto. Es más bien una fortaleza tecnológica con sistemas redundantes de energía, refrigeración y conectividad.

┌────────────────────────────────────────────────────────────┐
│              ANATOMÍA DE UN SERVIDOR FÍSICO                │
│                                                            │
│  ┌──────────────────────────────────────────────────────┐  │
│  │                      RACK 1U                         │  │
│  ├──────────────────────────────────────────────────────┤  │
│  │  ┌──────────────┐  ┌──────────────┐                  │  │
│  │  │   CPU x2     │  │  RAM: 64 GB  │                  │  │
│  │  │  (32 núcleos │  │  (16 slots)  │                  │  │
│  │  │   cada uno)  │  │              │                  │  │
│  │  └──────────────┘  └──────────────┘                  │  │
│  │  ┌──────────────┐  ┌──────────────┐                  │  │
│  │  │   NVMe x4    │  │  Red: 10Gbps │                  │  │
│  │  │  (2 TB total)│  │  (2 puertos) │                  │  │
│  │  └──────────────┘  └──────────────┘                  │  │
│  │  ┌──────────────┐  ┌──────────────┐                  │  │
│  │  │  Fuente x2   │  │   IPMI/iDRAC │                  │  │
│  │  │  (redundante)│  │  (gestión    │                  │  │
│  │  │              │  │  remota)     │                  │  │
│  │  └──────────────┘  └──────────────┘                  │  │
│  └──────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────┘

Redundancia energética: Los centros de datos tienen UPS (Uninterruptible Power Supplies), que son baterías gigantes que entran en funcionamiento en microsegundos si falla la corriente comercial. Además tienen generadores diésel que arrancan en segundos y pueden mantener el centro de datos funcionando durante días.

Refrigeración: Los servidores generan una cantidad enorme de calor. Un rack típico consume 5-15 kW, comparable a 5-15 microondas funcionando simultáneamente. Los centros de datos usan sistemas de refrigeración sofisticados: pasillos fríos/calientes, enfriamiento líquido, free-cooling (aprovechando el aire exterior frío en invierno).

5.4 Sistemas operativos para servidores¶

Linux: el rey indiscutible¶

Con el 59.4% de todos los servidores en Internet corriendo Linux (diciembre 2025), y Ubuntu siendo la distribución más popular con el 13.7% del total de servidores web, la pregunta no es si aprender Linux, sino cuándo. La respuesta es: hoy.

¿Por qué domina Linux en servidores?

Gratuito y de código abierto: sin licencias caras como Windows Server (~$500-$1,200 por licencia).
Estabilidad legendaria: servidores Linux que llevan años funcionando sin reiniciarse son algo común, no una excepción.
Eficiencia: Linux puede correr con 512 MB de RAM y ser completamente funcional. Windows Server necesita mínimo 2 GB solo para arrancar.
Ecosistema: Nginx, Apache, MySQL, PostgreSQL, Docker, Kubernetes: todo nació y funciona mejor en Linux.
Seguridad: modelo de permisos granular, pocas superficies de ataque en instalaciones minimalistas.

Ubuntu Server es la puerta de entrada recomendada para quienes vienen del mundo del desarrollo web. Es la misma base de Ubuntu Desktop pero sin interfaz gráfica, con actualizaciones de seguridad por 5 años (LTS) y una comunidad masiva que responde preguntas en segundos.

Debian es el padre de Ubuntu y es famoso por su estabilidad extrema. Si Ubuntu adopta nuevas versiones de paquetes rápidamente, Debian las testa durante meses antes de incluirlas en su rama estable. Ideal para servidores de base de datos críticos donde "si funciona, no lo toques" es el mantra.

Rocky Linux y AlmaLinux surgieron cuando Red Hat cambió la licencia de CentOS en 2020-2021, dejando a miles de administradores buscando alternativas. Son binariamente compatibles con Red Hat Enterprise Linux (RHEL) y son la opción estándar en entornos corporativos que migran desde CentOS.

Windows Server: cuándo tiene sentido¶

Windows Server no está muerto. Con el 3.2% de cuota de mercado en servidores web (a través de IIS), ocupa un nicho específico y bien definido: empresas que ya usan el ecosistema Microsoft.

Tiene sentido usar Windows Server cuando: - La aplicación está construida en ASP.NET o .NET Framework (legacy). - El cliente tiene licencias Microsoft existentes (Microsoft 365, Active Directory). - Se usan tecnologías como SQL Server o SharePoint. - El equipo de IT tiene expertise exclusivamente en Windows.

No tiene sentido cuando: - Construyes algo desde cero en 2026. - Usas Node.js, Python, Go o cualquier stack moderno. - El presupuesto es limitado (las licencias son caras).

Criterio	Linux (Ubuntu)	Windows Server
Costo de licencia	Gratis	$500-$1,200+
Rendimiento web	Excelente	Bueno
Compatibilidad .NET	Buena (dotnet core)	Nativa
Facilidad inicial	Curva de aprendizaje	Más familiar
Ecosistema cloud	Nativo	Compatible
Uso en producción	59.4% del mercado	~18% del mercado

5.5 Servidores web más utilizados¶

Un servidor web es el programa que recibe peticiones HTTP y devuelve respuestas. Es el portero del edificio: recibe a cada visitante, verifica qué quieren y los dirige al lugar correcto.

Nginx (31.9% — líder global)¶

Historia: Igor Sysoev, un ingeniero ruso, creó Nginx en 2004 para resolver un problema específico: servir 10,000 conexiones simultáneas (el famoso problema C10K). Los servidores de la época, basados en el modelo de un proceso por conexión (como Apache), se colapsaban con ese volumen. Sysoev diseñó una arquitectura radicalmente diferente: event-driven y asíncrona.

Cómo funciona: En vez de crear un proceso o hilo por cada conexión (lo que consume RAM proporcional al número de usuarios), Nginx usa un pequeño número de workers (igual al número de CPUs), cada uno capaz de manejar miles de conexiones simultáneamente usando el mecanismo de eventos del sistema operativo (epoll en Linux). Es como un chef que cocina muchos platos al mismo tiempo moviéndose entre ellos, en vez de esperar a que cada plato esté listo antes de empezar el siguiente.

Ejemplo de configuración básica:

server {
    listen 80;
    server_name elprofe.org www.elprofe.org;

    # Redirigir a HTTPS
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name elprofe.org www.elprofe.org;

    # Archivos estáticos
    root /var/www/elprofe;
    index index.html;

    # Proxy hacia la app Node.js en puerto 3000
    location /api/ {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Caché de archivos estáticos
    location ~* \.(jpg|jpeg|png|gif|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Ventajas: extraordinario rendimiento con alta concurrencia, bajo consumo de memoria, excelente como reverse proxy y balanceador de carga, amplio soporte de módulos.

Desventajas: configuración menos intuitiva que Apache para principiantes, no soporta .htaccess (lo que puede ser problemático al migrar desde Apache), algunos módulos dinámicos requieren recompilar.

Apache HTTP Server (23.1%)¶

Historia: Lanzado en 1995, Apache fue durante años sinónimo de servidor web. De hecho, construyó literalmente la web comercial. Su nombre viene de "a patchy server" (un servidor parcheado), por los parches que le aplicaron al código original del servidor httpd de la NCSA.

Arquitectura: A diferencia de Nginx, Apache usa un modelo de proceso/hilo por conexión (con diferentes MPMs: prefork, worker, event). Esto lo hace más flexible pero también más pesado en memoria con mucho tráfico.

Su killer feature es el archivo .htaccess: un archivo de configuración que puede existir en cualquier directorio y que permite a los administradores de sitios (no solo los del servidor) modificar el comportamiento de Apache. Es la razón por la que millones de sitios WordPress en hosting compartido pueden tener redirects, protección de directorios y reglas personalizadas sin acceso al servidor completo.

Ventajas: enormemente maduro y documentado, módulos para casi todo imaginable, .htaccess da poder a usuarios sin acceso root, compatibilidad universal con hosting compartido.

Desventajas: mayor consumo de memoria por conexión, configuración puede volverse compleja, menos eficiente que Nginx para alto tráfico estático.

LiteSpeed (15.2%)¶

LiteSpeed Web Server es el gran desconocido que se ha ganado el 15.2% del mercado casi sin hacer ruido. Su propuesta de valor es clara: es 100% compatible con Apache (incluyendo .htaccess y sus módulos), pero con el rendimiento de Nginx o superior.

Es el servidor favorito del mundo del hosting compartido y WordPress. LiteSpeed tiene su propio plugin de caché para WordPress (LiteSpeed Cache) que es consistentemente el más rápido en benchmarks independientes. Además soporta HTTP/3 nativo, el protocolo de próxima generación que veremos en el capítulo 6.

Ventajas: compatible con Apache sin cambiar configuración, excelente para WordPress, HTTP/3 nativo, menor uso de CPU que Apache.

Desventajas: la versión Enterprise es de pago (aunque hay una versión OpenLiteSpeed gratuita), menos documentación que Apache o Nginx.

Caddy (0.2% pero creciendo)¶

Caddy es el servidor web que hubiera existido si lo hubieran diseñado en 2024 en vez de en los años 90. Su característica más revolucionaria: HTTPS automático por defecto. No tienes que configurar Let's Encrypt, no tienes que renovar certificados. Caddy lo hace solo.

Ejemplo de Caddyfile (la configuración más simple del mundo):

elprofe.org {
    reverse_proxy localhost:3000
}

Esas dos líneas hacen todo: obtiene certificado SSL de Let's Encrypt, configura HTTPS, redirige HTTP a HTTPS y hace proxy a tu aplicación en el puerto 3000. Nginx necesita 30+ líneas para hacer lo mismo.

Ventajas: configuración increíblemente simple, HTTPS automático y renovación sin intervención, excelente para desarrolladores independientes y proyectos pequeños/medianos.

Desventajas: menor cuota de mercado implica menos recursos de la comunidad, algunos módulos avanzados aún no maduros, rendimiento ligeramente inferior a Nginx en escenarios de altísima concurrencia.

Microsoft IIS (3.2%)¶

Internet Information Services (IIS) es el servidor web de Microsoft, incluido con Windows Server. Con el 3.2% del mercado, es la opción estándar para aplicaciones .NET y ASP.NET en entornos empresariales Windows.

Ventajas: integración nativa con el stack Microsoft, administración gráfica a través de IIS Manager, soporte nativo de ASP.NET y .NET Core, gestión centralizada en entornos Active Directory.

Desventajas: solo funciona en Windows Server (licencia de pago), mayor consumo de recursos que Nginx/Apache en Linux, menos flexible para stacks modernos no-Microsoft.

Cloudflare como "servidor web" (28.5% como edge proxy)¶

Aunque técnicamente Cloudflare no es un servidor web tradicional, aparece en las estadísticas de W3Techs con el 28.5% del mercado (en crecimiento desde 23.8% en junio 2025) porque actúa como capa intermedia delante de millones de sitios web.

Cloudflare es un proxy inverso en el edge: se interpone entre el usuario y tu servidor, sirviéndole directamente desde el nodo más cercano al usuario cuando tiene el contenido en caché, y filtrando tráfico malicioso antes de que llegue a tu servidor.

Ventajas: CDN global con 310+ ciudades, protección DDoS incluida, SSL/TLS gratuito, firewall de aplicación web (WAF), Workers para edge computing.

Desventajas: no es un servidor web completo por sí solo (necesita un origen detrás), algunas funcionalidades avanzadas son de pago, añade una capa de dependencia externa.

Tabla comparativa de servidores web¶

Servidor	Cuota (jun 2026)	Arquitectura	HTTPS auto	Mejor para	Dificultad
Nginx	31.9%	Event-driven	No	Alto tráfico, reverse proxy	Media
Cloudflare	28.5%	Edge/CDN	Sí	Cualquier proyecto con CDN	Baja
Apache	23.1%	Process/Thread	No	Hosting compartido, .htaccess	Media
LiteSpeed	15.2%	Event-driven	No	WordPress, hosting compartido	Media
Node.js (httpd)	6.6%	Event-driven	No	APIs, apps JavaScript	Alta
IIS	3.2%	Process/Thread	No	Ecosistema .NET/Microsoft	Baja-Media
Caddy	0.2%	Event-driven	Sí	Proyectos propios, indie devs	Baja

Fuente de cuotas: W3Techs, junio 2026 — https://w3techs.com/technologies/overview/web_server

5.6 Hosting: qué es y qué NO es¶

Definición precisa¶

Hosting (alojamiento web) es el servicio de proporcionar espacio en un servidor y los recursos necesarios para que un sitio web sea accesible en Internet. Pagas a alguien para que mantenga tu sitio funcionando en su infraestructura.

Pero aquí está el problema: mucha gente mezcla estos conceptos y toma decisiones equivocadas. Vamos a dejarlos clarísimos:

Hosting: el espacio donde viven tus archivos y aplicaciones.
Servidor: la máquina (física o virtual) que ejecuta tu sitio.
Dominio: el nombre (elprofe.org) que los usuarios escriben.
DNS: el directorio que traduce dominio a IP.
CDN: red de distribución que copia tu contenido en múltiples ubicaciones para servir desde la más cercana al usuario.
Cloud: servidores virtualizados en centros de datos de grandes empresas (AWS, GCP, Azure), no un lugar mágico en el cielo.

┌─────────────────────────────────────────────────────────────────┐
│           RELACIÓN ENTRE CONCEPTOS CLAVE                        │
│                                                                 │
│  ┌──────────┐      ┌──────────┐      ┌──────────────────────┐   │
│  │ DOMINIO  │─DNS─▶│   IP     │─────▶│      HOSTING         │   │
│  │elprofe   │      │104.21.x.x│      │                      │   │
│  │.org      │      └──────────┘      │  ┌──────────────┐    │   │
│  └──────────┘           ▲            │  │   SERVIDOR   │    │   │
│                         │            │  │  (Nginx/App) │    │   │
│  ┌──────────┐           │            │  └──────┬───────┘    │   │
│  │   CDN    │───────────┘            │         │            │   │
│  │(Cloudflare│  (Cloudflare intercepta│  ┌──────▼───────┐   │   │
│  │ Pages)   │  y puede responder      │  │   ARCHIVOS   │   │   │
│  └──────────┘  desde edge antes de   │  │  HTML/CSS/JS │   │   │
│               llegar al origen)      │  └──────────────┘   │   │
│                                      └──────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Confusiones comunes que cuestan dinero:

"Compré el dominio, ya tengo hosting" → Falso. El dominio solo es el nombre. Necesitas por separado contratar hosting donde alojar los archivos.
"Tengo hosting gratuito de Firebase, ya no necesito dominio" → Firebase Hosting da una URL gratis (tuproyecto.web.app), pero para usar elprofe.org necesitas comprar ese dominio por separado.
"La nube es gratis" → AWS, GCP y Azure cobran por uso. Tienen free tiers iniciales limitados, pero en producción se paga.
"Un CDN reemplaza el hosting" → Un CDN distribuye y cachea contenido, pero necesita un origen donde vive el contenido original.

5.7 Tipos de hosting¶

Hosting compartido ($2.50–$10/mes entry, $10–$15/mes business)¶

Imagina una pensión estudiantil: compartes cocina, baño, sala de estar y conexión a Internet con varios desconocidos. Es barato, tienes todo incluido, pero si alguien decide cocinar un festín a las 3am, todos sufren.

En el hosting compartido, cientos o miles de sitios web viven en el mismo servidor físico. Si el sitio de tu vecino recibe un pico de tráfico enorme, puede ralentizar el tuyo. Si otro vecino instala un plugin de WordPress mal programado que consume toda la CPU, tu sitio sufre. Es el efecto "vecino ruidoso".

Ventajas: económico, todo gestionado por el proveedor (actualizaciones del servidor, seguridad base, backups), panel de control sencillo (cPanel/DirectAdmin), no requiere conocimientos técnicos de administración de servidores.

Desventajas: recursos compartidos y limitados, poco control sobre la configuración del servidor, mal aislamiento entre sitios, rendimiento inconsistente, generalmente PHP + MySQL solamente (difícil correr Node.js o Python).

Caso de uso perfecto: primariajuanescutia.edu.mx — un sitio institucional pequeño, pocas visitas diarias, solo necesita publicar información estática y quizás un formulario de contacto. Por $3-5/mes en Hostgator o Bluehost, tiene todo lo que necesita sin complicaciones técnicas.

VPS — Servidor Privado Virtual ($5–$40/mes)¶

El VPS es el apartamento propio: mismo edificio que los demás, misma planta física, pero tu espacio está completamente delimitado. Tienes tu propia cocina, tu propio baño, tus propias llaves. Lo que haga tu vecino no te afecta porque las paredes están bien aisladas.

Cómo funciona la virtualización en VPS: En un servidor físico potente, el proveedor usa un hipervisor (KVM es el más común en Linux) para crear múltiples máquinas virtuales completamente aisladas. Cada una tiene CPU dedicada, RAM dedicada y disco dedicado, garantizados. Aunque el hardware sea compartido a nivel físico, el software garantiza el aislamiento.

VPS no gestionado vs. gestionado: - No gestionado ($5-$15/mes entry): tú eres el administrador. Instalas el sistema operativo, configuras Nginx, actualizas el software, gestionas los backups. Máximo control, mínimo costo. - Gestionado ($29.95-$40/mes entry): el proveedor hace todo eso por ti. Monitoreo, actualizaciones, backups, soporte técnico. Pagas por no tener que saber.

Precios reales VPS en 2026 (vpsprices.net):

Proveedor	Plan	Precio/mes	CPU	RAM	Disco
Vultr	Cloud Compute	$2.50	1 vCPU	512 MB	10 GB SSD
DigitalOcean	Basic Droplet	$4.00	1 vCPU	1 GB	25 GB SSD
Linode/Akamai	Nanode	$5.00	1 vCPU	1 GB	25 GB SSD
Hostinger	KVM 1	$4.99	1 vCPU	4 GB	50 GB NVMe
Hetzner	CX23	$3.49	2 vCPU	4 GB	40 GB NVMe

El Hetzner CX23 a $3.49/mes con 2 vCPU, 4 GB de RAM y 40 GB NVMe es la joya oculta del mercado en 2026. Por ese precio obtienes un servidor con más RAM que la mayoría de los planes de $10-15/mes de la competencia. La desventaja: los centros de datos de Hetzner están en Europa y EE.UU., lo que añade latencia para usuarios en Latinoamérica.

Para quién: elprofe.org en su fase de crecimiento. Con 4 GB de RAM y NVMe, puede correr Node.js + Firebase SDK + Nginx sin problemas. Cuando el tráfico crezca, se migra a un plan mayor o a cloud.

Servidor dedicado ($80–$300+/mes)¶

La casa propia: todos los recursos son tuyos. Nadie más en esa máquina física. Máximo rendimiento, máximo control, máximo costo.

Se justifica cuando necesitas potencia de cómputo que un VPS no puede darte (bases de datos muy grandes, videojuegos en tiempo real, renderizado), cuando el aislamiento por seguridad es crítico (datos financieros, médicos), o cuando el costo de múltiples VPS supera al de un dedicado.

En 2026, para la mayoría de proyectos de emprendedores y docentes, el servidor dedicado es innecesario. El cloud y los VPS de alta gama cubren casi todos los casos.

Cloud Hosting (AWS, GCP, Azure)¶

El cloud no es un tipo específico de máquina; es un modelo de servicio: pagas exactamente por lo que usas, puedes escalar en segundos, y los recursos son virtualmente ilimitados.

Auto-scaling: la característica más poderosa del cloud. Cuando elprofe.org publica un nuevo examen y 5,000 estudiantes se conectan simultáneamente al mediodía, el auto-scaling lanza automáticamente 10 instancias nuevas para absorber el tráfico. A las 2am cuando solo hay 10 usuarios, se reducen a 1 instancia. Solo pagas por lo que usas.

┌────────────────────────────────────────────────────────────────┐
│          ESCALADO HORIZONTAL vs. VERTICAL                      │
├─────────────────────────────┬──────────────────────────────────┤
│       VERTICAL               │         HORIZONTAL              │
│    (Scale UP)                │         (Scale OUT)             │
│                              │                                 │
│  ┌──────────┐                │  ┌──────┐  ┌──────┐  ┌──────┐  │
│  │          │                │  │Srv 1 │  │Srv 2 │  │Srv 3 │  │
│  │ SERVIDOR │ ← CPU más      │  └──────┘  └──────┘  └──────┘  │
│  │  GRANDE  │   grande       │       ▲         ▲        ▲      │
│  │          │ ← Más RAM      │       └─────────┴────────┘      │
│  └──────────┘                │          BALANCEADOR            │
│                              │          DE CARGA               │
│  Límite físico de la         │                                 │
│  máquina más grande          │  Sin límite teórico             │
│  Costoso y lento de aplicar  │  Ágil y automático              │
└─────────────────────────────┴──────────────────────────────────┘

Cuándo usar cloud: cuando el tráfico es muy variable o impredecible, cuando necesitas múltiples servicios integrados (base de datos gestionada, almacenamiento de objetos, notificaciones push), cuando el equipo ya tiene expertise en AWS/GCP/Azure.

Serverless (Funciones como Servicio — FaaS)¶

El modelo serverless lleva la abstracción al extremo: no gestionas servidores, no te preocupas por el SO, ni siquiera por el proceso servidor. Solo escribes una función y la despliegas.

// Firebase Function — una función serverless
exports.generarCredencial = functions.https.onCall(async (data, context) => {
  const { alumnoId, cursoId } = data;
  const credencial = await crearCertificadoPDF(alumnoId, cursoId);
  return { url: credencial.downloadURL };
});

Esta función solo corre cuando alguien la llama. Si no hay llamadas, no hay costo. Si hay 10,000 llamadas simultáneas, la plataforma escala automáticamente.

Limitaciones importantes: - Cold starts: si la función no se ha ejecutado recientemente, hay un delay de arranque (AWS Lambda: 100-500ms, Cloudflare Workers: <5ms). Para APIs que necesitan respuesta ultra-rápida, esto importa. - Tiempo de ejecución limitado: AWS Lambda tiene un máximo de 15 minutos por ejecución. Ideal para tareas cortas, no para procesos largos. - Stateless: la función no puede guardar estado entre ejecuciones. Cada llamada parte de cero.

Para quién: APIs de generación de credenciales digitales en proyectos como los del libro. Una función que genera un PDF de certificado cuando un estudiante completa un curso es el caso de uso perfecto.

Edge Computing¶

Si el cloud tradicional acerca los servidores al usuario comparado con un datacenter propio, el edge computing da otro paso más: lleva el código a miles de puntos distribuidos globalmente, a milisegundos del usuario.

Cloudflare Workers usa V8 isolates (el motor de JavaScript de Chrome) en vez de contenedores o VMs. Esto permite cold starts de menos de 5ms versus los 100-500ms de AWS Lambda. Los Workers corren en más de 310 ciudades en todo el mundo, con el 95% de la población mundial a menos de 50ms.

LATENCIA COMPARADA:

  Usuario en CDMX → Servidor en Virginia:   ~80-120ms
  Usuario en CDMX → CDN en Dallas:          ~20-30ms
  Usuario en CDMX → Edge Worker en CDMX:   ~2-5ms

Cuándo usar edge y cuándo no: - ✅ Ideal: personalización de contenido, A/B testing, autenticación, redirects, APIs ultra-rápidas, contenido geolocalizado. - ❌ No ideal: operaciones con base de datos tradicional (las BD no están en el edge), procesos largos, estado persistente complejo.

Tabla comparativa de tipos de hosting¶

Tipo	Precio/mes	Control	Dificultad	Escalabilidad	Ideal para
Compartido	$2.50–$15	Bajo	Baja	Ninguna	Blogs, sitios pequeños
VPS	$5–$40	Alto	Media-Alta	Manual	Apps en crecimiento
Dedicado	$80–$300+	Total	Alta	Manual	Alto tráfico, seguridad máxima
Cloud (IaaS)	$10–$200+	Alto	Alta	Automática	Tráfico variable, empresas
Serverless	Pago por uso	Bajo	Media	Automática	APIs, funciones cortas
Edge Computing	Pago por req.	Bajo	Media	Automática	Latencia mínima, globalidad

5.8 Plataformas modernas de hosting estático y JAMstack¶

El ecosistema de plataformas de hosting ha cambiado radicalmente en los últimos años. Para proyectos de contenido estático y aplicaciones JAMstack, estas plataformas ofrecen una experiencia de despliegue que hace obsoleto el FTP de los años 90.

GitHub Pages¶

El punto de entrada para millones de desarrolladores. Conectas tu repositorio de GitHub, y cada push al branch principal despliega automáticamente tu sitio.

Free tier: 1 GB de almacenamiento, 100 GB/mes de ancho de banda.
Limitaciones: solo contenido estático, dominio personalizado requiere CNAME/A record configurado manualmente, los sitios en repositorios privados requieren GitHub Pro ($4/mes).
Ideal para: documentación de proyectos (muchos proyectos open source lo usan), portafolios personales, sitios generados con Jekyll (que GitHub Pages soporta nativamente).

Cloudflare Pages¶

La plataforma de hosting estático más generosa del mercado en su free tier. Conectas tu repositorio (GitHub o GitLab), configuras el comando de build, y Cloudflare despliega en su red global de 310+ ciudades.

Free tier: sitios ilimitados, ancho de banda ilimitado, 500 builds/mes.
Pro: $20/mes, agrega más builds, control de acceso, analytics.
Killer feature: al ser edge-native, tu sitio corre en el Cloudflare CDN desde el primer día, sin configuración adicional. La latencia es mínima para usuarios en cualquier parte del mundo.
Ideal para: el frontend de elprofe.org. Un Next.js o Astro desplegado aquí tiene rendimiento extraordinario y ancho de banda ilimitado.

Netlify¶

Fue la plataforma que inventó el concepto de "push to deploy" para el mundo JAMstack. Su DX (Developer Experience) es legendaria.

Free tier: 100 GB/mes de transferencia, 300 minutos de build/mes.
Pro: $19/mes.
Extras únicos: Netlify Forms (formularios de contacto sin backend), Netlify Identity (autenticación básica incluida), Deploy Previews (cada PR genera una URL de preview).
Ideal para: sitios de marketing, proyectos con formularios, equipos que valoran las previsualizaciones por Pull Request.

Vercel¶

Si Netlify inventó el CI/CD para JAMstack, Vercel lo perfeccionó para el ecosistema React/Next.js. Vercel es la empresa que crea Next.js, así que la integración es obviamente perfecta.

Free tier: 100 GB/mes de transferencia, 6,000 minutos de build/mes.
Pro: $20/mes.
Especialidad: SSR (Server-Side Rendering) y ISR (Incremental Static Regeneration) de Next.js funcionan de forma nativa. Si Next.js genera HTML en el servidor, Vercel lo procesa eficientemente en su edge network.
Ideal para: aplicaciones Next.js, cualquier proyecto que use SSR o ISR.

Firebase Hosting¶

La opción natural para proyectos construidos sobre el ecosistema Firebase/Google. La integración con Firestore, Firebase Auth y Cloud Functions es nativa e impecable.

Free tier (Spark): 10 GB de storage, 10 GB/mes de transferencia.
Pago por uso (Blaze): $0.026/GB de storage adicional, $0.15/GB de transferencia adicional.
Killer feature: despliegue atómico. Cada firebase deploy es una transacción: o todo se actualiza, o nada. No hay estado intermedio donde un usuario vea mitad de la versión antigua y mitad de la nueva.
Ideal para: elprofe.org completo. Si ya usas Firestore para la base de datos, Firebase Auth para el login y Cloud Functions para las APIs, tiene todo el sentido alojar también el frontend aquí.

AWS Amplify¶

La opción de AWS para hosting de aplicaciones web modernas. Integra con CodeCommit, GitHub y otros repositorios, con pipelines CI/CD automáticos.

Precios: $0.01/minuto de build, $0.023/GB de storage, $0.15/GB servido. Sin free tier permanente.
Ideal para: proyectos empresariales que ya tienen toda su infraestructura en AWS y necesitan que el hosting esté en el mismo entorno.

Azure Static Web Apps¶

La respuesta de Microsoft a Netlify/Vercel. Gratuito para proyectos pequeños, con CI/CD integrado via GitHub Actions.

Free tier: disponible.
Ideal para: equipos .NET/Microsoft que quieren un pipeline de despliegue integrado con su ecosistema.

Tabla comparativa de plataformas modernas¶

Plataforma	Free Storage	Free Bandwidth	Free Builds	Precio Pro	Mejor para
GitHub Pages	1 GB	100 GB/mes	Ilimitado	$4 (GitHub)	Docs, portafolios
Cloudflare Pages	Ilimitado	Ilimitado	500/mes	$20/mes	Máximo rendimiento CDN
Netlify	—	100 GB/mes	300 min/mes	$19/mes	DX, formularios
Vercel	—	100 GB/mes	6,000 min/mes	$20/mes	Next.js, SSR/ISR
Firebase Hosting	10 GB	10 GB/mes	—	Pago x uso	Ecosistema Firebase
AWS Amplify	—	—	$0.01/min	Pago x uso	Ecosistema AWS
Azure Static Apps	Básico	Básico	Via GH Actions	$9/mes	Ecosistema Microsoft

5.9 Arquitecturas modernas¶

La arquitectura web ha evolucionado enormemente desde los días del HTML estático de 1991. Hoy existen múltiples paradigmas, cada uno con sus fortalezas y debilidades.

Sitio estático: Archivos HTML, CSS y JS pre-generados que el servidor sirve directamente sin procesamiento. El tiempo de respuesta es mínimo porque no hay lógica de servidor. Ideal para sitios de contenido que no cambia frecuentemente (documentación, portafolios, landing pages).

Sitio dinámico: El servidor genera el HTML en cada petición consultando bases de datos y aplicando lógica. WordPress, sitios PHP clásicos. Flexible pero más lento y con mayor carga en el servidor.

SPA (Single Page Application): La aplicación carga una vez y actualiza el DOM del navegador dinámicamente sin recargar la página. React, Vue, Angular. Excelente UX, pero problemas con SEO (el HTML inicial está vacío) y rendimiento en la primera carga.

SSR (Server-Side Rendering): El servidor genera el HTML completo para cada petición, como los sitios dinámicos, pero usando frameworks modernos como Next.js o Nuxt. Combina SEO óptimo con experiencia de SPA.

SSG (Static Site Generation): El framework genera todos los archivos HTML en tiempo de build, no en cada petición. Jekyll, Hugo, Astro, Next.js (getStaticProps). El resultado es un sitio estático ultra-rápido.

ISR (Incremental Static Regeneration): Exclusivo de Next.js. Genera páginas estáticas que se revalidan automáticamente cada N segundos o bajo demanda. Combina la velocidad del sitio estático con datos frescos sin necesidad de hacer rebuild completo.

Headless CMS: El contenido se gestiona en un sistema separado (Contentful, Sanity, Strapi) y se consume vía API. El frontend puede ser cualquier tecnología. Ideal cuando el mismo contenido debe aparecer en web, app móvil y otros canales.

JAMstack: JavaScript + APIs + Markup. Filosofía que promueve pre-renderizar todo lo posible en el build y usar APIs para la funcionalidad dinámica. No es una tecnología específica, es un enfoque arquitectónico.

Serverless: Funciones stateless que se ejecutan bajo demanda. Escalan automáticamente a cero (sin costo) cuando no hay tráfico.

Microservicios: La aplicación se divide en servicios independientes, cada uno con su propio proceso, base de datos y ciclo de despliegue. Complejo de operar pero extremadamente escalable.

┌─────────────────────────────────────────────────────────────────────┐
│            ÁRBOL DE DECISIÓN DE ARQUITECTURA                        │
│                                                                     │
│  ¿El contenido cambia frecuentemente?                               │
│         │                                                           │
│    ┌────┴─────┐                                                     │
│    │          │                                                     │
│   NO          SÍ                                                    │
│    │          │                                                     │
│    ▼          ▼                                                     │
│  SSG        ¿Necesita SEO?                                          │
│  (Hugo,      │                                                      │
│  Astro,   ┌──┴──┐                                                   │
│  Jekyll)  │     │                                                   │
│          NO    SÍ                                                   │
│           │     │                                                   │
│           ▼     ▼                                                   │
│          SPA   ¿Alto tráfico o contenido                           │
│          (React, muy dinámico?                                      │
│          Vue)   │                                                   │
│              ┌──┴──┐                                                │
│              │     │                                               │
│             NO    SÍ                                               │
│              │     │                                               │
│              ▼     ▼                                               │
│             SSR  ISR o SSG + API                                   │
│            (Next (Next.js ISR,                                     │
│            .js)  Headless CMS)                                     │
└─────────────────────────────────────────────────────────────────────┘

5.10 Balanceadores de carga¶

Imagina que tu restaurante se volvió tan popular que una sola cocina no da abasto. Abres cinco cocinas idénticas y contratas un maitre en la puerta que, cuando llega cada cliente, decide a cuál cocina mandarlo para que ninguna esté saturada. Eso es exactamente un balanceador de carga.

Un balanceador de carga (load balancer) distribuye el tráfico entrante entre múltiples servidores backend, garantizando que ninguno se sobrecargue y que el servicio esté disponible incluso si uno de los servidores falla.

Algoritmos comunes de distribución: - Round-robin: cada petición va al siguiente servidor en la lista, en orden circular. Simple y efectivo si los servidores son idénticos. - Least connections: la petición va al servidor con menos conexiones activas. Mejor cuando algunas peticiones tardan más que otras. - IP hash: el servidor se elige según la IP del cliente. El mismo usuario siempre va al mismo servidor (útil para sesiones). - Weighted round-robin: servidores más potentes reciben más peticiones. Útil cuando los servidores no son idénticos.

┌────────────────────────────────────────────────────────────────────┐
│              BALANCEADOR DE CARGA CON ALTA DISPONIBILIDAD          │
│                                                                    │
│    ┌──────────┐   ┌──────────┐   ┌──────────┐                     │
│    │ User 1   │   │ User 2   │   │ User 3   │                     │
│    └────┬─────┘   └────┬─────┘   └────┬─────┘                    │
│         │              │              │                            │
│         └──────────────┴──────────────┘                           │
│                         │                                          │
│                         ▼                                          │
│              ┌───────────────────┐                                 │
│              │   BALANCEADOR     │                                 │
│              │   DE CARGA        │                                 │
│              │ (Nginx/HAProxy/   │                                 │
│              │  AWS ALB)         │                                 │
│              └─────┬──────┬──────┘                                │
│                    │      │      │                                 │
│              ┌─────┘   ┌──┘   ┌──┘                               │
│              ▼          ▼      ▼                                   │
│         ┌────────┐ ┌────────┐ ┌────────┐                          │
│         │Server 1│ │Server 2│ │Server 3│                          │
│         │✅ OK   │ │❌ CAÍDO│ │✅ OK   │                         │
│         └────────┘ └────────┘ └────────┘                          │
│                                                                    │
│  Si Server 2 cae, el balanceador automáticamente lo detecta        │
│  y deja de enviarle tráfico. Los usuarios no notan nada.           │
└────────────────────────────────────────────────────────────────────┘

Esto se conoce como alta disponibilidad (High Availability, HA). Con un solo servidor, si cae, el sitio cae. Con un balanceador y múltiples servidores, el servicio sigue funcionando aunque uno falle.

La combinación de balanceador de carga + múltiples servidores + escalado automático (cloud) es la base de cualquier arquitectura de producción seria.

5.11 Centros de datos¶

Los Tiers del Uptime Institute¶

La industria de centros de datos usa un sistema de clasificación estándar llamado Tiers, definido por el Uptime Institute, para comunicar de forma objetiva la fiabilidad de la infraestructura:

Tier	Uptime	Downtime máx/año	Redundancia
I	99.671%	28.8 horas	Sin redundancia
II	99.741%	22 horas	Redundancia parcial
III	99.982%	1.6 horas	N+1 (fault tolerant)
IV	99.995%	26.3 minutos	2N (fully redundant)

Fuente: Uptime Institute / CoreSite — https://www.coresite.com/blog/breaking-down-data-center-tiers-classifications

Tier I: Básico. Una sola ruta de energía, una sola ruta de red. Sin redundancia. Pensado para uso no crítico (oficinas pequeñas).

Tier II: Algo de redundancia. Tiene UPS y generadores, pero una sola ruta de distribución. Mantenimientos programados requieren apagado.

Tier III: El estándar de la industria para hosting comercial. Tiene múltiples rutas activas (N+1), lo que permite mantenimiento sin interrupciones. AWS, GCP, Azure operan sus centros en este nivel o superior.

Tier IV: El máximo. Completamente redundante: dos rutas activas de energía, dos de red, dos de refrigeración. Incluso si falla un sistema completo, el otro mantiene todo funcionando. Usado por infraestructuras financieras críticas y gobiernos.

El backbone de Internet: cables transoceánicos¶

Una curiosidad que impresiona: la mayor parte del tráfico internacional de Internet viaja por cables de fibra óptica tendidos en el fondo del océano. Hay más de 400 sistemas de cables submarinos activos, con una longitud total de más de 1.3 millones de kilómetros.

Cuando un usuario en México accede a un servidor en Alemania, es muy probable que los datos crucen el Atlántico por un cable que está a 4,000 metros de profundidad. La velocidad de la luz en la fibra óptica (~200,000 km/s) es la razón de por qué hay ~40-80ms de latencia transatlántica, y no hay mucho que la tecnología pueda hacer para reducirla: es física pura.

5.12 Virtualización¶

Máquinas virtuales: un computador dentro de otro¶

Una máquina virtual (VM) es una computadora completa simulada por software. El hipervisor es el software que gestiona estas VMs, repartiendo los recursos del hardware físico entre ellas.

Existen dos tipos de hipervisores: - Tipo 1 (bare-metal): corre directamente sobre el hardware, sin SO intermedio. KVM en Linux, Hyper-V en Windows Server, VMware ESXi. Son los más usados en centros de datos. - Tipo 2 (hosted): corre sobre un SO existente. VirtualBox, VMware Workstation. Para desarrollo y pruebas.

KVM (Kernel-based Virtual Machine) es el hipervisor más usado en servidores Linux y la base de la mayoría de VPS en el mercado. Es parte del kernel de Linux desde 2007.

Docker y contenedores: más ligeros que las VMs¶

Un contenedor es como un apartamento amueblado y empaquetado: incluye la aplicación, sus dependencias, las librerías necesarias y un sistema mínimo, pero comparte el kernel del SO del host. No tiene que arrancar un sistema operativo completo.

┌────────────────────────────────────────────────────────────────────┐
│           BARE METAL vs. VMs vs. CONTENEDORES                      │
├───────────────┬──────────────────────┬─────────────────────────────┤
│  BARE METAL   │   MÁQUINAS VIRTUALES │      CONTENEDORES           │
│               │                      │                             │
│  ┌──────────┐ │  ┌──────┐  ┌──────┐  │  ┌────┐  ┌────┐  ┌────┐   │
│  │  App 1   │ │  │App 1 │  │App 2 │  │  │App │  │App │  │App │   │
│  └──────────┘ │  ├──────┤  ├──────┤  │  │ 1  │  │ 2  │  │ 3  │   │
│  ┌──────────┐ │  │Libs  │  │Libs  │  │  ├────┤  ├────┤  ├────┤   │
│  │   SO     │ │  ├──────┤  ├──────┤  │  │Libs│  │Libs│  │Libs│   │
│  └──────────┘ │  │ SO   │  │ SO   │  │  └────┘  └────┘  └────┘   │
│  ┌──────────┐ │  │guest │  │guest │  │       DOCKER ENGINE        │
│  │ Hardware │ │  └──────┘  └──────┘  │       ┌──────────┐         │
│  └──────────┘ │  ┌──────────────────┐│       │   SO     │         │
│               │  │   HIPERVISOR     ││       │  HOST    │         │
│               │  ├──────────────────┤│       ├──────────┤         │
│               │  │     Hardware     ││       │ Hardware │         │
│               │  └──────────────────┘│       └──────────┘         │
├───────────────┼──────────────────────┼─────────────────────────────┤
│ Boot: ~5s     │ Boot: ~30-60 seg     │ Boot: <1 segundo            │
│ Overhead: 0%  │ Overhead: ~3-5%      │ Overhead: <5%               │
│ Aislamiento:  │ Aislamiento: Alto    │ Aislamiento: Medio          │
│  N/A          │                      │                             │
└───────────────┴──────────────────────┴─────────────────────────────┘

Datos: Atmosly — https://atmosly.com/knowledge/docker-container-vs-virtual-machine-which-should-you-use-in-2025

Una imagen Docker encapsula código + dependencias + sistema mínimo en un paquete reproducible. Si funciona en tu laptop, funciona exactamente igual en producción. Esta es la promesa del contenedor: eliminar el "en mi máquina funciona".

Kubernetes es el orquestador de contenedores: si Docker es el camión que transporta los contenedores, Kubernetes es el sistema logístico completo que decide cuántos camiones necesitas, qué ruta toman, qué hacer si uno se avería y cómo coordinar miles de entregas simultáneas.

5.13 Edge Computing en profundidad¶

¿Qué significa "edge"?¶

En el argot de redes, el "edge" (borde) es la parte de la red más cercana al usuario final: los routers de las ISP, los nodos de CDN en cada ciudad, los puntos de presencia (PoPs) de Cloudflare en 310+ ciudades del mundo. Contrasta con el "core" o "origen", que son los grandes centros de datos centralizados.

El edge computing lleva la computación al borde: en vez de que tu petición viaje miles de kilómetros hasta un datacenter central, un nodo a pocos kilómetros de ti la procesa directamente.

Por qué Cloudflare Workers es diferente¶

La razón por la que Cloudflare Workers tiene cold starts de menos de 5ms (versus 100-500ms de AWS Lambda) está en los V8 isolates:

AWS Lambda arranca un contenedor (con SO) para cada función. Incluso con optimizaciones, esto tarda cientos de milisegundos.
Cloudflare Workers usa V8 isolates: el mismo motor de aislamiento que Chrome usa para tabs diferentes. Un isolate arranca en microsegundos porque no hay SO que cargar. Es código JavaScript en un sandbox, listo instantáneamente.

┌─────────────────────────────────────────────────────────────────────┐
│              COMPARATIVA DE LATENCIAS                               │
│                                                                     │
│  Servidor tradicional                                               │
│  (Single datacenter, Virginia, EE.UU.)                             │
│                                                                     │
│  Usuario CDMX ──────────────────────────────▶ ~80-120ms            │
│                                                                     │
│  CDN (Content Delivery Network)                                     │
│  (Nodo en Dallas, TX)                                               │
│                                                                     │
│  Usuario CDMX ─────────────▶ ~20-30ms                              │
│                                                                     │
│  Edge Computing (Cloudflare Workers)                                │
│  (Nodo en Ciudad de México)                                         │
│                                                                     │
│  Usuario CDMX ──▶ ~2-5ms                                           │
│                                                                     │
│  Cold start del worker: <5ms                                        │
│  (vs. AWS Lambda: 100-500ms)                                        │
└─────────────────────────────────────────────────────────────────────┘

Cloudflare Workers procesa más de 10 millones de peticiones por segundo globalmente, con el 95% de la población mundial a menos de 50ms de distancia de algún nodo.

Casos ideales para edge: personalización de respuestas HTTP (A/B testing, redirects geográficos), autenticación en el borde (verificar JWT antes de que la petición llegue al origen), transformación de imágenes, APIs de lectura con datos cacheables.

Limitaciones: sin acceso a sistemas de archivos, sin bases de datos tradicionales en el borde (aunque Cloudflare KV y D1 empiezan a resolverlo), tiempo de ejecución limitado por CPU.

5.14 Casos reales analizados¶

Cloudflare Pages (para elprofe.org — frontend)¶

elprofe.org tiene un frontend en Next.js que sirve las páginas de cursos, el perfil del estudiante y las páginas de inicio. Desplegado en Cloudflare Pages, se beneficia del ancho de banda ilimitado y la distribución edge global.

Justificación técnica: los estudiantes están en México y Latinoamérica. Con Cloudflare Pages, el HTML estático se sirve desde el nodo más cercano. La latencia percibida es mínima.
Costo: $0/mes en el free tier para comenzar.
Ventaja clave: sin límite de ancho de banda significa que si un video se vuelve viral o hay un pico de tráfico, no hay cargo inesperado.
Desventaja: las 500 builds/mes son suficientes, pero si el equipo crece y hace muchos deploys al día, puede ser un límite.

Firebase Hosting (para elprofe.org — app completa)¶

Para la versión completa con autenticación y datos en tiempo real, elprofe.org usa Firebase Hosting junto con Firestore, Firebase Auth y Cloud Functions.

Justificación técnica: todo el ecosistema Firebase en un solo proveedor elimina la complejidad de integración. Los Cloud Functions generan PDFs de certificados bajo demanda.
Costo: gratuito en Spark plan hasta 10 GB de transfer/mes. En Blaze: $0.15/GB adicional.
Ventaja clave: despliegue atómico, integración nativa con todas las demás herramientas de Firebase.
Desventaja: el free tier de Firebase es más limitado que Cloudflare Pages en ancho de banda (10 GB vs. ilimitado).

GitHub Pages (para documentación de proyectos)¶

La documentación técnica de las APIs de nlink.uk y masterfinanzas.com vive en GitHub Pages, generada con Docusaurus (React).

Costo: $0/mes.
Ventaja: pipeline completamente automático: commit en GitHub → deploy automático.
Limitación: solo estático. Suficiente para documentación.

AWS S3 + CloudFront (para masterfinanzas.com)¶

masterfinanzas.com es una plataforma de finanzas con usuarios en toda América. Su frontend estático se sirve desde S3 (almacenamiento de objetos) con CloudFront (CDN de Amazon) delante.

Justificación técnica: el equipo ya tiene todo en AWS (RDS, Lambda, ECS). Tener también el frontend en S3+CloudFront unifica la infraestructura y simplifica la gestión IAM y los permisos.
Costo aproximado: ~$10-30/mes dependiendo del tráfico (S3 + CloudFront).
Ventaja: integración perfecta con el ecosistema AWS, latencias bajas gracias a los edge locations de CloudFront.

VPS Hetzner CX23 (para nlink.uk — URL shortener con backend)¶

nlink.uk es un servicio de acortamiento de URLs con analytics. Necesita un backend persistente (base de datos de redirecciones) y alta velocidad de respuesta.

Justificación técnica: los URL shorteners necesitan responder en <5ms para que el usuario no perciba el redirect. Un VPS en Hetzner con Redis en memoria para las URLs más populares cumple perfectamente.
Costo: $3.49/mes (Hetzner CX23: 2 vCPU, 4 GB RAM, 40 GB NVMe).
Stack: Nginx (reverse proxy) + Node.js + Redis + PostgreSQL.
Ventaja: precio imbatible para lo que ofrece.
Desventaja: los servidores de Hetzner están en Europa; para usuarios en América hay ~150ms de latencia. Mitigable con Cloudflare delante.

Hosting compartido (para primariajuanescutia.edu.mx)¶

El sitio de la primaria Juan Escutia solo necesita publicar el calendario escolar, fotos de eventos y datos de contacto. Unas decenas de visitas al día como máximo.

Justificación técnica: un VPS sería overkill. El hosting compartido por $3-5/mes con cPanel y WordPress pre-instalado es exactamente lo que necesita el maestro que lo administra sin conocimientos técnicos.
Costo: ~$3-5/mes.
Ventaja: sin mantenimiento de servidor, sin preocupaciones técnicas, panel visual para actualizar contenido.
Desventaja: si algún día el sitio crece, habrá que migrar.

Buenas prácticas¶

Elige el hosting según el proyecto, no según el precio: el hosting compartido más barato puede costarte caro en rendimiento y frustración si tu proyecto crece.
Siempre configura HTTPS: en 2026, un sitio sin HTTPS es inaceptable. Usa Caddy para HTTPS automático, Cloudflare para certificados en el edge, o Certbot con Nginx.
Separa el dominio del hosting: no compres dominio y hosting en el mismo proveedor. Así puedes cambiar de proveedor de hosting sin perder el dominio.
Configura backups automáticos desde el primer día: la pregunta no es si perderás datos, sino cuándo. Los backups diarios son el mínimo aceptable.
Monitorea el uptime: usa herramientas gratuitas como UptimeRobot para recibir alertas cuando tu sitio cae. No esperes que los usuarios te avisen.
Usa CDN para contenido estático: imágenes, CSS y JS servidos desde una CDN son más rápidos y reducen la carga en tu servidor principal.
Escala horizontal antes que vertical: añadir más servidores pequeños es más resiliente y generalmente más económico que un único servidor gigante.
Mantén el software actualizado: los exploits más comunes en servidores web atacan versiones antiguas de Nginx, Apache, PHP o WordPress. Las actualizaciones son seguridad.
Usa variables de entorno para datos sensibles: contraseñas de bases de datos, API keys y tokens nunca deben estar en el código fuente ni en el repositorio.
Lee los SLAs de tu proveedor: un 99.9% de uptime suena bien, pero implica ~8.7 horas de downtime/año. Si tu negocio no puede permitirse eso, necesitas Tier III o superior.

Errores comunes¶

Comprar el plan más barato sin verificar los recursos: el hosting compartido de $1.99/mes puede tener restricciones de CPU y I/O tan agresivas que el sitio sea inutilizable bajo carga mínima. Lee las letras pequeñas sobre límites de CPU, inodos y conexiones de BD.
No configurar HTTPS en desarrollo local: ignorar HTTPS en desarrollo crea hábitos incorrectos. Usa mkcert para certificados locales o Caddy, y acostúmbrate a trabajar con HTTPS desde el principio.
Creer que la nube es infinitamente gratuita: AWS, GCP y Azure tienen free tiers que expiran o tienen límites. Una Lambda que se llama millones de veces o un S3 que almacena terabytes puede generar facturas de cientos o miles de dólares. Configura siempre alertas de presupuesto (billing alerts).
Poner el servidor en el continente equivocado: si tu audiencia está en México y tu servidor está en Frankfurt sin CDN, estás añadiendo ~150ms de latencia innecesaria a cada petición. Elige la región más cercana a tus usuarios principales.
No separar entornos de desarrollo, staging y producción: hacer cambios directamente en producción es una receta para desastres. El mínimo aceptable es tener un entorno de staging donde probar antes de desplegar.
Ignorar los logs del servidor: Nginx y Apache generan logs detallados de cada petición, error y anomalía. No leerlos es como conducir con los ojos cerrados. Los logs revelan ataques en curso, errores de configuración y cuellos de botella.
No configurar límites de recursos en VPS no gestionado: un proceso que se descontrola puede consumir toda la CPU o RAM del VPS y derribar el servidor. Configura límites con systemd o Docker.
Confundir reinicio del servidor con reinicio del servicio: cuando Nginx deja de responder, no es necesario reiniciar el VPS completo (eso genera downtime). En casi todos los casos, un systemctl restart nginx es suficiente y tarda segundos.

Curiosidades¶

El servidor web más antiguo del mundo aún funciona: el primer servidor web del mundo, instalado por Tim Berners-Lee en el CERN en 1990 en una NeXT Computer, fue apagado en 1991... pero el CERN lo restauró y está disponible en http://info.cern.ch. Es literalmente el primer sitio web de la historia.
Facebook usó PHP durante años para servir a mil millones de usuarios: ante la sorpresa de muchos puristas, Facebook corrió PHP masivamente hasta muy recientemente. Lo hicieron escalar creando HipHop (un compilador PHP a C++) y luego HHVM (HipHop Virtual Machine). La herramienta no es el límite; la ingeniería sí importa.
Los cables submarinos de Internet son delgados como una manguera: a pesar de cruzar océanos y transportar petabits de datos por segundo, los cables submarinos tienen el diámetro de una manguera de jardín en alta mar (donde el riesgo de daño es menor) y el de un brazo humano cerca de las costas (donde hay protección adicional).
Un solo rack de servidores puede consumir más electricidad que 10 hogares: los servidores modernos de alta densidad generan tanto calor que algunos centros de datos los sumergen literalmente en aceite dieléctico para refrigerarlos. Microsoft probó en 2018 sumergir un datacenter entero en el fondo del mar (Proyecto Natick) y el resultado fue sorprendente: el hardware fallaba mucho menos que en tierra, probablemente porque la atmósfera controlada eliminó la humedad y las micropartículas.
Cloudflare bloquea ~136 mil millones de amenazas cibernéticas al día: como proxy de millones de sitios, Cloudflare tiene una visibilidad sin precedente del tráfico de Internet. Cada ataque DDoS que detecta en un sitio entrena sus sistemas para proteger a todos los demás. Es un modelo de seguridad colectiva único en la industria.

Resumen del capítulo¶

En este capítulo exploramos el corazón de cómo funciona Internet: los servidores web.

Comenzamos con lo fundamental: un servidor es una computadora que espera peticiones y las responde, bajo el modelo cliente-servidor que es la base de toda la web. Distinguimos entre el hardware físico y el software servidor, y cómo sobre un mismo hardware pueden correr decenas de servidores lógicos.

Analizamos el flujo completo de una petición web, conectando con el DNS del capítulo anterior: desde que el usuario escribe una URL, pasa por la resolución DNS, la conexión TCP, el handshake TLS, el procesamiento en el servidor y la base de datos, hasta que el HTML llega al navegador.

En la sección de hardware vimos cómo la CPU, la RAM y el tipo de disco (HDD, SSD, NVMe) determinan el rendimiento de un servidor, y cómo los centros de datos garantizan disponibilidad con redundancia energética, refrigeración y múltiples conexiones de red.

Linux domina el 59.4% del mercado de servidores, y Ubuntu es la distribución más usada. Entendemos por qué: es gratuito, estable, eficiente y tiene el mayor ecosistema de soporte.

De los servidores web, Nginx lidera con el 31.9% del mercado gracias a su arquitectura event-driven que resuelve el problema C10K. Apache (23.1%) domina el hosting compartido gracias al .htaccess. LiteSpeed (15.2%) es el favorito de WordPress. Caddy destaca por su HTTPS automático. Cloudflare (28.5%) actúa como edge proxy delante de millones de servidores.

En los tipos de hosting, encontramos el espectro completo: desde el hosting compartido a $3/mes (ideal para primariajuanescutia.edu.mx) hasta los VPS con precios imbatibles como el Hetzner CX23 a $3.49/mes, pasando por cloud computing con auto-scaling, serverless (AWS Lambda, Firebase Functions) y edge computing (Cloudflare Workers con cold starts de <5ms).

Las plataformas modernas de JAMstack —GitHub Pages, Cloudflare Pages, Netlify, Vercel, Firebase Hosting— han democratizado el despliegue profesional. Cloudflare Pages con ancho de banda ilimitado y Vercel con su integración perfecta con Next.js son los grandes protagonistas.

Las arquitecturas modernas van más allá del sitio dinámico clásico: SSG, SSR, ISR, JAMstack, serverless y microservicios son paradigmas con sus propios casos de uso, y el árbol de decisión del capítulo te ayuda a elegir el correcto.

El balanceador de carga garantiza alta disponibilidad: si un servidor cae, el tráfico se redistribuye automáticamente. La virtualización —VMs con KVM, contenedores con Docker— permite aprovechar al máximo el hardware y garantizar reproducibilidad. Kubernetes orquesta esos contenedores a escala.

Finalmente, los casos reales —elprofe.org en Cloudflare Pages y Firebase, nlink.uk en Hetzner VPS, masterfinanzas.com en AWS— ilustran cómo aplicar estos conocimientos a decisiones de infraestructura concretas con costos reales.

Glosario¶

Alta disponibilidad (High Availability, HA): arquitectura diseñada para minimizar el tiempo de inactividad, generalmente mediante redundancia de componentes.

Apache HTTP Server: servidor web de código abierto, lanzado en 1995, conocido por su flexibilidad y el archivo .htaccess.

Auto-scaling: capacidad de un sistema cloud de añadir o eliminar instancias de servidor automáticamente según la demanda.

Balanceador de carga (Load Balancer): componente que distribuye el tráfico entrante entre múltiples servidores backend.

Bare metal: servidor físico dedicado, sin capa de virtualización.

CDN (Content Delivery Network): red de servidores distribuidos geográficamente que sirven contenido desde el nodo más cercano al usuario.

Caddy: servidor web moderno con HTTPS automático por defecto via Let's Encrypt.

Cloudflare Workers: plataforma de edge computing que usa V8 isolates para ejecutar JavaScript en más de 310 ubicaciones con cold starts de <5ms.

Cold start: tiempo que tarda en inicializar una función serverless o un worker cuando no estaba activo previamente.

Contenedor (Container): unidad de software que empaqueta código y dependencias, compartiendo el kernel del SO host. Más ligero que una VM.

Docker: plataforma de contenedores que permite empaquetar aplicaciones con todas sus dependencias en imágenes reproducibles.

Edge computing: modelo de computación que procesa datos en nodos distribuidos cercanos al usuario, en lugar de en un datacenter centralizado.

Escalado horizontal (Scale Out): añadir más servidores a un sistema para distribuir la carga.

Escalado vertical (Scale Up): aumentar los recursos (CPU, RAM) de un servidor existente.

FaaS (Function as a Service): modelo serverless donde se despliegan funciones individuales que se ejecutan bajo demanda.

Hipervisor: software que crea y gestiona máquinas virtuales. Tipos: Tipo 1 (bare-metal, como KVM) y Tipo 2 (hosted, como VirtualBox).

Hosting compartido: servicio donde múltiples sitios web comparten recursos de un mismo servidor físico.

HTTP (HyperText Transfer Protocol): protocolo de comunicación base de la web para transferencia de datos.

HTTPS: versión segura de HTTP, cifrada con TLS/SSL.

ISR (Incremental Static Regeneration): técnica de Next.js que actualiza páginas estáticas de forma incremental sin recompilar todo el sitio.

JAMstack: arquitectura web basada en JavaScript, APIs y Markup pre-generado.

KVM (Kernel-based Virtual Machine): hipervisor de Tipo 1 integrado en el kernel de Linux, base de la mayoría de VPS comerciales.

Kubernetes: sistema de orquestación de contenedores que automatiza el despliegue, escalado y gestión de aplicaciones en contenedores.

Latencia: tiempo que tarda en llegar el primer byte de datos desde el servidor hasta el cliente.

Let's Encrypt: autoridad de certificación gratuita que emite certificados TLS/SSL automatizables.

LiteSpeed: servidor web compatible con Apache, con mejor rendimiento y soporte nativo de HTTP/3.

Nginx: servidor web event-driven, líder global con 31.9% de cuota de mercado, creado por Igor Sysoev en 2004.

NVMe (Non-Volatile Memory Express): protocolo de almacenamiento de alta velocidad para SSDs, con latencias de ~0.02ms.

Proxy inverso (Reverse Proxy): servidor que recibe peticiones de clientes y las reenvía a servidores backend, actuando como intermediario.

Round-robin: algoritmo de balanceo de carga que distribuye peticiones de forma circular entre los servidores disponibles.

Serverless: modelo de computación donde el proveedor gestiona la infraestructura y el desarrollador solo escribe funciones.

SPA (Single Page Application): aplicación web que carga una sola vez y actualiza el DOM dinámicamente.

SSG (Static Site Generation): generación de todas las páginas HTML en tiempo de compilación, antes de recibir peticiones.

SSR (Server-Side Rendering): generación del HTML en el servidor por cada petición del cliente.

Tier (Uptime Institute): clasificación de centros de datos del I al IV, indicando nivel de redundancia y disponibilidad garantizada.

UPS (Uninterruptible Power Supply): sistema de alimentación ininterrumpida que protege los equipos de cortes de energía.

V8 isolates: mecanismo de aislamiento del motor JavaScript de Google (V8) que permite ejecutar múltiples instancias de código con overhead mínimo.

Virtualización: tecnología que permite ejecutar múltiples sistemas operativos o entornos aislados sobre un mismo hardware físico.

VPS (Virtual Private Server): servidor virtual con recursos dedicados garantizados, creado mediante virtualización sobre hardware físico compartido.

20 Preguntas de autoevaluación¶

Opción múltiple (10 preguntas)¶

1. ¿Cuál es la arquitectura fundamental que permite a Nginx manejar decenas de miles de conexiones simultáneas con bajo consumo de memoria?

a) Proceso por conexión (prefork)
b) Thread por conexión (worker)
c) Event-driven asíncrona y no bloqueante ✅
d) Microkernel multihilo

2. Según los datos de W3Techs de junio 2026, ¿cuál es el servidor web con mayor cuota de mercado?

a) Apache (23.1%)
b) LiteSpeed (15.2%)
c) Cloudflare (28.5%)
d) Nginx (31.9%) ✅

3. ¿Cuál de las siguientes plataformas de hosting estático ofrece ancho de banda ilimitado en su free tier?

a) Netlify (100 GB/mes)
b) GitHub Pages (100 GB/mes)
c) Firebase Hosting (10 GB/mes)
d) Cloudflare Pages (ilimitado) ✅

4. Un VPS Hetzner CX23 cuesta $3.49/mes en 2026. ¿Qué recursos incluye?

a) 1 vCPU, 1 GB RAM, 25 GB SSD
b) 4 vCPU, 8 GB RAM, 80 GB NVMe
c) 2 vCPU, 4 GB RAM, 40 GB NVMe ✅
d) 2 vCPU, 2 GB RAM, 50 GB HDD

5. ¿Qué característica diferencia a Cloudflare Workers de AWS Lambda en términos de cold start?

a) Workers usa contenedores Docker más pequeños
b) Workers usa máquinas virtuales optimizadas para arranque rápido
c) Workers no tiene cold start porque es serverless puro
d) Workers usa V8 isolates (no contenedores), logrando <5ms vs 100-500ms de Lambda ✅

6. ¿Cuál es la diferencia fundamental entre escalado vertical y horizontal?

a) El vertical usa más ancho de banda; el horizontal usa más CPU
b) El vertical aumenta recursos de un servidor existente; el horizontal añade más servidores ✅
c) El vertical usa cloud; el horizontal usa servidores dedicados
d) El vertical es automático; el horizontal es manual

7. ¿Qué significa que un centro de datos es Tier III según el Uptime Institute?

a) Tiene 99.995% de uptime y menos de 26 minutos de downtime al año
b) Tiene 99.671% de uptime sin redundancia
c) Tiene 99.982% de uptime, máximo 1.6 horas de downtime/año, con N+1 fault tolerance ✅
d) Tiene 99.741% de uptime con redundancia parcial

8. Para un nuevo proyecto con Next.js que necesita SSR, ¿cuál sería la plataforma de hosting más indicada?

a) GitHub Pages (no soporta SSR, solo estático)
b) Firebase Hosting (optimizado para SPAs y estático)
c) Vercel (creada por el mismo equipo de Next.js, soporte nativo de SSR/ISR) ✅
d) AWS Amplify (requiere configuración manual del SSR)

9. ¿Por qué Linux domina los servidores web frente a Windows Server?

a) Porque Linux tiene mejor soporte para aplicaciones .NET
b) Porque Linux tiene interfaz gráfica más completa para administración
c) Porque Windows Server no soporta bases de datos
d) Por ser gratuito, estable, eficiente en recursos, y tener mejor ecosistema de herramientas web ✅

10. ¿Qué es el archivo .htaccess en el contexto de Apache?

a) Un archivo de configuración de SSL/TLS
b) Un archivo de registro de accesos (access log)
c) Un archivo de configuración de Apache que puede existir en cualquier directorio y que usuarios sin acceso root pueden modificar ✅
d) Un archivo de hash de contraseñas del sistema

Verdadero o falso (5 preguntas)¶

11. Firebase Hosting en su free tier incluye ancho de banda ilimitado.

FALSO ✅ — El plan Spark de Firebase Hosting incluye 10 GB de almacenamiento y 10 GB/mes de transferencia. El ancho de banda ilimitado en free tier lo ofrece Cloudflare Pages.

12. Un contenedor Docker arranca generalmente en menos de 1 segundo, mientras que una máquina virtual tarda entre 30 y 60 segundos.

VERDADERO ✅ — Los contenedores comparten el kernel del SO host y no necesitan arrancar un sistema operativo completo, lo que les da ese tiempo de inicio casi instantáneo.

13. Cloudflare (28.5% de cuota según W3Techs) es un servidor web tradicional que reemplaza completamente a Nginx o Apache.

FALSO ✅ — Cloudflare es un edge proxy/CDN que se coloca delante de cualquier servidor. Necesita un servidor de origen (Nginx, Apache, etc.) detrás, aunque puede servir contenido cacheado sin contactar el origen.

14. El modelo serverless es ideal para procesos de larga duración como renderizado de video o análisis de grandes datasets.

FALSO ✅ — Serverless tiene límites de tiempo de ejecución (AWS Lambda: máximo 15 minutos) y no es adecuado para procesos prolongados. Es ideal para tareas cortas y stateless.

15. El crecimiento de Cloudflare como "servidor web" en las estadísticas de W3Techs refleja el aumento de sitios que usan Cloudflare como proxy, no que Cloudflare haya creado un nuevo servidor web tradicional.

VERDADERO ✅ — Cloudflare aparece en las estadísticas porque actúa como intermediario (proxy inverso en el edge) delante de millones de sitios. Su "servidor web" es el edge proxy, no una aplicación equivalente a Nginx.

Respuesta corta (5 preguntas)¶

16. Explica con tus propias palabras la diferencia entre hosting, dominio y DNS, usando elprofe.org como ejemplo.

Respuesta modelo: El dominio elprofe.org es el nombre que los usuarios escriben; es solo una etiqueta legible por humanos. El DNS es el sistema de directorio que traduce elprofe.org a una dirección IP (como 104.21.x.x), para que los navegadores sepan a qué máquina conectarse. El hosting es el servicio que proporciona el servidor donde realmente viven los archivos y la aplicación de elprofe.org. Sin los tres, el sitio no funciona: necesitas el nombre (dominio), el directorio (DNS) y la ubicación física (hosting).

17. ¿Por qué Igor Sysoev creó Nginx en 2004? ¿Qué problema resolvía?

Respuesta modelo: Sysoev creó Nginx para resolver el problema C10K: la incapacidad de los servidores web de la época (basados en el modelo de un proceso por conexión, como Apache prefork) de manejar 10,000 conexiones simultáneas sin consumir cantidades impracticables de RAM. Con 10,000 procesos concurrentes, incluso un servidor potente se quedaba sin memoria. Nginx resolvió esto con una arquitectura event-driven y asíncrona: pocos workers manejando miles de conexiones mediante eventos, sin bloquear.

18. ¿En qué situación concreto recomendarías usar hosting compartido versus un VPS para un proyecto educativo?

Respuesta modelo: Recomendaría hosting compartido para un sitio institucional pequeño como primariajuanescutia.edu.mx: pocas visitas diarias, contenido principalmente estático (calendario, noticias), sin necesidad de tecnologías especiales (PHP + MySQL es suficiente), administrado por alguien sin conocimientos de administración de servidores, y con presupuesto mínimo ($3-5/mes). Recomendaría un VPS para elprofe.org en crecimiento: necesita Node.js (que hosting compartido generalmente no soporta bien), tiene tráfico variable que podría saturar recursos compartidos, y requiere configuraciones personalizadas como variables de entorno, cron jobs y conexiones a servicios externos.

19. ¿Cuál es la ventaja principal de ISR (Incremental Static Regeneration) sobre SSG puro en un sitio educativo con contenido que cambia frecuentemente?

Respuesta modelo: Con SSG puro, cada vez que cambia el contenido (se añade un nuevo curso, se actualiza una lección) hay que hacer un rebuild completo del sitio, que puede tardar minutos en sitios grandes. Con ISR de Next.js, las páginas se pre-generan estáticamente (como SSG) pero se revalidan automáticamente cada N segundos o bajo demanda. Así, cuando elprofe.org añade un nuevo curso, solo esa página se regenera en el servidor, no todo el sitio. El resultado es la velocidad del sitio estático con la frescura de un sitio dinámico.

20. Describe tres diferencias técnicas clave entre máquinas virtuales (VMs) y contenedores Docker.

Respuesta modelo: (1) Nivel de aislamiento: las VMs tienen su propio kernel de SO completo, son completamente independientes del host. Los contenedores comparten el kernel del SO host, por lo que son menos aislados pero mucho más eficientes. (2) Tiempo de arranque: una VM tarda entre 30-60 segundos en arrancar (debe iniciar el SO invitado). Un contenedor Docker arranca en menos de 1 segundo porque no hay OS que cargar. (3) Overhead de recursos: una VM necesita reservar RAM y CPU para el SO invitado (aunque no use la aplicación esos recursos). Un contenedor solo usa los recursos que realmente necesita la aplicación, con un overhead menor al 5%.

Proyecto práctico: Diseña la infraestructura de una plataforma educativa moderna¶

Contexto del proyecto¶

Has sido contratado como arquitecto de soluciones para diseñar la infraestructura de una nueva plataforma educativa similar a elprofe.org. La plataforma debe soportar:

Catálogo de cursos con videos y materiales descargables
Sistema de autenticación de estudiantes y docentes
Exámenes online con calificación automática
Generación de certificados/credenciales digitales en PDF
Dashboard de seguimiento del progreso del estudiante
Blog educativo con artículos y recursos

1. Análisis de requisitos¶

Tráfico esperado (estimaciones conservadoras para el primer año): - 500 usuarios registrados al lanzamiento, creciendo a 5,000 en 12 meses - Pico de concurrencia: 200 usuarios simultáneos durante exámenes programados - Transferencia estimada: 200-500 GB/mes (incluyendo videos) - Videos alojados externamente (YouTube/Vimeo) para no cargar el hosting de video

Tipos de contenido: - Frontend SPA/SSR: HTML, CSS, JS (~50 MB total) - API backend: endpoints REST/GraphQL para cursos, usuarios, exámenes - Base de datos: usuarios, cursos, progresos, exámenes (~1-5 GB) - Archivos PDF generados: certificados (~100 KB cada uno) - Imágenes: miniaturas de cursos, avatares (~5 GB)

2. Decisiones de arquitectura y justificación¶

Componente	Decisión	Justificación
Frontend	Next.js con SSR/SSG	SEO para cursos, ISR para contenido actualizable
Hosting frontend	Cloudflare Pages	Edge global, bandwidth ilimitado, integración con Workers
Backend/API	Firebase Cloud Functions (serverless)	Escalado automático, pago por uso, integración con Firestore
Base de datos	Firestore + Firebase RTDB	Tiempo real para exámenes, SDK multiplataforma
Autenticación	Firebase Auth	Google, email/password, magic links; sin código de auth propio
Almacenamiento	Firebase Storage / Cloudflare R2	PDFs y assets; R2 sin costo de egress
CDN	Cloudflare (incluido)	Automático con Cloudflare Pages y Workers
Certificados SSL	Cloudflare (incluido)	Automático, renovación automática
DNS	Cloudflare DNS	Propagación rápida, integración nativa
Monitoreo	Cloudflare Analytics + Firebase	Sin costo adicional en ambas plataformas

3. Diagrama ASCII de la arquitectura completa¶

┌─────────────────────────────────────────────────────────────────────────┐
│              ARQUITECTURA DE PLATAFORMA EDUCATIVA MODERNA               │
│                                                                         │
│   USUARIOS (Estudiantes y Docentes)                                     │
│        │                                                                │
│        ▼                                                                │
│   ┌─────────────────────────────────────────┐                          │
│   │         CLOUDFLARE EDGE (310+ ciudades) │                          │
│   │  ┌──────────────┐  ┌──────────────────┐ │                          │
│   │  │  DNS / SSL   │  │  DDoS Protection │ │                          │
│   │  └──────────────┘  └──────────────────┘ │                          │
│   │  ┌──────────────────────────────────── ┐ │                          │
│   │  │         Cloudflare Pages             │ │                          │
│   │  │    (Next.js Frontend - SSR/SSG)      │ │                          │
│   │  │    elprofe.org  — HTML/CSS/JS       │ │                          │
│   │  └───────────────────┬─────────────────┘ │                          │
│   └─────────────────────┼─────────────────────┘                        │
│                         │ API calls                                     │
│                         ▼                                               │
│   ┌─────────────────────────────────────────────────────────────────┐   │
│   │                    FIREBASE (Google Cloud)                      │   │
│   │                                                                 │   │
│   │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │   │
│   │  │ Firebase     │  │  Firestore   │  │  Cloud Functions     │  │   │
│   │  │ Auth         │  │  (NoSQL DB)  │  │  (Serverless)        │  │   │
│   │  │              │  │              │  │                      │  │   │
│   │  │ - Google     │  │ - Usuarios   │  │ - API REST          │  │   │
│   │  │ - Email/pass │  │ - Cursos     │  │ - Generar PDF cert  │  │   │
│   │  │ - Magic link │  │ - Exámenes   │  │ - Notificaciones    │  │   │
│   │  │              │  │ - Progreso   │  │ - Webhooks          │  │   │
│   │  └──────────────┘  └──────────────┘  └──────────────────────┘  │   │
│   │                                                                 │   │
│   │  ┌──────────────────────────────────────────────────────────┐   │   │
│   │  │  Firebase Storage / Cloudflare R2                        │   │   │
│   │  │  (PDFs certificados, imágenes de cursos, materiales)     │   │   │
│   │  └──────────────────────────────────────────────────────────┘   │   │
│   └─────────────────────────────────────────────────────────────────┘   │
│                                                                         │
│   SERVICIOS EXTERNOS:                                                   │
│   ┌──────────────┐  ┌──────────────┐  ┌──────────────────────────┐     │
│   │  YouTube /   │  │  SendGrid /  │  │  Stripe / PayPal         │     │
│   │  Vimeo       │  │  Resend      │  │  (pagos futuros)         │     │
│   │  (videos)    │  │  (emails)    │  │                          │     │
│   └──────────────┘  └──────────────┘  └──────────────────────────┘     │
└─────────────────────────────────────────────────────────────────────────┘

4. Comparativa de costos mensuales¶

Opción A: Hosting compartido tradicional

Servicio	Proveedor	Costo/mes
Hosting compartido	Bluehost/SG	$8.99
Dominio	Namecheap	$1.00
SSL (incluido en hosting)	—	$0
CDN externo	Cloudflare free	$0
Base de datos	Incluida (MySQL)	$0
Email transaccional	Mailchimp free	$0
Total aproximado		~$10/mes

Limitaciones graves: no soporta Node.js, sin auto-scaling, problemas con picos de tráfico, PHP solamente, sin generación de PDFs serverless.

Opción B: VPS Hetzner + stack propio

Servicio	Proveedor	Costo/mes
VPS CX33 (4 vCPU, 8 GB RAM)	Hetzner	$7.49
Dominio	Namecheap	$1.00
SSL (Let's Encrypt + Caddy)	—	$0
CDN	Cloudflare free	$0
Backup (Hetzner)	Hetzner	$1.50
Base de datos (en VPS)	—	$0
Monitoring básico	UptimeRobot free	$0
Total aproximado		~$10/mes

Requiere administración del servidor Linux, configuración de Nginx, gestión de backups, actualizaciones de seguridad manuales. Tiempo técnico: 2-4 horas/mes mínimo.

Opción C: Cloudflare Pages + Firebase (recomendado)

Servicio	Proveedor	Costo/mes
Hosting frontend	Cloudflare Pages	$0
Backend serverless	Firebase Functions	$0*
Base de datos	Firestore	$0*
Autenticación	Firebase Auth	$0*
Almacenamiento (PDFs)	Firebase Storage	$0*
CDN	Cloudflare (incl.)	$0
SSL/TLS	Cloudflare (incl.)	$0
Dominio	Namecheap	$1.00
Email transaccional	Resend free tier	$0
Total aproximado		~$1/mes

* Hasta los límites del plan gratuito (Spark/free). Con 5,000 usuarios activos, el plan Blaze de Firebase cobrará ~$5-20/mes por uso adicional.

Máxima escalabilidad, cero administración de servidores, HTTPS automático, despliegue continuo desde GitHub.

Opción D: AWS completo

Servicio	Proveedor	Costo/mes
S3 (frontend + assets)	AWS	$3-5
CloudFront (CDN)	AWS	$5-15
Lambda (backend serverless)	AWS	$5-20
RDS PostgreSQL (db.t3.micro)	AWS	$15-25
Route 53 (DNS)	AWS	$0.50
Certificate Manager (SSL)	AWS	$0
SES (email transaccional)	AWS	$1-3
Dominio	Namecheap	$1
Total aproximado		~$30-70/mes

Requiere expertise en AWS, configuración de IAM, VPC, security groups. Alta complejidad operativa para un proyecto inicial.

5. Tabla comparativa de las 4 opciones¶

Criterio	A: Compartido	B: VPS Hetzner	C: CF+Firebase	D: AWS completo
Costo/mes	~$10	~$10	~$1-20	~$30-70
Dificultad técnica	Muy baja	Alta	Baja	Muy alta
Escalabilidad	Ninguna	Manual	Automática	Automática
HTTPS automático	Básico	Manual (Caddy)	✅ Automático	✅ Automático
Node.js/Python	❌ No	✅ Sí	✅ Sí	✅ Sí
Administración	Proveedor	Tú mismo	Proveedor	Tú mismo/AWS
Tiempo a producción	1 hora	1 día	2 horas	1 semana
Adecuación al proyecto	Baja	Media	Alta	Media-Alta
Vendor lock-in	Bajo	Ninguno	Medio	Alto
Free tier real	Básico	No	Muy generoso	Limitado

6. Recomendación final justificada¶

Recomendación: Opción C — Cloudflare Pages + Firebase

Para un proyecto educativo en sus primeras fases con un equipo pequeño (típicamente 1-3 personas), la Opción C es la decisión correcta por las siguientes razones:

Economía real: comenzar con $0-$1/mes permite validar la idea antes de invertir en infraestructura. Si el proyecto no despega, no hay costos de servidor. Si despega, el escalado es automático y el costo crece proporcionalmente a los ingresos.

Cero administración de servidores: el tiempo que un desarrollador independiente o docente gastaría administrando un VPS (actualizaciones, backups, monitoreo, incidencias) es tiempo que no está dedicando al producto. Firebase y Cloudflare gestionan toda la infraestructura.

Escalabilidad probada: Cloudflare Pages sirve sitios a escala global para empresas Fortune 500. Firebase soporta apps con millones de usuarios. Si elprofe.org crece de 500 a 50,000 usuarios, la infraestructura escala sin cambiar de proveedor ni reconfigurar nada.

HTTPS y CDN incluidos: en 2026 no tiene sentido pagar por SSL ni configurar una CDN manualmente. Ambas vienen incluidas y automáticas.

Migración futura sencilla: si en el futuro la plataforma requiere más control o el vendor lock-in de Firebase se vuelve problemático, los Cloud Functions son estándar Node.js y migrar a AWS Lambda o a un VPS propio es un trabajo de días, no de meses.

Cuándo reconsiderar: si el proyecto requiere bases de datos relacionales complejas (SQL con joins avanzados), procesamiento de video propio, o si el equipo tiene expertise dedicado en DevOps, el VPS (Opción B) o AWS (Opción D) serían más apropiados.

Referencias bibliográficas¶

W3Techs. (2026). Usage statistics of web servers for websites. W3Techs Web Technology Surveys. https://w3techs.com/technologies/overview/web_server
iSoumyaDey. (2026). Awesome Web Hosting 2026 — Pricing comparison and features. GitHub. https://github.com/iSoumyaDey/Awesome-Web-Hosting-2026
MarkAICode. (2025). Cloudflare Workers Edge Computing: Complete Guide 2025. MarkAICode Blog. https://markaicode.com/cloudflare-workers-edge-computing-2025/
CoreSite. (2024). Breaking Down Data Center Tiers Classifications. CoreSite Blog. https://www.coresite.com/blog/breaking-down-data-center-tiers-classifications
Atmosly. (2025). Docker Container vs Virtual Machine: Which Should You Use in 2025?. Atmosly Knowledge Base. https://atmosly.com/knowledge/docker-container-vs-virtual-machine-which-should-you-use-in-2025
CommandLinux. (2025). Linux Web Server Market Share Statistics (December 2025). CommandLinux. https://commandlinux.com/statistics/linux-web-server-market-share/
Cloudflare. (2026). Cloudflare Workers documentation. Cloudflare Developers. https://developers.cloudflare.com/workers/
Firebase. (2026). Firebase Hosting pricing and quotas. Firebase Documentation — Google. https://firebase.google.com/docs/hosting/usage-quotas-pricing
Nginx, Inc. (2026). NGINX documentation — Architecture overview. NGINX Docs. https://nginx.org/en/docs/
Uptime Institute. (2023). Tier Standard: Topology (Data Center Site Infrastructure Tier Standard). Uptime Institute. https://uptimeinstitute.com/tiers
Berners-Lee, T. (1991). The original proposal of the WWW, HTMLized. CERN. https://www.w3.org/History/1989/proposal.html
VPS Prices. (2026). VPS Prices Comparison 2026. vpsprices.net. https://vpsprices.net

Adelanto del Capítulo 6: Has visto cómo los servidores reciben y procesan peticiones. Pero hay un detalle que mencionamos varias veces sin profundizar: ese https:// al inicio de cada URL y el candado en la barra del navegador. En el Capítulo 6 — HTTPS, TLS y la seguridad en la web, descubrirás cómo funciona el cifrado que protege cada conversación entre tu navegador y el servidor. Aprenderás qué es exactamente TLS, cómo funciona el handshake criptográfico que ocurre en milisegundos antes de que llegue cualquier dato, qué son los certificados SSL y quién los emite, por qué Let's Encrypt cambió el juego al hacerlos gratuitos, y cómo configurar HTTPS correctamente. También exploraremos HTTP/2 y HTTP/3, los protocolos modernos que hacen la web entre 2 y 5 veces más rápida que el HTTP clásico. Si alguna vez te has preguntado qué hay detrás de ese pequeño candado verde, el siguiente capítulo te dará todas las respuestas.