De monòlit a microserveis sense trencar-ho tot: tres patrons que explica BettaTech

En cualquier equipo de software, tarde o que emprano aparece la misma discusión. Nos quedamos con un monolito, migramos todo a microservicios, estamos haciendo la buena infraestructura para nuestro proyecto, después de leer monolito microservices de Sam Newman, la idea que más de marco es otra. Porque según este libro el objetivo no es casarte con la arquitectura perfecta. Si no aprender, a cómo evolucionar un arquitectura sin que se romba por el camino. Bienvenido a la serie del club de lectura con BetaTech, una serie en la que analizamos libros técnicos y resumimos sus ideas principales. Y en este vídeo quiero compartir tres patrones que aparecerán este libro que van a cambiar completamente la forma en la que diseñas y piensas en tus sistemas. En este libro nos encontramos una serie de patrones para poder agarrar nuestros ojos. y si hace falta separarlo en microservicios, pero siguiendo un proceso, siguiendo una serie de estructuras que simplifican y se aseguran de que no te cargas nada por el camino. De hecho, el primer patrón que te voy a compartir de este libro es un patrón que yo sin darme cuenta, había estado utilizando durante años, era una empresa en la que había trabajado. Es un patrón con un nombre un poquito curioso, y es que es el patrón de la igera extangulante. O tienes este nombre de Martin Fawler, que hace unos años a día de escrito este patrón, realizando la analogía de una igera. Martín Fawler describía un amigo específico que dejaba las semillas en las copas de los árboles y luego iba, descendiendo hasta que dejaba la raíz al fondo del árbol grande del árbol original. Poco a poco esta igera iba creciendo rodeando el árbol que le hacía de soporte hasta envolverlo por completo y al cabo de los años te da más cuenta de que el árbol que había dentro del árbol original.

Había muerto. Martín Favler utiliza esta analogía para describir el patrón de Iguera estrangulante en Ingeniería de software. Para verlo en el mundo del desarrollo el árbol troncal el árbol original, el que le da estructura a la Iguera, sería la parte de tu sistema que tú quieres eliminar. La parte del sistema que quieres migrar, por ejemplo. El monolito, lo nuevo que va a desarrollando es decir, el nuevo sistema haría el papel de la igera y iria creciendo alrededor del sistema original para luego, cuando todo ya está mirado, cambiará el tráfico, hacer que lo que antes era el tronco, lo que antes era el monolito, ya no reciba más información y ahora lo reciba el nuevo sistema. A la práctica, estás estrangulando tu monolito. Como ves este patrón ayuda a migrar las cosas de forma incremental sin tener que estar jugando todo el rato en cambiar su fuerte puede estar funcionando en producción. Eso es solamente en el momento en que ya lo tienes todo implementado que lo tienes este lado y que te has asegurado de que lo nuevo funciona en el que realizas este cambio de tráfico. Y de hecho, yo aprendí que este patrón se llamaba.

es Tragner Fick, precisamente gracias a este libro, pero yo ya había estado trabajando con este patron sin saberlo durante muchos años. En una de mis primeras experiencias laborales, teníamos todo desplegado en un UBS, en un servidor dedicado en el que teníamos nuestro monolito, un servidor en Node, hecho con JavaScript, muy sencillo que era una app. poco a poco, quisimos ir profesionalizando todo nuestro producto y acabamos migrando también a Amazon Web Services, con todos los cambios que yo implica que si podemos utilizar funciones serverles que si podemos utilizar contenedores, por lo tanto, tuvimos que hacer un proceso de migración que llevo bastante tiempo. Concretamente primero, nos movimos a una instancia dedicada en AWS, desplegamos ahí nuestro servidor y poco a poco fuimos utilizando el patrón de Stranger Fick para acabar moviendo la funcionalidad a funciones serverles a funciones LAM. Todo esto sin saber cómo se llamaba el patrón por lo tanto, a ver visto qué. exactamente tenía un nombre en este libro, me sirvió mucho para ver que realmente habíamos tomado el camino adecuado. Pero este libro no habla solamente de migración de código que puede ser la parte sencilla. El problema real viene cuando te das cuenta de que los datos siguen perteneciendo al servicio anterior, siguen estando de forma monolítica. Vamos a ver cómo lo soluciona o que propuestas da San Niuman en este libro. Disque cuando tu sé para hacer código en su propio repositorio, en...

otra apiristinta, con su propio despliegue, incluso a veces con otro lenguaje de programación diferente, sientes como que o esto implementando microservicios en un arquitecto super escalable, pero luego te das cuenta de que... Todos los microservicios están atacando a la misma base de datos y tienen los mismos permisos y el mismo acceso, cosa que puede ser un riesgo puede ser un problema. Ya que no estén a buscar otra pregunta, ya no es simplemente dónde está colocado físicamente mi código, sino a qué tiene acceso de quién son cada uno de los datos, de quién son los flujos de los diferentes usuarios. El capítulo cuatro de este libro se llama literalmente descomponiendo la base de datos, y empieza con el patrón que hemos presentado la base de compartida, el argumento que presenta en este libro y lo ha sido de tormenta es el siguiente. Si el comportamiento que cambia el estado es decir, el código está ahora distribuido alrededor del sistema, asegurarse de que el estado es decir, los datos se mantienen consistent en las diferentes máquinas es un problema peligroso. Maneras de diferenciar los datos y poder hacer un aislamiento en los diferentes microservicios. Y rompen uno de los grandes mitos que se han vivido o se han leído históricamente sobre los microservicios. Y es que cada microservicios de va a tener su propia base de datos. El martín y has dicho que lo tenemos que aislar que no tenemos que compartir la misma base de datos. Por lo tanto, me voy a levantar un postgrese cual aquí yo, un postgrese cual allá y un postgrese cual allá. No es necesario.

Depende del patrón que escogas puedes hacer diferentes soluciones. El primer patrón que se presenta en el libro es utilizar vistas en la base de la base. Una vista te permite generar una representación transformada, sobre los datos que tenemos por debajo en nuestras vasedaditos. Ya alguna forma, generas como una tabla virtual que te permite leer la información ya preparada según las necesidades de cada servicio. Esto lo que te permite es tener una vasedadito global, pero tener microservicios que tienen acceso solamente a la información que tú quieres que vean, porque les ha generado unas vistas que les limitan o les transforman la info necesaria. un sistema de cálculo de precios, donde guardarías, por ejemplo, precios de una plataforma de venta de unicomers o de una tienda online. Tú podría tener una base de datos con toda la información necesaria para poder calcular la información de precios, pero no tener que ir lar o encajar. Los microservicios que estás añadiendo al formato de estatable. Porque imagínete que luego cambia ese estatable, tienes que actualizar el código de todos los microservicios. Por lo tanto lo que puede hacer es generarte una vista que sea la parte pública, una vista, a nivel de base edatos, a la que se van a conectar estos microservicios externos. De forma que si quieres cambiar cómo se implementan los datos, en el monolito, puedes simplemente actualizar cómo se calcula la vista y los otros sistemas distribuidos no tienen ni qué saber que ha cambiado algo.

Y este es solamente uno de los patrones de migración de datos que se presenta, también se presenta, implementar un servicio dedicado para la gestión de la base de datos para que los microservicios no vayan directamente a la base de datos sino que pasen. Por esto es servicio intermedio, o incluso patrones de sin reinitación de datos y un montón de patrones extra que puedes empezar a implementar desde el día uno. Insisto, este libro te da un montón de técnicas, pero el principal reto de migrar a microservicios no es solamente a nivel de arquitectura, infraestructura, esa nivel de sementic. La parte más importante de migrar a microservicios es realmente encontrar estos puntos de quebre, estos límites. De realmente razonar sobre el sistema para que se permita una separación consentido. Y este libro hace bastante bien fascinado. La separación o migración a microservicios no sea de hacer, porque... Quiero llegar a tener una arquitectura de microservicios porque sí, se tiene que hacer por razones adecuadas. Tienes que analizar tu sistema, ver si hay partes que quieres escalar de manera independiente o no. Si te va a aportar alguna mejor operativa y entonces una de las opciones analizar sería hacer una migración, porque si al final realizas una migración de microservicios sin haber pensado, si realmente las necesitas, estás convertiendo un problema local que antes tenías dentro de un monolito y con el que podía razonar a un problema.

distribuido, en el que ahora además tienes que incorporarle fallas de red y problemas de disponibilidad que creme van a aparecer. De hecho, en el capítulo 5, con yo título es Dolores Crecientes, vale? Nos dice lo siguiente. A medida que vas adoptando una arquitectura de microservicios, vas a experimentar un montón de problemas por el camino, más servicios más dolor. Durante todo este capítulo, se han muñumando, abandono algunos trucos o algunos patrones o metodologías que puedes seguir para realmente entender las implicaciones que tenia adoptar una arquitectura como esta, ofreciendo como no, potenciales soluciones a medida que vas detectando estos riesgos. Uno de los problemas que define Sam en el libro son los Breaking Changes o los cambios que rompen el comportamiento anterior. Y que cuando tienes microservicios, es muy probable que a medida que los vas desarrollando, acá ves realizando cambios que vayan a afectar al resto de servicios que los están consumiendo. En esquerco mucho cuidado y tienes que tener en cuenta cosas que quizá si estabas desarrollando lo monolito, pues el propio editor te decía, hey, que has cambiado aquí una función y esta función se usa en estos siete sitios. Pero eso, difícilmente, lo vas a tener con un arquitectura distribuida. Por lo tanto, tienes que tener en cuenta algunos consejos para poder solucionar todo esto. Una de las potenciales soluciones que nos ofrece para poder arreglar o prevenir.

estos cambios que rompen, el resto del sistema, sería incorporar algún tipo de típado o estructura a los contratos de los diferentes microservicios. De esta forma, tú tienes un repositorio central con las maneras y datos esperados de cada servicio a nivel de... definición a nivel de contato, si tú rompes en cualquier servicio el contato con otro de alguna forma te vas a saltar un error. Esto te permite dar te cuenta de problemas muy rápido y te va a permitir evitar que al cabo del tiempo a que se cae por si solo. Ahora bien, hay situaciones en las que realmente tienes que cambiar este contrato por necesidades técnicas. En el libro se recomiendan diferentes etapas de una implementación de este estilo para dar suficiente información y tiempo a los diferentes equipos y consumidores para que pueda la actualizar sus servicios para aceptar el nuevo contrato. Como ves, cuando generas microservicios que es de preocupar de muchas más cosas que no solamente la implementación técnica, tienes también que preocuparte de la comunicación con el resto del equipo de desarrollo.

Y este sería solamente uno de los riesgos que nos ofrecen este capítulo también nos ofrece dificultades al nivel de reporti. cuando tú tienes sistemas distribuidos, generar análisis de datos, pues se complica pues también nos explica un poquito, soluciones para mejorar el reporte y mejorar los locks en arquitecturas distribuidas y también nos ofrece un problema que no lo he visto comentado muchas veces, cuando hablamos de aplicaciones distribuidas que es la experiencia del desarrollo de horlo calo, obviamente es mucho más fácil levantarte en lo cal un monolito que levantarte 30 alandas para poder implementar y hacer pruebas en tu propio portátil ¿no? Por lo tanto si te interesa o estás anteando migrar aplicaciones en la nube aplicaciones distribuidas o te encuentras en una situación en la que quieres que aplicar monolitos podría ser algo interesante este libro te puede dar una serie de estrategias que te podrían ayudar enormemente. Y una parte que me gusta especialmente de San Newman es que no notas que intenten venderte que los microservicios son lo mejor constantemente. De hecho tengo otro libro. de San Newman también que se llama construyendo microservicios, que es un poquito más antiguo que el de migrando de monolito microservicios. En este libro, San Newman te explica técnicas específicas de construcción de microservicios desde cero, no de la migración. Pero en este libro...

Sama hace una referencia a su libro anterior, diciendo que no le gusta mucho que se utilice este libro para intentar venderte que micróse servicios son una solución mágica para todo. Y lo deja claro en este libro, implementa micróse servicios, si realmente tienes sentido. técnico o te va a aportar algo a tu organización. Asumiendo los riesgos que te voy a explicar y voy a intentar ayudarte a hacerlo bien por el camino, pero entiende que estás aceptando una serie de problemas que con un monolito no tendrías. Por lo tanto si te interesa, migrar a microservicios o entender que patrones existen de nuevo este libro es tu mejor compañía. Y dejanme en los comentarios si os interesa que también os deje una revíus, y me la hará esta, pero del libro de construyendo microservicios. Un libro súper interesante que también explica un una serie de técnicas y prácticas para implementarlos de la mejor forma posible. Y si te gusta todo este contenido, o mar relacionado con diseño de sistemas y implementación de servicios distribuidos, le dejo por aquí un vídeo en el que te explico los conceptos básicos, conceptos técnicos que tienes que entender para poder construir estos sistemas en la manera eficiente. Si mucho más, si te gusta este vídeo, por favor suscríbete, déjame un buen like y ahora hay una cosa que se llama hype, también le puedes dar sin miles. Nos vemos en el siguiente vídeo con más informática. Hasta otra!