🆙 👩🏽 🍥 Costos ocultos de cambiar a microservicios 👩🏾‍🎓 🤴🏻 🤥

En un mundo ideal, podría simplemente tomar el código fuente de un monolito, dividir su código entre microservicios y, al conectarlos, obtener el mismo sistema, pero en una nueva arquitectura. Esto nunca sucede en la vida. La vida aporta mucha complejidad a esta imagen perfecta. ¿Cuáles son los desafíos específicos que pueden duplicar o triplicar su presupuesto de migración de microservicios?

Describiré los factores que están retrasando la transición a los microservicios y haciéndola mucho más cara de lo esperado inicialmente. Recibirá una lista de verificación para evaluar estos factores y será más realista al calcular el presupuesto de transición.

Hablé de este tema en ArchDays 2020 . Siga el enlace para encontrar diapositivas y videos (que se publicarán próximamente) del discurso https://blog.byndyu.ru/2020/12/archdays-2020.html .

# 1 Cambiando el enfoque para trabajar con datos maestros

Un monolito suele tener una o dos grandes bases de datos que contienen datos maestros variados. El propio monolito contiene código que gestiona estos datos maestros. Por ejemplo, si la parte "verde" de la base de datos es el directorio de direcciones, entonces el código monolito "verde" controla las direcciones. Resulta que hay muchos datos maestros en la base de datos del monolito y hay muchos sistemas maestros en el código del monolito:

En los microservicios, los datos maestros se administran de manera diferente: hay muchas bases de datos, no se pueden mezclar datos maestros entre microservicios y solo un microservicio puede administrar los datos maestros. Por ejemplo, el microservicio "verde" ahora ha recibido su propia base de datos con direcciones, y solo él puede realizar cambios en estos datos maestros. Otros microservicios pueden leer datos con direcciones, pero solo a través del microservicio "verde":