1. Del «en mi ordenador funciona» a producción
Una aplicación que solo funciona en tu portátil no le sirve a nadie. Desplegar es llevarla a un servidor donde los usuarios puedan usarla, y conseguir que siga funcionando cuando haya cien veces más visitas, cuando se caiga un disco o cuando publiques una versión nueva un viernes por la tarde. Es un trabajo a medio camino entre el desarrollo y la administración de sistemas, y en las empresas lo hacen perfiles con nombres como administrador de sistemas, DevOps o SRE.
La frase «en mi ordenador funciona» resume el problema clásico: tu equipo tiene una versión de PHP, unas librerías, unas variables de entorno y unos permisos que el servidor no tiene. Buena parte de este módulo trata de eliminar esas diferencias y automatizar el camino hasta producción para que sea repetible y aburrido. En despliegue, aburrido es un elogio.
| Entorno | Para qué | Quién lo usa |
|---|---|---|
| Desarrollo | Programar y probar mientras escribes | Cada desarrollador, en su equipo |
| Pruebas o staging | Una copia lo más parecida posible a producción para validar antes de publicar | El equipo, QA y el cliente |
| Producción | El sistema real, con datos y usuarios reales | Los usuarios; los cambios, solo por el proceso de despliegue |
2. Las piezas de una arquitectura web
Una aplicación pequeña puede vivir entera en un único servidor. A medida que crece, cada pieza se separa en su propia máquina o servicio para poder escalarla y protegerla por separado. Conocer el papel de cada pieza es lo primero para entender cualquier diagrama de arquitectura.
Una arquitectura web es como un gran restaurante
| Pieza | Función | Ejemplos |
|---|---|---|
| DNS | Traduce el nombre del dominio a la IP del servidor | BIND, Cloudflare, Route 53 |
| CDN | Copias de los ficheros estáticos repartidas por el mundo, cerca del usuario | Cloudflare, CloudFront, Fastly |
| Balanceador de carga | Reparte las peticiones entre varios servidores y deja de enviar a los que fallan | HAProxy, Nginx, balanceadores del proveedor cloud |
| Servidor web / proxy inverso | Termina HTTPS, sirve estáticos y pasa lo dinámico a la aplicación | Nginx, Apache, Caddy, Traefik |
| Servidor de aplicaciones | Ejecuta el código de la aplicación | PHP-FPM, Tomcat, Node.js |
| Base de datos | Guarda los datos de forma persistente | MySQL, MariaDB, PostgreSQL |
| Caché y colas | Guardan datos calculados y encolan tareas lentas | Redis, RabbitMQ |
Escalar: hacia arriba o hacia los lados
Cuando un servidor se queda corto hay dos caminos. Escalar verticalmente es darle más CPU y memoria: es sencillo, pero tiene un techo y el servidor sigue siendo un punto único de fallo. Escalar horizontalmente es añadir más servidores iguales detrás de un balanceador: no tiene techo práctico y, si uno cae, los demás siguen. Para escalar horizontalmente, la aplicación debe ser sin estado: nada de guardar sesiones o ficheros subidos en el disco local de un servidor concreto, sino en Redis, en la base de datos o en un almacenamiento compartido.
3. Dónde desplegar: de tu propio servidor a la nube
La gran decisión es cuánto quieres gestionar tú y cuánto delegas en un proveedor. Cuanto más delegas, menos trabajo y más rapidez, a cambio de menos control y, a veces, más coste y dependencia del proveedor.
| Modelo | Tú gestionas | El proveedor gestiona | Ejemplos |
|---|---|---|---|
| On-premise | Todo: edificio, hardware, red, sistema, aplicación | Nada | El CPD de la propia empresa |
| VPS / IaaS | Sistema operativo, software y aplicación | Hardware, red y virtualización | Hetzner, OVH, AWS EC2, Azure VM |
| PaaS | La aplicación y su configuración | Servidores, sistema, escalado | Heroku, Render, Railway, Google App Engine |
| Contenedores gestionados | Imágenes y su configuración | El clúster donde se ejecutan | Google Cloud Run, AWS ECS, Kubernetes gestionado |
| Serverless / FaaS | Solo funciones de código | Todo lo demás, y cobra por ejecución | AWS Lambda, Cloudflare Workers |
| Estático + edge | Los ficheros generados | Su distribución mundial | Vercel, Netlify, GitHub Pages |
Esta web, por ejemplo, está en Vercel: las páginas se generan como HTML al construir el proyecto y se sirven desde una red mundial, mientras que la base de datos de progreso de los usuarios es un servicio gestionado aparte. Para los proyectos del ciclo, un VPS barato con Linux es la mejor escuela, porque te obliga a entender cada pieza.
La nube no es gratis ni mágica
4. Criterios para elegir una arquitectura
- Carga esperada: usuarios simultáneos, picos (rebajas, matrículas) y crecimiento previsto.
- Disponibilidad: cuánto tiempo puede estar caída. Un 99,9 % permite casi 9 horas al año; un 99,99 %, menos de una.
- Datos: volumen, dónde deben estar alojados (el RGPD exige garantías para salir de la UE) y cómo se hacen las copias.
- Seguridad: qué se expone a internet, cómo se aíslan las piezas y quién puede entrar.
- Coste: no solo el de los servidores, también las horas de mantenimiento.
- Equipo: lo que sabe gestionar. La mejor arquitectura es la que tu equipo puede mantener de madrugada.
5. Ejercicios
Diseña la arquitectura
Propón una arquitectura de despliegue (piezas, dónde se alojan y cómo escala) para cada caso y dibuja el diagrama: 1. La web de una academia de 200 alumnos con un formulario de contacto. 2. Una tienda online que multiplica por 20 su tráfico en el Black Friday. 3. Una aplicación de gestión para un hospital con datos de pacientes.
Calcula la disponibilidad
Un proveedor garantiza un 99,95 % de disponibilidad mensual. ¿Cuántos minutos puede estar caído al mes (30 días) sin incumplir? Si tu aplicación depende de dos servicios en serie (servidor 99,95 % y base de datos 99,9 %), ¿cuál es la disponibilidad del conjunto?