La segunda edición es más prudente que la primera y eso la mejora: define qué es un microservicio, discute acoplamiento y cohesión, muestra cómo partir un sistema que ya existe sin detenerlo, cómo separar la base de datos, cómo comunicar servicios, cómo probarlos, cómo observarlos y qué le pasa a la organización cuando lo hace.
Qué hice con él
Lo uso, sobre todo, para decir que no. La pregunta previa es si el problema es de escala técnica o de organización; si una empresa tiene un equipo y un sistema, partirlo en servicios agrega latencia, fallas parciales y una operación que no tiene quién la atienda. Eso lo digo ahora con el libro detrás y no como opinión.
Lo que sí traslado siempre es el capítulo de flujos distribuidos. Entre un ERP, el organismo tributario, el banco y el operador logístico no existe ninguna transacción que se pueda deshacer de golpe: lo que hay son pasos y compensaciones, y hay que diseñarlas. Cuando alguien pregunta qué pasa si el sistema externo acepta y el nuestro falla, la respuesta tiene que estar escrita antes, no improvisada el día que ocurre.
Y la parte de separar la base de datos me dio el argumento contra la integración por tablas compartidas. Dos sistemas que escriben en la misma tabla están casados sin contrato: ninguno puede cambiar nada sin romper al otro.
Qué dejé fuera
Casi todo lo operativo: orquestadores, mallas de servicio, despliegues progresivos. Eso necesita un equipo de plataforma, y quien no lo tiene se compra un problema permanente. También hay que decir que el libro sufre del mismo mal del que advierte: son seiscientas páginas sobre algo que la mayoría no debería hacer, y esa proporción no ayuda a que el mensaje llegue.