Description
Partiste el monolito para que los equipos dejaran de pisarse, y seis meses después una sola funcionalidad toca cinco servicios, un deploy tira abajo a otros tres, y una llamada que antes era una línea ahora falla a mitad de camino y deja al cliente pagado sin nada que entregarle. Los microservicios se venden como la cura de un monolito enredado y suelen ser una forma de convertir un problema difícil en una docena más difíciles. En el momento en que partís un sistema a través de la red, una llamada a función se vuelve un request que puede ser lento, fallar o llegar dos veces, una transacción que antes era un solo commit ahora cruza servicios que cada uno puede fallar a la mitad, y un cambio de schema se vuelve un problema de coordinación entre equipos. La mayoría del dolor de microservicios es autoinfligido: límites dibujados alrededor de sustantivos en vez de alrededor del cambio, servicios tan charlatanes que son un monolito distribuido con peor latencia, bases de datos compartidas que acoplan todo lo que se suponía que iban a separar, y ningún plan para la falla que ahora es constante. La habilidad no es correr contenedores, es saber dónde cortar, cómo deberían hablar los servicios, y cómo operar un sistema donde la red siempre está en parte rota.
Este libro te enseña a diseñar y operar microservicios que de verdad te compran la independencia que prometen, en vez de un monolito distribuido que tiene todos los costos de los servicios y ninguno de los beneficios. Arranca desde la única pregunta honesta (si de verdad los necesitás, y qué hace mejor un monolito) y la que decide todo lo demás: dónde dibujar los límites de servicio, alrededor de capacidades de negocio y de los ejes del cambio en vez de alrededor de tablas, para que un cambio típico toque un servicio y no siete. Construye la capa de comunicación con cuidado: las llamadas síncronas y sus modos de falla, la mensajería asíncrona y orientada a eventos y por qué desacopla los servicios, y los patrones que los mantienen honestos (timeouts, reintentos con backoff, idempotencia, circuit breakers, y el callejón sin salida de las transacciones distribuidas frente al patrón saga). Encara los datos de frente: una base de datos por servicio, por qué una base de datos compartida reacopla todo, y cómo mantener los datos consistentes entre servicios sin una transacción global. Después se pone operativo, porque ahí se ganan o se pierden los microservicios: cómo un request encuentra un servicio, el API gateway, la observabilidad sobre una llamada que cruza diez servicios (tracing, correlation ids, y los logs en los que vas a vivir), versionar un contrato sin romper a los consumidores, y testear un sistema que no podés correr entero en tu laptop. Cierra con la migración: estrangular un monolito una capacidad a la vez en vez de una reescritura. Los ejemplos son un sistema real, mostrado partido mal y después bien. Para ingenieros que quieren servicios que puedan cambiar de forma independiente, no un monolito desparramado por la red.
Para quién lo escribimos
Este libro es para: ingenieros y líderes que están por partir un monolito, o que ya corren una flota de servicios, y quieren que los límites, la comunicación y la realidad operativa de los microservicios trabajen a su favor en vez de volverse un monolito distribuido que nadie puede cambiar.
El atajo que nadie te regala
Los 6 pasos para volverte el arquitecto al que le confían decidir dónde se parte el sistema. El método para partir un sistema en servicios que de verdad cambian de forma independiente, en vez de un monolito distribuido con todos los costos de los microservicios y ninguna de las libertades. Un solo test decide cada movida, desde dónde dibujás el límite hasta cómo hablan los servicios, cómo aíslan sus datos y cómo se operan, para que un cambio típico toque un servicio y no siete. Pasás de un monolito que tenés miedo de tocar a servicios que se mueven solos.
- Decidí si de verdad los necesitás
- Cortá los límites por el cambio, no por las tablas
- Conectá los servicios sin volver a acoplarlos
- Aislá los datos con una base por servicio
- Operá un sistema que no te entra en la cabeza
- Migrá el monolito de a una capacidad por vez
El índice completo
- Capítulo 1: El día en que una línea de código dejó de ser segura
- Capítulo 2: ¿De verdad necesitás microservicios?
- Capítulo 3: Cortás en el lugar equivocado y una sola funcionalidad toca cinco servicios
- Capítulo 4: Cómo una cadena de llamadas entre servicios multiplica tu tiempo de caída
- Capítulo 5: ¿Y si tus servicios nunca tuvieran que esperarse entre sí?
- Capítulo 6: La red siempre está un poco rota
- Capítulo 7: El SELECT que convierte tus servicios de nuevo en un monolito
- Capítulo 8: El cliente pagó y no hay nada que revertir
- Capítulo 9: Cuando pintar una sola pantalla son cuatro llamadas de red
- Capítulo 10: El request se veía bien en todos los logs y falló igual
- Capítulo 11: Cambiaste un campo y rompiste un servicio que nunca abriste
- Capítulo 12: Por qué la gran reescritura casi nunca sale
- Capítulo 13: ¿Construiste microservicios o un monolito en la red?
