El desarrollo web pasó de sitios estáticos en servidores únicos a aplicaciones distribuidas en la nube que cambian varias veces al día. Si estás aprendiendo desarrollo web hoy, entender esta evolución te ayuda a saber por qué se usan microservicios, continuous integration y continuous delivery en lugar de los viejos monolitos.

¿Cómo funcionaba el desarrollo web tradicional?

En los inicios de internet, los sitios eran simples: HTML, texto, algunas imágenes y estilos básicos guardados en un servidor centralizado [0:30]. Un ejemplo claro es atomix.vg, un sitio de videojuegos cuya información completa vivía en una computadora en oficinas de Ciudad de México [1:05].

El flujo era directo y predecible:

• El usuario navegaba a la URL del sitio.
• El navegador enviaba la petición al servidor.
• El servidor respondía con el contenido.
• El navegador renderizaba todo para mostrarlo.

A este modelo, donde toda la aplicación vive en un solo bloque dentro de un servidor, se le conoce como aplicación monolítica [2:05]. Y solía acompañarse de una metodología llamada waterfall development, en la que planeación, código, desarrollo y pruebas avanzaban en línea recta hasta publicar todo de golpe [2:30].

¿Qué es una aplicación monolítica? Es una aplicación web cuyo código completo se carga y ejecuta en un solo servidor centralizado. Todas las peticiones van al mismo lugar y cualquier cambio implica volver a desplegar todo el bloque.

¿Por qué cambiaron las reglas del desarrollo web?

Las expectativas de los usuarios y la velocidad de los negocios cambiaron radicalmente. Hoy llevamos internet en el bolsillo, cualquier negocio necesita presencia online y los usuarios exigen experiencias casi perfectas. Eso obligó a las empresas a contratar más desarrolladores y a manejar technology stacks mucho más complejos [4:05].

Piénsalo así: en los 2000, un stack podía ser un servidor Java para usuarios y quizá algo en Ruby [4:30]. Lanzar la versión uno de un sitio podía tomar un año entero. La versión dos, otro año más.

En 2008, con el lanzamiento de Twitter, el ritmo cambió: pasamos de despliegues semanales a decenas de despliegues al día [5:25]. Si tu equipo no entrega varios cambios por semana, hoy se considera lento.

Platzi, por ejemplo, no usa un único lenguaje en el backend ni una sola librería en el frontend. La filosofía es elegir la tecnología correcta para cada problema específico del producto [6:30].

¿Qué son los microservicios y por qué importan?

La mayoría de las empresas abandonó el monolito y la cascada porque resultaban lentos e ineficientes frente a la competencia actual [7:50]. En su lugar, hoy domina la arquitectura de microservicios, donde la aplicación se compone de muchos módulos pequeños y autocontenidos, cada uno con una tarea precisa [8:25].

Imagina una tienda en línea. Cada acción es un microservicio independiente:

• El login del usuario.
• Agregar un producto al carrito.
• Procesar el pago.
• Registrar la dirección de envío.

Todos deben trabajar de forma orquestada, como si hubiera un director coordinándolos, para que la experiencia se sienta fluida [9:15]. Y aquí viene lo interesante: si un microservicio falla, solo se rompe esa parte y el sistema puede detectar exactamente dónde estuvo el problema.

¿Qué es un microservicio? Es un módulo pequeño y autocontenido que resuelve una tarea específica dentro de una aplicación, como el login o agregar al carrito. Funciona junto a otros microservicios sin depender de un único bloque de código.

¿Cómo se relacionan microservicios y CI/CD?

Gracias a esa modularidad, puedes aplicar continuous integration y continuous delivery, conocido como CI/CD [10:00]. Esto significa que los equipos liberan mejoras incrementales todo el tiempo: una corrección de bug, una animación nueva al agregar un producto al carrito, sin tener que rehacer el flujo completo [10:30].

CI/CD viene del mundo de DevOps, la filosofía que acerca a los equipos de desarrollo y operaciones para que el flujo de trabajo sea más ágil y la experiencia del usuario mejore constantemente [11:30].

¿Qué tecnologías marcan el desarrollo web actual?

Los stacks modernos combinan proveedores en la nube, bases de datos locales y múltiples lenguajes de programación. Las aplicaciones son cloud-native: viven completamente en la nube, no en un servidor potente dentro de una oficina [7:25].

Los pilares actuales que conviene dominar son:

• Arquitectura de microservicios para escalar y mantener el código.
• CI/CD para desplegar mejoras varias veces al día.
• DevOps como filosofía de colaboración entre desarrollo y operaciones.
• Observability, un concepto emergente con potencial de impacto similar al que tuvo CI/CD [11:10].

¿Qué es DevOps? Es la práctica que une a los equipos de desarrollo y operaciones para que el código llegue más rápido y con mejor calidad a los usuarios, apoyándose en automatización y despliegues continuos.

Entender este recorrido te da contexto para decidir qué herramientas aprender y cómo encajan en proyectos reales. ¿Qué parte de tu stack actual sigue funcionando como un monolito y cuál ya migraste a microservicios? Cuéntanos en los comentarios.