Una app, una dirección
Una sola aplicación hace todo: usuarios, órdenes y pagos son módulos del mismo programa. El cliente conoce una sola dirección: tienda.com.
- Un solo código, un solo deploy, una sola base de datos.
- Para muchos sistemas, esto está bien: es simple de entender, probar y operar.
- Si hace falta más capacidad, ya lo vimos: copias detrás de un load balancer.
Se satura una parte, escalás todo
Llega un pico de pagos. La única forma de atenderlo es clonar la app entera.
- Cada copia carga los tres módulos, aunque solo pagos esté saturado.
- Pagamos memoria y CPU para usuarios y órdenes que nadie está pidiendo.
Cambiás una parte, deployás todoFalla una parte, cae todo
Cambia una línea de pagos. Para que llegue a producción hay que redeployar la app entera, copia por copia.
Un bug en pagos cuelga el proceso. Todas las copias corren el mismo código: se caen todas.
- No hay caída: el deploy es gradual, como vimos con el LB. El costo es coordinar y arriesgar todo por un cambio chico.
- Si el cambio trae un bug, el bug llega a todas las copias.
Cada parte, su propio servicio
Los módulos del monolito pasan a ser programas separados, que se hablan por la red.
- Cada servicio tiene su código, su deploy y su escalado.
- Cada uno puede tener su propio load balancer y sus réplicas.
- Idealmente, sus propios datos: nadie más toca su base.
- Suele seguir la forma de los equipos: un equipo, uno o pocos servicios.
Escalar, deployar y fallar por separado
Las mismas pruebas de antes, ahora servicio por servicio.
- El pico se absorbe con réplicas solo de pagos: 5 unidades contra 9 del monolito.
- Un deploy de órdenes no toca a usuarios ni a pagos.
- Si pagos se cae, el resto sigue andando.
Cada servicio elige su tecnología
Monolito un stack para todo
- Un lenguaje, un framework y una base para todos los módulos.
- Actualizar el framework es actualizar todo a la vez.
- Si un módulo necesita otra cosa, se arregla con lo que hay.
Servicios cada uno el suyo
- Lo único que comparten es el contrato: HTTP y JSON.
- Cada uno usa la base que le sirve y se puede reescribir sin tocar a los demás.
- Poder no es deber: cada stack nuevo es algo más para aprender, monitorear y mantener.
Los servicios siguen a los equipos
Monolito todos en el mismo código
- Un cambio de un equipo espera el deploy de todos.
- Para salir hay que coordinar: reuniones, ramas, congelamientos.
Servicios un equipo, sus servicios
- Cada equipo lo construye, lo deploya y lo opera.
- Entre equipos se acuerda el contrato, no la fecha de salida.
“Las organizaciones diseñan sistemas que copian su estructura de comunicación.” — Ley de Conway, 1967
El cliente conoce tres direcciones
Cada servicio tiene su propia dirección, y el cliente (el navegador, la app del celular) tiene que conocerlas todas.
- Mover o partir un servicio rompe a los clientes hasta que se actualicen. Y una app de celular no se actualiza cuando nosotros queremos.
- Todos los servicios quedan expuestos a internet, y cada uno repite HTTPS, autenticación y límites.
Una app web que orquesta
El cliente le habla solo a la app web, en tienda.com. Ella llama a cada servicio y arma la página.
- El cliente vuelve a conocer una sola dirección.
- Los servicios ya no están expuestos: solo la app web los ve.
- Esto tiene nombre: orquestación. La app web es el orquestador: decide a quién llamar, en qué orden, y arma el resultado.
El orquestador decide el orden
La misma página, con las mismas tres llamadas. Lo único que cambia es cómo las hace la app web.
- Orquestar = una pieza central que dirige cada paso.
- El orden y las dependencias (la orden antes que su envío) viven en su código.
Cuando falta una parte
Se cae Órdenes. ¿La página sale igual, o falla entera? Lo decide el orquestador.
- Con un hueco, Usuarios y Pagos siguen sirviendo.
- Esa decisión también es código del orquestador, página por página.
El orquestador se volvió un mini-monolito
Funciona, pero todo lo que cambia atrás pasa por la app web.
- Cada servicio nuevo = código nuevo + deploy de la app web.
- HTTPS, autenticación, límites: todo acá, para todos.
- Si se cae la app web, se cae todo, aunque los servicios estén sanos.
Lo que nos llevamos
Monolito
Simple, pero se escala, se deploya y se cae todo junto.
Servicios
Cada parte escala, se deploya y falla por su cuenta, con su tecnología y su equipo.
Orquestador
El cliente conoce una sola dirección: la app web llama a los servicios, decide el orden y qué hacer si falta una parte. A cambio, cada servicio nuevo es código y deploy suyo, y si se cae, cae todo.
Llevátela y probala
gastonprieto.github.io/
presentacion-microservicios
🧪 Animate a probar tu propia arquitectura
En el Architecture Playground armás un sistema con las piezas que vimos (clientes, servicios, load balancers, proxies, cachés, colas, brokers) y lo ponés bajo carga.
Arrancá por el preset Orden de compra y compará la versión orquestada con la coreografiada.
Abrir el playground →github.com/gastonprieto/presentacion-microservicios
🐳 En el repo también hay un laboratorio con Docker para probar lo mismo con servicios de verdad.