https:\/\/martinfowler.com\/articles\/break-monolith-into-microservices.html<\/a><\/p>\n <\/p>\n
<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
\u00bfQu\u00e9 desacoplar y cu\u00e1ndo? A medida que los sistemas monol\u00edticos se vuelven demasiado grandes para lidiar con ellos, muchas empresas est\u00e1n dispuestas a dividirlos en el estilo arquitect\u00f3nico de los microservicios, como se hizo en su d\u00eda en el desarrollo con OOP, ahora le ha llegado el momento a los sistemas.\u00a0Es un viaje que vale la pena, pero no es f\u00e1cil.\u00a0Hemos aprendido que para hacer esto bien, debemos comenzar con un servicio simple, pero luego extraer servicios basados \u200b\u200ben capacidades verticales que sean importantes para el negocio y est\u00e9n sujetas a cambios frecuentes.\u00a0Estos servicios deben ser grandes al principio y, de preferencia, no dependen del monolito restante.\u00a0Debemos asegurarnos de que cada paso de la migraci\u00f3n representa\u00a0una mejora at\u00f3mica de la arquitectura general que adem\u00e1s de justificar los costes nos permite motivarnos m\u00e1s.\u00a0 La migraci\u00f3n de un sistema monol\u00edtico a un\u00a0ecosistema de microservicios\u00a0es un viaje \u00e9pico.\u00a0Los que se embarcan en este viaje tienen aspiraciones como aumentar la escala de operaci\u00f3n, acelerar el ritmo del cambio y escapar del alto costo del cambio.\u00a0Quieren aumentar su n\u00famero de equipos al tiempo que les permite entregar valor en paralelo e independientemente uno del otro.\u00a0Quieren experimentar r\u00e1pidamente con las capacidades centrales de su negocio y entregar valor m\u00e1s r\u00e1pido.\u00a0Tambi\u00e9n quieren escapar del alto costo asociado con hacer cambios en sus sistemas monol\u00edticos existentes. Para trabajar bien no hace falta cambiar de arquitectura.. quiz\u00e1s sus mismos servicios si fueran ‘SOLID oriented’ cumpl\u00edan todas sus necesidades.\u00a0Vale la pena estudiar el escenario en que aplica cada paradigma. Decidir qu\u00e9 capacidad de desacoplar cu\u00e1ndo y c\u00f3mo migrar de manera incremental son algunos de los desaf\u00edos arquitect\u00f3nicos de descomponer un monolito a un ecosistema de microservicios.\u00a0En este art\u00edculo, compartimos algunas t\u00e9cnicas que pueden guiar a los equipos de entrega (desarrolladores, arquitectos, gerentes t\u00e9cnicos) para tomar estas decisiones de descomposici\u00f3n a lo largo del viaje. El ecosistema del microservicio Antes de embarcarse, es fundamental que todos tengan un entendimiento com\u00fan de un ecosistema de microservicios. El ecosistema de microservicios es una plataforma de servicios que encapsula una capacidad empresarial. Una capacidad comercial representa lo que hace una empresa en un dominio particular para cumplir sus objetivos y responsabilidades. Cada microservicio expone una API que los desarrolladores pueden descubrir y utilizar de forma autom\u00e1tica. Los microservicios tienen un ciclo de vida independiente. Los desarrolladores pueden construir, probar y lanzar cada microservicio de forma independiente. El ecosistema de microservicios impone una estructura organizativa de equipos aut\u00f3nomos de larga vida, cada uno es responsable de uno o varios servicios. Contrariamente a la percepci\u00f3n general y al ‘micro’ en microservicios, el tama\u00f1o de cada servicio es lo m\u00e1s importante y puede variar seg\u00fan la madurez operativa de la organizaci\u00f3n. Roadmap Antes de sumergirse en la gu\u00eda, es importante saber que hay un alto costo general asociado con la descomposici\u00f3n de un sistema existente para microservicios y puede tomar muchas iteraciones. Es necesario que los desarrolladores y arquitectos eval\u00faen detenidamente si la descomposici\u00f3n de un monolito existente es el camino correcto y si los microservicios en s\u00ed son el destino correcto . Habiendo aclarado eso, vamos a repasar la gu\u00eda. Calentando motores con una capacidad simple y bastante desacoplada Iniciar una ruta hacia los microservicios requiere un nivel m\u00ednimo de preparaci\u00f3n operativa. Requiere acceso al entorno de implementaci\u00f3n, la creaci\u00f3n de nuevos canales, integraci\u00f3n continua para construir, probar e implementar de forma independiente los servicios ejecutables, y la capacidad de proteger, depurar y monitorear una arquitectura distribuida. Se requiere madurez de preparaci\u00f3n operacional y equipos bien formados ya sea para un nuevo proyecto o descomponiendo un sistema existente. Nuestra sugerencia es que los desarrolladores y los equipos de operaci\u00f3n construyan la infraestructura subyacente, los procesos de integraci\u00f3n continua y el sistema de administraci\u00f3n de API con el primer y segundo servicio que descomponen o construyen. Comience con las capacidades que est\u00e1n bastante desacopladas del monolito, no requieren cambios en muchas aplicaciones de cara al cliente que actualmente usan el monolito y posiblemente no necesitan un almac\u00e9n de datos. Lo que los equipos est\u00e1n optimizando es validar sus enfoques de entrega, mejorar la capacidad de los miembros del equipo y desarrollar la infraestructura m\u00ednima necesaria para entregar servicios seguros de implementaci\u00f3n independiente que exponen las API de autoservicio. Primero recomendamos desacoplar los servicios simples. A continuaci\u00f3n, adoptamos un enfoque diferente: capacidades de desacoplamiento profundamente integradas en el sistema monol\u00edtico. Aconsejamos realizar servicios de vanguardia primero porque al comienzo del viaje, el mayor riesgo de los equipos de entrega es no operar los microservicios correctamente. Por lo tanto, es bueno usar los servicios perimetrales para practicar los requisitos previos operativos que necesitan. Una vez que han abordado eso, pueden abordar el problema clave de dividir el monolito. Minimiza la dependencia de regreso al monolito Como principio fundamental, los equipos de entrega necesitan minimizar las dependencias de los microservicios reci\u00e9n formados para el monolito. Un beneficio importante de los microservicios es tener un ciclo de lanzamiento r\u00e1pido e independiente. Tener dependencias en el monolito (datos, l\u00f3gica, API) acopla el servicio al ciclo de lanzamiento del monolito, lo que proh\u00edbe este beneficio. A menudo, la principal motivaci\u00f3n para alejarse del monolito es el alto costo y el lento ritmo de cambio de las capacidades bloqueadas en \u00e9l, por lo que queremos avanzar progresivamente en una direcci\u00f3n que desacople estas capacidades b\u00e1sicas al eliminar las dependencias del monolito. Si los equipos siguen esta gu\u00eda a medida que desarrollan capacidades en sus propios servicios, lo que encuentran es, en cambio, dependencias en la direcci\u00f3n inversa. Del monolito a los servicios. Esta es una direcci\u00f3n de dependencia deseada, ya que no ralentiza el ritmo de cambio para los nuevos servicios. Las siguientes pautas ofrecen otras formas de decidir el orden en el que los desarrolladores desacoplan los servicios. Esto significa que es posible que no siempre puedan evitar las dependencias al monolito. En los casos en que un nuevo servicio termina con una llamada al monolito, sugiero exponer una nueva API del monolito. Es mejor crear una capa en el nuevo servicio para asegurarse de que los conceptos de monolito no se filtren. Esfu\u00e9rcese por definir la API que refleje los conceptos y estructuras de dominio bien definidos, aunque la implementaci\u00f3n interna del monolito podr\u00eda ser diferente. En este desafortunado caso, los equipos de entrega sufragar\u00e1n el costo y la dificultad de cambiar el monolito, probar y liberar los nuevos servicios junto con el lanzamiento del monolito. Separar las funcionalidades acopladas Estoy asumiendo que en este punto los equipos de entrega se sienten c\u00f3modos con la creaci\u00f3n de microservicios y est\u00e1n listos para atacar los problemas persistentes. Sin embargo, pueden verse limitados con las capacidades que pueden desacoplar a continuaci\u00f3n sin una dependencia del monolito. La causa principal de esto, a menudo es una capacidad dentro del monolito con fugas, no bien definida como un concepto de dominio, con muchas de las capacidades del monolito que dependen de \u00e9l. Para poder progresar, los desarrolladores necesitan identificar la funcionalidad acoplada, deconstruirla en conceptos de dominio bien definidos y luego replicar esos conceptos de dominio en servicios separados. Por ejemplo, en un monolito basado en web, la noci\u00f3n de ‘sesi\u00f3n (web)’ es uno de los factores de acoplamiento m\u00e1s comunes.\u00a0 A menos que abordemos el desacoplamiento, la deconstrucci\u00f3n y la replicaci\u00f3n de la actual \u00absesi\u00f3n\u00bb, nos esforzaremos por desacoplar muchas de las capacidades futuras ya que se enredar\u00e1n con el monolito a trav\u00e9s de los conceptos de la sesi\u00f3n con fugas. Los desarrolladores pueden extraer microservicios de forma progresiva de las funcionalidades acopladas a un servicio a la vez. Como ejemplo, es posible refactorizar primero la ‘lista de deseos del cliente’ y extraer eso en un nuevo servicio, luego refactorizar las ‘preferencias de pago del cliente’ en otro microservicio y rep\u00edtalo. Desacoplar verticalmente y liberar los datos El principal impulsor de las capacidades de desacoplamiento de un monolito es poder liberarlas de forma independiente. Este primer principio deber\u00eda guiar todas las decisiones que los desarrolladores toman sobre c\u00f3mo realizar el desacoplamiento. Un sistema monol\u00edtico a menudo est\u00e1 compuesto de capas estrechamente integradas o incluso de m\u00faltiples sistemas que deben liberarse juntos y tener interdependencias fr\u00e1giles. La mayor\u00eda de los intentos de desacoplamiento comienzan con la extracci\u00f3n de componentes orientados al usuario y algunos servicios de front-end para proporcionar API de f\u00e1cil uso para las interfaces de usuario modernas, mientras que los datos permanecen bloqueados en un esquema y sistema de almacenamiento. Aunque este enfoque ofrece algunas ventajas r\u00e1pidas, como cambiar la interfaz de usuario con m\u00e1s frecuencia, cuando se trata de capacidades b\u00e1sicas, los equipos de entrega solo pueden moverse tan r\u00e1pido como la parte m\u00e1s lenta, el monolito y su almac\u00e9n de datos monol\u00edtico. En pocas palabras, sin desacoplar los datos, la arquitectura no es microservicios. Mantener todos los datos en el mismo almac\u00e9n de datos es contrario a la caracter\u00edstica de administraci\u00f3n de datos descentralizada de los microservicios. La estrategia es mover las capacidades verticalmente, desacoplar la capacidad central con sus datos y redirigir todas las aplicaciones de front-end a las nuevas API. Tener m\u00faltiples aplicaciones de escritura y lectura desde y hacia los datos compartidos centralmente es el principal bloqueador para desacoplar los datos junto con el servicio. Los equipos de entrega deben incorporar una estrategia de migraci\u00f3n de datos que se adapte a su entorno en funci\u00f3n de si son capaces de redirigir y migrar todos los lectores \/ escritores de datos al mismo tiempo o no. La estrategia de migraci\u00f3n de datos de cuatro fases se aplica a muchos entornos que requieren migrar de manera incremental las aplicaciones que se integran a trav\u00e9s de la base de datos, mientras que todos los sistemas bajo cambio deben ejecutarse continuamente. Desacople lo que es importante para el negocio y los cambios con frecuencia La capacidad de desacoplamiento del monolito es dif\u00edcil. Extraer una capacidad implica extraer cuidadosamente los datos, la l\u00f3gica, los componentes del usuario y redirigirlos al nuevo servicio. Debido a que esta es una cantidad de trabajo no trivial, los desarrolladores necesitan evaluar continuamente el costo de la disociaci\u00f3n con los beneficios que obtienen, por ejemplo, ir m\u00e1s r\u00e1pido o crecer en escala. Por ejemplo, si el objetivo de los equipos de entrega es acelerar las modificaciones a las capacidades existentes bloqueadas en un monolito, deben identificar la capacidad que m\u00e1s se est\u00e1 modificando para sacar. Desacople partes del c\u00f3digo que est\u00e1n continuamente cambiando y recibiendo mucho cari\u00f1o por parte de los desarrolladores y las est\u00e1n limitando para entregar valor r\u00e1pidamente. Los equipos de entrega pueden analizar los patrones de compromiso de c\u00f3digo para descubrir qu\u00e9 ha cambiado hist\u00f3ricamente m\u00e1s, y superponer eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. Capacidad de desacoplamiento sin reescribir Cuando los desarrolladores desean extraer un servicio de un sistema existente, tienen dos formas de hacerlo: extraer c\u00f3digo o reescribir la capacidad. A menudo, de forma predeterminada, la extracci\u00f3n del servicio o la descomposici\u00f3n monol\u00edtica se imagina como un caso de reutilizaci\u00f3n de la implementaci\u00f3n existente tal como est\u00e1 y de extraerla en un servicio separado. En parte porque tenemos un sesgo cognitivo hacia el c\u00f3digo que dise\u00f1amos y escribimos. El trabajo de construir, no importa cu\u00e1n doloroso sea el proceso o el resultado imperfecto, nos hace crecer el amor por \u00e9l. De hecho, esto se conoce como el efecto IKEA . Desafortunadamente, este sesgo va a frenar el esfuerzo de descomposici\u00f3n del monolito. Hace que los desarrolladores y, lo que es m\u00e1s importante, los gerentes t\u00e9cnicos ignoren el alto costo y el bajo valor de extraer y reutilizar el c\u00f3digo. Alternativamente, los equipos de entrega tienen la opci\u00f3n de volver a escribir la capacidad y retirar el c\u00f3digo anterior. La reescritura les da la oportunidad de revisar la capacidad del negocio, iniciar una conversaci\u00f3n con negocio para simplificar el proceso heredado y desafiar las suposiciones y restricciones antiguas incorporadas con el tiempo en el sistema. Tambi\u00e9n brinda la oportunidad de una actualizaci\u00f3n tecnol\u00f3gica, implementando el nuevo servicio con un lenguaje de programaci\u00f3n y una pila de tecnolog\u00eda que es m\u00e1s adecuado para ese servicio en particular. Esta capacidad es posiblemente un buen candidato para reutilizaci\u00f3n y extracci\u00f3n. En contraste, el ‘perfil del cliente’ es una capacidad CRUD simple que se compone principalmente de c\u00f3digo repetitivo para la serializaci\u00f3n, manejo de almacenamiento y configuraci\u00f3n, por lo tanto, es un buen candidato para volver a escribir y retirarse. En nuestra experiencia, en la mayor\u00eda de los escenarios de descomposici\u00f3n, es mejor que los equipos reescriban la capacidad como un nuevo servicio y retiren el c\u00f3digo anterior. Esto est\u00e1 considerando el alto costo y el bajo valor de la reutilizaci\u00f3n, debido a las siguientes razones: Existe una gran cantidad de c\u00f3digo repetitivo que se ocupa de las dependencias del entorno, como el acceso a la configuraci\u00f3n de la aplicaci\u00f3n en tiempo de ejecuci\u00f3n, el acceso a los almacenes de datos, el almacenamiento en cach\u00e9 y se construye con marcos antiguos. La mayor parte de este c\u00f3digo repetitivo debe ser reescrito. La nueva infraestructura para alojar un microservicio es muy diferente del tiempo de ejecuci\u00f3n de la aplicaci\u00f3n desde hace d\u00e9cadas y requerir\u00e1 un tipo muy diferente de c\u00f3digo repetitivo. Es muy probable que las capacidades existentes no se construyan alrededor de conceptos de dominio claros. Esto resulta en el transporte o almacenamiento de estructuras de datos que no reflejan los nuevos modelos de dominio y requieren una gran reestructuraci\u00f3n. Un c\u00f3digo heredado de larga duraci\u00f3n que ha pasado por muchas iteraciones de cambio podr\u00eda tener un alto nivel de toxicidad de c\u00f3digo y un bajo valor para su reutilizaci\u00f3n. A menos que la capacidad sea relevante, alineada con un concepto de dominio claro y con alta propiedad intelectual, recomiendo encarecidamente volver a escribir y retirar el c\u00f3digo anterior. Primero macro, luego micro Encontrar los l\u00edmites del dominio en un monolito heredado es tanto un arte como una ciencia. Como regla general, la aplicaci\u00f3n de t\u00e9cnicas de dise\u00f1o controladas por dominio para encontrar los contextos delimitados que definen los l\u00edmites de los microservicios es un buen lugar para comenzar. Con demasiada frecuencia, vemos una sobrecorrecci\u00f3n de monolito grande a servicios realmente peque\u00f1os, servicios realmente peque\u00f1os cuyo dise\u00f1o est\u00e1 inspirado e impulsado por la vista normalizada existente de los datos. Este enfoque para identificar los l\u00edmites de los servicios casi siempre conduce a un gran n\u00famero de servicios id\u00e9nticos para acceder a los recursos de CRUD. Para muchos nuevos en la arquitectura de microservicios, esto crea un entorno de alta fricci\u00f3n que, en \u00faltima instancia, falla la prueba de la liberaci\u00f3n y ejecuci\u00f3n independientes de los servicios. Crea un sistema distribuido que es dif\u00edcil de depurar, un sistema distribuido que se rompe a trav\u00e9s de los l\u00edmites transaccionales y, por lo tanto, dif\u00edcil de mantener consistente, un sistema que es demasiado complejo para la madurez operativa de la organizaci\u00f3n. Aunque hay algunas pistas, sobre c\u00f3mo de ‘micro’ debe ser el microservicio: el tama\u00f1o del equipo, el tiempo para volver a escribir el servicio, la cantidad de comportamiento que debe encapsular, etc. Nuestro consejo es que el tama\u00f1o depende de cu\u00e1ntos servicios pueden proporcionar los equipos de entrega y operaci\u00f3n de forma independiente liberar, monitorear y operar. Comience con servicios m\u00e1s grandes en torno a un concepto de dominio l\u00f3gico, y divida el servicio en m\u00faltiples servicios cuando los equipos est\u00e9n listos para la operaci\u00f3n. Migrar en pasos evolutivos at\u00f3micos La idea de desvanecer un legado monolito en el aire al disociarlo en microservicios bellamente dise\u00f1ados es algo as\u00ed como un mito y posiblemente indeseable. Cualquier ingeniero experimentado puede compartir historias de migraciones e intentos de modernizaci\u00f3n que se planificaron e iniciaron con un optimismo total y, en el mejor de los casos, se abandonaron en un momento suficientemente bueno. Los planes a largo plazo de tales esfuerzos se abandonan debido a que cambian las condiciones macro: el programa se queda sin dinero, la organizaci\u00f3n gira su enfoque hacia otra cosa o el liderazgo en su apoyo. Por lo tanto, esta realidad debe dise\u00f1arse en la forma en que los equipos abordan el viaje del monolito al microservicio. Yo llamo a este enfoque ‘migraci\u00f3n en pasos at\u00f3micos de la evoluci\u00f3n de la arquitectura’, donde cada paso de la migraci\u00f3n deber\u00eda acercar la arquitectura a su estado objetivo. Cada unidad de evoluci\u00f3n puede ser un peque\u00f1o paso o un gran salto, pero es at\u00f3mica, ya sea completa o revierte. Esto es especialmente importante ya que estamos adoptando un enfoque iterativo e incremental para mejorar la arquitectura general y los servicios de desacoplamiento. Cada incremento debe dejarnos en un lugar mejor en t\u00e9rminos del objetivo de la arquitectura, la funci\u00f3n de la aptitud arquitect\u00f3nica despu\u00e9s de cada paso at\u00f3mico de la migraci\u00f3n debe generar un valor m\u00e1s cercano al objetivo de la arquitectura. Imagine que el objetivo de la arquitectura de microservicio es aumentar la velocidad de los desarrolladores modificando el sistema general para ofrecer valor. El equipo decide desacoplar la autenticaci\u00f3n del usuario final en un servicio separado basado en el protocolo OAuth 2.0. Este servicio est\u00e1 destinado tanto a reemplazar la forma en que la aplicaci\u00f3n cliente existente (arquitectura antigua) autentica al usuario final, como a los nuevos servicios de arquitectura que validan al usuario final. Llamemos a este incremento en la evoluci\u00f3n, ‘Introducci\u00f3n al servicio de autenticaci\u00f3n’. Una forma de presentar el nuevo servicio es seguir estos pasos primero: Cree el servicio Auth, implementando el protocolo OAuth 2.0. Agregue una nueva ruta de autenticaci\u00f3n en el back-end monolito para llamar al servicio Auth para autenticar al usuario final en cuyo nombre est\u00e1 procesando una solicitud.Si el equipo se detiene aqu\u00ed y gira para construir otro servicio o caracter\u00edstica, deja la arquitectura general en un estado de mayor entrop\u00eda. En este estado, hay dos formas de autenticar al usuario, la nueva ruta base de OAuth 2.0 y la ruta basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente. En este punto, los equipos est\u00e1n realmente m\u00e1s lejos de su objetivo general de hacer cambios m\u00e1s r\u00e1pido. Cualquier nuevo desarrollador del c\u00f3digo monolito necesita lidiar con dos rutas de c\u00f3digo, una mayor carga cognitiva de comprensi\u00f3n del c\u00f3digo y un proceso m\u00e1s lento para cambiarlo y probarlo. Reemplace la autenticaci\u00f3n basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente con la ruta OAuth 2.0 Retire la ruta del c\u00f3digo de autenticaci\u00f3n anterior del monolito En este punto, podemos argumentar que los equipos se han acercado a la arquitectura de destino. A menudo encontramos que los equipos finalizan la migraci\u00f3n de una capacidad fuera del monolito y claman la victoria tan pronto como se construye la nueva capacidad sin retirar la ruta del c\u00f3digo antiguo, el anti-patr\u00f3n descrito anteriormente. Las razones principales para esto son: (a) El enfoque en los beneficios a corto plazo de la introducci\u00f3n de una nueva capacidad y (b) La cantidad total de esfuerzo requerido para retirar las implementaciones antiguas al tiempo que se enfrentan a prioridades competitivas para crear nuevas caracter\u00edsticas. Para hacer lo correcto, debemos esforzarnos por hacer los pasos at\u00f3micos lo m\u00e1s peque\u00f1os posible. Al migrar con este enfoque, podemos dividir el viaje en viajes m\u00e1s cortos. Podemos detenernos, revivir y sobrevivir con seguridad en este largo viaje, matando al monolito. Herramientas Para llevar a cabo un desarrollo orientado a microservicios, las \u00abnuevas\u00bb herramientas como docker y los nuevos servicios en la nube (PaaS) son un gran aliado si nuestro negocio nos permite alojar nuestros datos en una nube p\u00fablica. Para implementar de una forma escalable y sin complejas adaptaciones en nuestro departamento de sistemas podemos usar kubernetes\u00a0on premise o con nuestro PaaS de confianza. Conclusiones Adem\u00e1s del volumen hay que tener en cuenta el tema de la complejidad. Es decir, para nosotros, la ventaja la ves cuando tienes una plataforma empresarial donde la gente implanta soluciones, etc, y empiezas a identificar temas recurrentes como: Autenticaci\u00f3n\/Autorizaci\u00f3n, o un servicio de subida de im\u00e1genes. No tiene sentido que cada aplicaci\u00f3n que tenga que subir una imagen lo vuelva a implementar. Si implementas un servicio de subida de im\u00e1genes (que adem\u00e1s as\u00ed lo tienes optimizado y que si hay cualquier cambio no tiene impacto en cada una de las soluciones que lo consumen) y de paso estandarizas, monitorizas recursos, etc. De estas forma descargas a los proveedores que desarrollan aplicaciones de negocio de servicios cross que implican integrarse en tu infraestructura, etc, etc. Partiendo de escenarios reales, esto lo acabas viendo en plan \u00abarquitectura emergente\u00bb.. a partir de cada soluci\u00f3n puedes ver la funcionalidad que es candidata a ser Cross. Pero.. si por contra quieres hacer Cross toda una soluci\u00f3n de negocio.. por un lado puede que en s\u00ed mismo no tenga sentido (voy a poner la funci\u00f3n de planificar una reuni\u00f3n as a service para toda la compa\u00f1\u00eda?) lo que implica puede no ser viable por costes, tiempo y complejidad de implantaci\u00f3n ya que: Por lo pronto tienes que refactorizar el c\u00f3digo para aislarlo por dominios, subdominios, etc Al atomizar los componentes tienes m\u00e1s complejidad de operaci\u00f3n y de trazabilidad.. a nivel de testing se complican las pruebas de integraci\u00f3n, etc. Tienes que incorporar un message queue o ESB, etc, con lo que es m\u00e1s infraestructura que gestionar. Las alternativas cloud han simplificado un poco esto, pero crea otros problemas en operaci\u00f3n \/ TIC. Pero volviendo al refactor de c\u00f3digo, tienes que saber manejar: Patrones como Strangler para aislar dominios. Log Aggregators para centralizar los logs Patrones como SAGA para orquestar el acceso a base de datos para garantizar la transaccionalidad ya que ahora cada microservice tiene su propio repositorio y no puedes hacer cosas tan b\u00e1sicas como un \u00abdrop cascade\u00bb Un Service Registry para que cada servicio se registre y que los servicios clientes no tengan que guardar urls que pueden romperse, verificar que los servicios est\u00e1n activos etc. Si todo esto no lo tienes muy claro o la gente que lo implementa no tiene experiencia esto se acaba estancando y eternizando. Si adem\u00e1s se plantea como un proyecto SCRUM de \u00abvamos haciendo y mockeando que a alg\u00fan sitio llegaremos\u00bb sin una definici\u00f3n de la arquitectura.. pues.. acabas teniendo una chapuza luego inmantenible y sobre todo que genera muchos m\u00e1s problemas que una aplicaci\u00f3n cl\u00e1sica, cada problema es m\u00e1s dif\u00edcil de diagnosticar, etc.. Como suele pasar, cuando no hay planificaci\u00f3n y te consumes el presupuesto.. los tests se abandonan.. con lo que despu\u00e9s de todo el sufrimiento tienes una fant\u00e1stica aplicaci\u00f3n Legacy en producci\u00f3n de nuevo cu\u00f1o. En general, en la vida real el problema es la falta de la figura del arquitecto.. tanto los \u00abresponsables\u00bb como los chavales quieren probar cosas nuevas \u00abporque est\u00e1n de moda\u00bb.. pero.. luego.. \u00bfqui\u00e9n paga la fiesta? Bibliograf\u00eda: https:\/\/martinfowler.com\/articles\/break-monolith-into-microservices.html <\/p>\n","protected":false},"author":3,"featured_media":550,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[69,66,67,68],"class_list":["post-549","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tecnologia","tag-desarrollo","tag-microservices","tag-microservicio","tag-patron"],"yoast_head":"\n
Romper el monolito - Setblau<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\" \/>\n<meta property=\"og:locale\" content=\"es_ES\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Romper el monolito - Setblau\" \/>\n<meta property=\"og:description\" content=\"\u00bfQu\u00e9 desacoplar y cu\u00e1ndo? A medida que los sistemas monol\u00edticos se vuelven demasiado grandes para lidiar con ellos, muchas empresas est\u00e1n dispuestas a dividirlos en el estilo arquitect\u00f3nico de los microservicios, como se hizo en su d\u00eda en el desarrollo con OOP, ahora le ha llegado el momento a los sistemas.\u00a0Es un viaje que vale la pena, pero no es f\u00e1cil.\u00a0Hemos aprendido que para hacer esto bien, debemos comenzar con un servicio simple, pero luego extraer servicios basados \u200b\u200ben capacidades verticales que sean importantes para el negocio y est\u00e9n sujetas a cambios frecuentes.\u00a0Estos servicios deben ser grandes al principio y, de preferencia, no dependen del monolito restante.\u00a0Debemos asegurarnos de que cada paso de la migraci\u00f3n representa\u00a0una mejora at\u00f3mica de la arquitectura general que adem\u00e1s de justificar los costes nos permite motivarnos m\u00e1s.\u00a0 La migraci\u00f3n de un sistema monol\u00edtico a un\u00a0ecosistema de microservicios\u00a0es un viaje \u00e9pico.\u00a0Los que se embarcan en este viaje tienen aspiraciones como aumentar la escala de operaci\u00f3n, acelerar el ritmo del cambio y escapar del alto costo del cambio.\u00a0Quieren aumentar su n\u00famero de equipos al tiempo que les permite entregar valor en paralelo e independientemente uno del otro.\u00a0Quieren experimentar r\u00e1pidamente con las capacidades centrales de su negocio y entregar valor m\u00e1s r\u00e1pido.\u00a0Tambi\u00e9n quieren escapar del alto costo asociado con hacer cambios en sus sistemas monol\u00edticos existentes. Para trabajar bien no hace falta cambiar de arquitectura.. quiz\u00e1s sus mismos servicios si fueran ‘SOLID oriented’ cumpl\u00edan todas sus necesidades.\u00a0Vale la pena estudiar el escenario en que aplica cada paradigma. Decidir qu\u00e9 capacidad de desacoplar cu\u00e1ndo y c\u00f3mo migrar de manera incremental son algunos de los desaf\u00edos arquitect\u00f3nicos de descomponer un monolito a un ecosistema de microservicios.\u00a0En este art\u00edculo, compartimos algunas t\u00e9cnicas que pueden guiar a los equipos de entrega (desarrolladores, arquitectos, gerentes t\u00e9cnicos) para tomar estas decisiones de descomposici\u00f3n a lo largo del viaje. El ecosistema del microservicio Antes de embarcarse, es fundamental que todos tengan un entendimiento com\u00fan de un ecosistema de microservicios. El ecosistema de microservicios es una plataforma de servicios que encapsula una capacidad empresarial. Una capacidad comercial representa lo que hace una empresa en un dominio particular para cumplir sus objetivos y responsabilidades. Cada microservicio expone una API que los desarrolladores pueden descubrir y utilizar de forma autom\u00e1tica. Los microservicios tienen un ciclo de vida independiente. Los desarrolladores pueden construir, probar y lanzar cada microservicio de forma independiente. El ecosistema de microservicios impone una estructura organizativa de equipos aut\u00f3nomos de larga vida, cada uno es responsable de uno o varios servicios. Contrariamente a la percepci\u00f3n general y al ‘micro’ en microservicios, el tama\u00f1o de cada servicio es lo m\u00e1s importante y puede variar seg\u00fan la madurez operativa de la organizaci\u00f3n. Roadmap Antes de sumergirse en la gu\u00eda, es importante saber que hay un alto costo general asociado con la descomposici\u00f3n de un sistema existente para microservicios y puede tomar muchas iteraciones. Es necesario que los desarrolladores y arquitectos eval\u00faen detenidamente si la descomposici\u00f3n de un monolito existente es el camino correcto y si los microservicios en s\u00ed son el destino correcto . Habiendo aclarado eso, vamos a repasar la gu\u00eda. Calentando motores con una capacidad simple y bastante desacoplada Iniciar una ruta hacia los microservicios requiere un nivel m\u00ednimo de preparaci\u00f3n operativa. Requiere acceso al entorno de implementaci\u00f3n, la creaci\u00f3n de nuevos canales, integraci\u00f3n continua para construir, probar e implementar de forma independiente los servicios ejecutables, y la capacidad de proteger, depurar y monitorear una arquitectura distribuida. Se requiere madurez de preparaci\u00f3n operacional y equipos bien formados ya sea para un nuevo proyecto o descomponiendo un sistema existente. Nuestra sugerencia es que los desarrolladores y los equipos de operaci\u00f3n construyan la infraestructura subyacente, los procesos de integraci\u00f3n continua y el sistema de administraci\u00f3n de API con el primer y segundo servicio que descomponen o construyen. Comience con las capacidades que est\u00e1n bastante desacopladas del monolito, no requieren cambios en muchas aplicaciones de cara al cliente que actualmente usan el monolito y posiblemente no necesitan un almac\u00e9n de datos. Lo que los equipos est\u00e1n optimizando es validar sus enfoques de entrega, mejorar la capacidad de los miembros del equipo y desarrollar la infraestructura m\u00ednima necesaria para entregar servicios seguros de implementaci\u00f3n independiente que exponen las API de autoservicio. Primero recomendamos desacoplar los servicios simples. A continuaci\u00f3n, adoptamos un enfoque diferente: capacidades de desacoplamiento profundamente integradas en el sistema monol\u00edtico. Aconsejamos realizar servicios de vanguardia primero porque al comienzo del viaje, el mayor riesgo de los equipos de entrega es no operar los microservicios correctamente. Por lo tanto, es bueno usar los servicios perimetrales para practicar los requisitos previos operativos que necesitan. Una vez que han abordado eso, pueden abordar el problema clave de dividir el monolito. Minimiza la dependencia de regreso al monolito Como principio fundamental, los equipos de entrega necesitan minimizar las dependencias de los microservicios reci\u00e9n formados para el monolito. Un beneficio importante de los microservicios es tener un ciclo de lanzamiento r\u00e1pido e independiente. Tener dependencias en el monolito (datos, l\u00f3gica, API) acopla el servicio al ciclo de lanzamiento del monolito, lo que proh\u00edbe este beneficio. A menudo, la principal motivaci\u00f3n para alejarse del monolito es el alto costo y el lento ritmo de cambio de las capacidades bloqueadas en \u00e9l, por lo que queremos avanzar progresivamente en una direcci\u00f3n que desacople estas capacidades b\u00e1sicas al eliminar las dependencias del monolito. Si los equipos siguen esta gu\u00eda a medida que desarrollan capacidades en sus propios servicios, lo que encuentran es, en cambio, dependencias en la direcci\u00f3n inversa. Del monolito a los servicios. Esta es una direcci\u00f3n de dependencia deseada, ya que no ralentiza el ritmo de cambio para los nuevos servicios. Las siguientes pautas ofrecen otras formas de decidir el orden en el que los desarrolladores desacoplan los servicios. Esto significa que es posible que no siempre puedan evitar las dependencias al monolito. En los casos en que un nuevo servicio termina con una llamada al monolito, sugiero exponer una nueva API del monolito. Es mejor crear una capa en el nuevo servicio para asegurarse de que los conceptos de monolito no se filtren. Esfu\u00e9rcese por definir la API que refleje los conceptos y estructuras de dominio bien definidos, aunque la implementaci\u00f3n interna del monolito podr\u00eda ser diferente. En este desafortunado caso, los equipos de entrega sufragar\u00e1n el costo y la dificultad de cambiar el monolito, probar y liberar los nuevos servicios junto con el lanzamiento del monolito. Separar las funcionalidades acopladas Estoy asumiendo que en este punto los equipos de entrega se sienten c\u00f3modos con la creaci\u00f3n de microservicios y est\u00e1n listos para atacar los problemas persistentes. Sin embargo, pueden verse limitados con las capacidades que pueden desacoplar a continuaci\u00f3n sin una dependencia del monolito. La causa principal de esto, a menudo es una capacidad dentro del monolito con fugas, no bien definida como un concepto de dominio, con muchas de las capacidades del monolito que dependen de \u00e9l. Para poder progresar, los desarrolladores necesitan identificar la funcionalidad acoplada, deconstruirla en conceptos de dominio bien definidos y luego replicar esos conceptos de dominio en servicios separados. Por ejemplo, en un monolito basado en web, la noci\u00f3n de ‘sesi\u00f3n (web)’ es uno de los factores de acoplamiento m\u00e1s comunes.\u00a0 A menos que abordemos el desacoplamiento, la deconstrucci\u00f3n y la replicaci\u00f3n de la actual \u00absesi\u00f3n\u00bb, nos esforzaremos por desacoplar muchas de las capacidades futuras ya que se enredar\u00e1n con el monolito a trav\u00e9s de los conceptos de la sesi\u00f3n con fugas. Los desarrolladores pueden extraer microservicios de forma progresiva de las funcionalidades acopladas a un servicio a la vez. Como ejemplo, es posible refactorizar primero la ‘lista de deseos del cliente’ y extraer eso en un nuevo servicio, luego refactorizar las ‘preferencias de pago del cliente’ en otro microservicio y rep\u00edtalo. Desacoplar verticalmente y liberar los datos El principal impulsor de las capacidades de desacoplamiento de un monolito es poder liberarlas de forma independiente. Este primer principio deber\u00eda guiar todas las decisiones que los desarrolladores toman sobre c\u00f3mo realizar el desacoplamiento. Un sistema monol\u00edtico a menudo est\u00e1 compuesto de capas estrechamente integradas o incluso de m\u00faltiples sistemas que deben liberarse juntos y tener interdependencias fr\u00e1giles. La mayor\u00eda de los intentos de desacoplamiento comienzan con la extracci\u00f3n de componentes orientados al usuario y algunos servicios de front-end para proporcionar API de f\u00e1cil uso para las interfaces de usuario modernas, mientras que los datos permanecen bloqueados en un esquema y sistema de almacenamiento. Aunque este enfoque ofrece algunas ventajas r\u00e1pidas, como cambiar la interfaz de usuario con m\u00e1s frecuencia, cuando se trata de capacidades b\u00e1sicas, los equipos de entrega solo pueden moverse tan r\u00e1pido como la parte m\u00e1s lenta, el monolito y su almac\u00e9n de datos monol\u00edtico. En pocas palabras, sin desacoplar los datos, la arquitectura no es microservicios. Mantener todos los datos en el mismo almac\u00e9n de datos es contrario a la caracter\u00edstica de administraci\u00f3n de datos descentralizada de los microservicios. La estrategia es mover las capacidades verticalmente, desacoplar la capacidad central con sus datos y redirigir todas las aplicaciones de front-end a las nuevas API. Tener m\u00faltiples aplicaciones de escritura y lectura desde y hacia los datos compartidos centralmente es el principal bloqueador para desacoplar los datos junto con el servicio. Los equipos de entrega deben incorporar una estrategia de migraci\u00f3n de datos que se adapte a su entorno en funci\u00f3n de si son capaces de redirigir y migrar todos los lectores \/ escritores de datos al mismo tiempo o no. La estrategia de migraci\u00f3n de datos de cuatro fases se aplica a muchos entornos que requieren migrar de manera incremental las aplicaciones que se integran a trav\u00e9s de la base de datos, mientras que todos los sistemas bajo cambio deben ejecutarse continuamente. Desacople lo que es importante para el negocio y los cambios con frecuencia La capacidad de desacoplamiento del monolito es dif\u00edcil. Extraer una capacidad implica extraer cuidadosamente los datos, la l\u00f3gica, los componentes del usuario y redirigirlos al nuevo servicio. Debido a que esta es una cantidad de trabajo no trivial, los desarrolladores necesitan evaluar continuamente el costo de la disociaci\u00f3n con los beneficios que obtienen, por ejemplo, ir m\u00e1s r\u00e1pido o crecer en escala. Por ejemplo, si el objetivo de los equipos de entrega es acelerar las modificaciones a las capacidades existentes bloqueadas en un monolito, deben identificar la capacidad que m\u00e1s se est\u00e1 modificando para sacar. Desacople partes del c\u00f3digo que est\u00e1n continuamente cambiando y recibiendo mucho cari\u00f1o por parte de los desarrolladores y las est\u00e1n limitando para entregar valor r\u00e1pidamente. Los equipos de entrega pueden analizar los patrones de compromiso de c\u00f3digo para descubrir qu\u00e9 ha cambiado hist\u00f3ricamente m\u00e1s, y superponer eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. Capacidad de desacoplamiento sin reescribir Cuando los desarrolladores desean extraer un servicio de un sistema existente, tienen dos formas de hacerlo: extraer c\u00f3digo o reescribir la capacidad. A menudo, de forma predeterminada, la extracci\u00f3n del servicio o la descomposici\u00f3n monol\u00edtica se imagina como un caso de reutilizaci\u00f3n de la implementaci\u00f3n existente tal como est\u00e1 y de extraerla en un servicio separado. En parte porque tenemos un sesgo cognitivo hacia el c\u00f3digo que dise\u00f1amos y escribimos. El trabajo de construir, no importa cu\u00e1n doloroso sea el proceso o el resultado imperfecto, nos hace crecer el amor por \u00e9l. De hecho, esto se conoce como el efecto IKEA . Desafortunadamente, este sesgo va a frenar el esfuerzo de descomposici\u00f3n del monolito. Hace que los desarrolladores y, lo que es m\u00e1s importante, los gerentes t\u00e9cnicos ignoren el alto costo y el bajo valor de extraer y reutilizar el c\u00f3digo. Alternativamente, los equipos de entrega tienen la opci\u00f3n de volver a escribir la capacidad y retirar el c\u00f3digo anterior. La reescritura les da la oportunidad de revisar la capacidad del negocio, iniciar una conversaci\u00f3n con negocio para simplificar el proceso heredado y desafiar las suposiciones y restricciones antiguas incorporadas con el tiempo en el sistema. Tambi\u00e9n brinda la oportunidad de una actualizaci\u00f3n tecnol\u00f3gica, implementando el nuevo servicio con un lenguaje de programaci\u00f3n y una pila de tecnolog\u00eda que es m\u00e1s adecuado para ese servicio en particular. Esta capacidad es posiblemente un buen candidato para reutilizaci\u00f3n y extracci\u00f3n. En contraste, el ‘perfil del cliente’ es una capacidad CRUD simple que se compone principalmente de c\u00f3digo repetitivo para la serializaci\u00f3n, manejo de almacenamiento y configuraci\u00f3n, por lo tanto, es un buen candidato para volver a escribir y retirarse. En nuestra experiencia, en la mayor\u00eda de los escenarios de descomposici\u00f3n, es mejor que los equipos reescriban la capacidad como un nuevo servicio y retiren el c\u00f3digo anterior. Esto est\u00e1 considerando el alto costo y el bajo valor de la reutilizaci\u00f3n, debido a las siguientes razones: Existe una gran cantidad de c\u00f3digo repetitivo que se ocupa de las dependencias del entorno, como el acceso a la configuraci\u00f3n de la aplicaci\u00f3n en tiempo de ejecuci\u00f3n, el acceso a los almacenes de datos, el almacenamiento en cach\u00e9 y se construye con marcos antiguos. La mayor parte de este c\u00f3digo repetitivo debe ser reescrito. La nueva infraestructura para alojar un microservicio es muy diferente del tiempo de ejecuci\u00f3n de la aplicaci\u00f3n desde hace d\u00e9cadas y requerir\u00e1 un tipo muy diferente de c\u00f3digo repetitivo. Es muy probable que las capacidades existentes no se construyan alrededor de conceptos de dominio claros. Esto resulta en el transporte o almacenamiento de estructuras de datos que no reflejan los nuevos modelos de dominio y requieren una gran reestructuraci\u00f3n. Un c\u00f3digo heredado de larga duraci\u00f3n que ha pasado por muchas iteraciones de cambio podr\u00eda tener un alto nivel de toxicidad de c\u00f3digo y un bajo valor para su reutilizaci\u00f3n. A menos que la capacidad sea relevante, alineada con un concepto de dominio claro y con alta propiedad intelectual, recomiendo encarecidamente volver a escribir y retirar el c\u00f3digo anterior. Primero macro, luego micro Encontrar los l\u00edmites del dominio en un monolito heredado es tanto un arte como una ciencia. Como regla general, la aplicaci\u00f3n de t\u00e9cnicas de dise\u00f1o controladas por dominio para encontrar los contextos delimitados que definen los l\u00edmites de los microservicios es un buen lugar para comenzar. Con demasiada frecuencia, vemos una sobrecorrecci\u00f3n de monolito grande a servicios realmente peque\u00f1os, servicios realmente peque\u00f1os cuyo dise\u00f1o est\u00e1 inspirado e impulsado por la vista normalizada existente de los datos. Este enfoque para identificar los l\u00edmites de los servicios casi siempre conduce a un gran n\u00famero de servicios id\u00e9nticos para acceder a los recursos de CRUD. Para muchos nuevos en la arquitectura de microservicios, esto crea un entorno de alta fricci\u00f3n que, en \u00faltima instancia, falla la prueba de la liberaci\u00f3n y ejecuci\u00f3n independientes de los servicios. Crea un sistema distribuido que es dif\u00edcil de depurar, un sistema distribuido que se rompe a trav\u00e9s de los l\u00edmites transaccionales y, por lo tanto, dif\u00edcil de mantener consistente, un sistema que es demasiado complejo para la madurez operativa de la organizaci\u00f3n. Aunque hay algunas pistas, sobre c\u00f3mo de ‘micro’ debe ser el microservicio: el tama\u00f1o del equipo, el tiempo para volver a escribir el servicio, la cantidad de comportamiento que debe encapsular, etc. Nuestro consejo es que el tama\u00f1o depende de cu\u00e1ntos servicios pueden proporcionar los equipos de entrega y operaci\u00f3n de forma independiente liberar, monitorear y operar. Comience con servicios m\u00e1s grandes en torno a un concepto de dominio l\u00f3gico, y divida el servicio en m\u00faltiples servicios cuando los equipos est\u00e9n listos para la operaci\u00f3n. Migrar en pasos evolutivos at\u00f3micos La idea de desvanecer un legado monolito en el aire al disociarlo en microservicios bellamente dise\u00f1ados es algo as\u00ed como un mito y posiblemente indeseable. Cualquier ingeniero experimentado puede compartir historias de migraciones e intentos de modernizaci\u00f3n que se planificaron e iniciaron con un optimismo total y, en el mejor de los casos, se abandonaron en un momento suficientemente bueno. Los planes a largo plazo de tales esfuerzos se abandonan debido a que cambian las condiciones macro: el programa se queda sin dinero, la organizaci\u00f3n gira su enfoque hacia otra cosa o el liderazgo en su apoyo. Por lo tanto, esta realidad debe dise\u00f1arse en la forma en que los equipos abordan el viaje del monolito al microservicio. Yo llamo a este enfoque ‘migraci\u00f3n en pasos at\u00f3micos de la evoluci\u00f3n de la arquitectura’, donde cada paso de la migraci\u00f3n deber\u00eda acercar la arquitectura a su estado objetivo. Cada unidad de evoluci\u00f3n puede ser un peque\u00f1o paso o un gran salto, pero es at\u00f3mica, ya sea completa o revierte. Esto es especialmente importante ya que estamos adoptando un enfoque iterativo e incremental para mejorar la arquitectura general y los servicios de desacoplamiento. Cada incremento debe dejarnos en un lugar mejor en t\u00e9rminos del objetivo de la arquitectura, la funci\u00f3n de la aptitud arquitect\u00f3nica despu\u00e9s de cada paso at\u00f3mico de la migraci\u00f3n debe generar un valor m\u00e1s cercano al objetivo de la arquitectura. Imagine que el objetivo de la arquitectura de microservicio es aumentar la velocidad de los desarrolladores modificando el sistema general para ofrecer valor. El equipo decide desacoplar la autenticaci\u00f3n del usuario final en un servicio separado basado en el protocolo OAuth 2.0. Este servicio est\u00e1 destinado tanto a reemplazar la forma en que la aplicaci\u00f3n cliente existente (arquitectura antigua) autentica al usuario final, como a los nuevos servicios de arquitectura que validan al usuario final. Llamemos a este incremento en la evoluci\u00f3n, ‘Introducci\u00f3n al servicio de autenticaci\u00f3n’. Una forma de presentar el nuevo servicio es seguir estos pasos primero: Cree el servicio Auth, implementando el protocolo OAuth 2.0. Agregue una nueva ruta de autenticaci\u00f3n en el back-end monolito para llamar al servicio Auth para autenticar al usuario final en cuyo nombre est\u00e1 procesando una solicitud.Si el equipo se detiene aqu\u00ed y gira para construir otro servicio o caracter\u00edstica, deja la arquitectura general en un estado de mayor entrop\u00eda. En este estado, hay dos formas de autenticar al usuario, la nueva ruta base de OAuth 2.0 y la ruta basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente. En este punto, los equipos est\u00e1n realmente m\u00e1s lejos de su objetivo general de hacer cambios m\u00e1s r\u00e1pido. Cualquier nuevo desarrollador del c\u00f3digo monolito necesita lidiar con dos rutas de c\u00f3digo, una mayor carga cognitiva de comprensi\u00f3n del c\u00f3digo y un proceso m\u00e1s lento para cambiarlo y probarlo. Reemplace la autenticaci\u00f3n basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente con la ruta OAuth 2.0 Retire la ruta del c\u00f3digo de autenticaci\u00f3n anterior del monolito En este punto, podemos argumentar que los equipos se han acercado a la arquitectura de destino. A menudo encontramos que los equipos finalizan la migraci\u00f3n de una capacidad fuera del monolito y claman la victoria tan pronto como se construye la nueva capacidad sin retirar la ruta del c\u00f3digo antiguo, el anti-patr\u00f3n descrito anteriormente. Las razones principales para esto son: (a) El enfoque en los beneficios a corto plazo de la introducci\u00f3n de una nueva capacidad y (b) La cantidad total de esfuerzo requerido para retirar las implementaciones antiguas al tiempo que se enfrentan a prioridades competitivas para crear nuevas caracter\u00edsticas. Para hacer lo correcto, debemos esforzarnos por hacer los pasos at\u00f3micos lo m\u00e1s peque\u00f1os posible. Al migrar con este enfoque, podemos dividir el viaje en viajes m\u00e1s cortos. Podemos detenernos, revivir y sobrevivir con seguridad en este largo viaje, matando al monolito. Herramientas Para llevar a cabo un desarrollo orientado a microservicios, las \u00abnuevas\u00bb herramientas como docker y los nuevos servicios en la nube (PaaS) son un gran aliado si nuestro negocio nos permite alojar nuestros datos en una nube p\u00fablica. Para implementar de una forma escalable y sin complejas adaptaciones en nuestro departamento de sistemas podemos usar kubernetes\u00a0on premise o con nuestro PaaS de confianza. Conclusiones Adem\u00e1s del volumen hay que tener en cuenta el tema de la complejidad. Es decir, para nosotros, la ventaja la ves cuando tienes una plataforma empresarial donde la gente implanta soluciones, etc, y empiezas a identificar temas recurrentes como: Autenticaci\u00f3n\/Autorizaci\u00f3n, o un servicio de subida de im\u00e1genes. No tiene sentido que cada aplicaci\u00f3n que tenga que subir una imagen lo vuelva a implementar. Si implementas un servicio de subida de im\u00e1genes (que adem\u00e1s as\u00ed lo tienes optimizado y que si hay cualquier cambio no tiene impacto en cada una de las soluciones que lo consumen) y de paso estandarizas, monitorizas recursos, etc. De estas forma descargas a los proveedores que desarrollan aplicaciones de negocio de servicios cross que implican integrarse en tu infraestructura, etc, etc. Partiendo de escenarios reales, esto lo acabas viendo en plan \u00abarquitectura emergente\u00bb.. a partir de cada soluci\u00f3n puedes ver la funcionalidad que es candidata a ser Cross. Pero.. si por contra quieres hacer Cross toda una soluci\u00f3n de negocio.. por un lado puede que en s\u00ed mismo no tenga sentido (voy a poner la funci\u00f3n de planificar una reuni\u00f3n as a service para toda la compa\u00f1\u00eda?) lo que implica puede no ser viable por costes, tiempo y complejidad de implantaci\u00f3n ya que: Por lo pronto tienes que refactorizar el c\u00f3digo para aislarlo por dominios, subdominios, etc Al atomizar los componentes tienes m\u00e1s complejidad de operaci\u00f3n y de trazabilidad.. a nivel de testing se complican las pruebas de integraci\u00f3n, etc. Tienes que incorporar un message queue o ESB, etc, con lo que es m\u00e1s infraestructura que gestionar. Las alternativas cloud han simplificado un poco esto, pero crea otros problemas en operaci\u00f3n \/ TIC. Pero volviendo al refactor de c\u00f3digo, tienes que saber manejar: Patrones como Strangler para aislar dominios. Log Aggregators para centralizar los logs Patrones como SAGA para orquestar el acceso a base de datos para garantizar la transaccionalidad ya que ahora cada microservice tiene su propio repositorio y no puedes hacer cosas tan b\u00e1sicas como un \u00abdrop cascade\u00bb Un Service Registry para que cada servicio se registre y que los servicios clientes no tengan que guardar urls que pueden romperse, verificar que los servicios est\u00e1n activos etc. Si todo esto no lo tienes muy claro o la gente que lo implementa no tiene experiencia esto se acaba estancando y eternizando. Si adem\u00e1s se plantea como un proyecto SCRUM de \u00abvamos haciendo y mockeando que a alg\u00fan sitio llegaremos\u00bb sin una definici\u00f3n de la arquitectura.. pues.. acabas teniendo una chapuza luego inmantenible y sobre todo que genera muchos m\u00e1s problemas que una aplicaci\u00f3n cl\u00e1sica, cada problema es m\u00e1s dif\u00edcil de diagnosticar, etc.. Como suele pasar, cuando no hay planificaci\u00f3n y te consumes el presupuesto.. los tests se abandonan.. con lo que despu\u00e9s de todo el sufrimiento tienes una fant\u00e1stica aplicaci\u00f3n Legacy en producci\u00f3n de nuevo cu\u00f1o. En general, en la vida real el problema es la falta de la figura del arquitecto.. tanto los \u00abresponsables\u00bb como los chavales quieren probar cosas nuevas \u00abporque est\u00e1n de moda\u00bb.. pero.. luego.. \u00bfqui\u00e9n paga la fiesta? Bibliograf\u00eda: https:\/\/martinfowler.com\/articles\/break-monolith-into-microservices.html \" \/>\n<meta property=\"og:url\" content=\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\" \/>\n<meta property=\"og:site_name\" content=\"Setblau\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/setblau\" \/>\n<meta property=\"article:published_time\" content=\"2018-10-23T09:34:34+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2018-10-23T10:25:21+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"640\" \/>\n\t<meta property=\"og:image:height\" content=\"484\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Llu\u00eds Gonz\u00e0lez\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@Setblau\" \/>\n<meta name=\"twitter:site\" content=\"@Setblau\" \/>\n<meta name=\"twitter:label1\" content=\"Escrito por\" \/>\n\t<meta name=\"twitter:data1\" content=\"Llu\u00eds Gonz\u00e0lez\" \/>\n\t<meta name=\"twitter:label2\" content=\"Tiempo de lectura\" \/>\n\t<meta name=\"twitter:data2\" content=\"21 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\"},\"author\":{\"name\":\"Llu\u00eds Gonz\u00e0lez\",\"@id\":\"https:\/\/setblau.com\/blog\/#\/schema\/person\/66c35168882c827bb8dc164524a3da4a\"},\"headline\":\"Romper el monolito\",\"datePublished\":\"2018-10-23T09:34:34+00:00\",\"dateModified\":\"2018-10-23T10:25:21+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\"},\"wordCount\":4210,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/setblau.com\/blog\/#organization\"},\"image\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg\",\"keywords\":[\"desarrollo\",\"microservices\",\"microservicio\",\"patr\u00f3n\"],\"articleSection\":[\"Tecnolog\u00eda\"],\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\",\"url\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\",\"name\":\"Romper el monolito - Setblau\",\"isPartOf\":{\"@id\":\"https:\/\/setblau.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg\",\"datePublished\":\"2018-10-23T09:34:34+00:00\",\"dateModified\":\"2018-10-23T10:25:21+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#breadcrumb\"},\"inLanguage\":\"es\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/setblau.com\/blog\/romper-el-monolito\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage\",\"url\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg\",\"contentUrl\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg\",\"width\":640,\"height\":484,\"caption\":\"comepiedras\"},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/setblau.com\/blog\/romper-el-monolito\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Portada\",\"item\":\"https:\/\/setblau.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Romper el monolito\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/setblau.com\/blog\/#website\",\"url\":\"https:\/\/setblau.com\/blog\/\",\"name\":\"Setblau\",\"description\":\"Tutoriales y novedades\",\"publisher\":{\"@id\":\"https:\/\/setblau.com\/blog\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/setblau.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"es\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/setblau.com\/blog\/#organization\",\"name\":\"Setblau\",\"url\":\"https:\/\/setblau.com\/blog\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\/\/setblau.com\/blog\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2015\/11\/setblau.gif\",\"contentUrl\":\"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2015\/11\/setblau.gif\",\"width\":394,\"height\":83,\"caption\":\"Setblau\"},\"image\":{\"@id\":\"https:\/\/setblau.com\/blog\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/setblau\",\"https:\/\/x.com\/Setblau\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/setblau.com\/blog\/#\/schema\/person\/66c35168882c827bb8dc164524a3da4a\",\"name\":\"Llu\u00eds Gonz\u00e0lez\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"es\",\"@id\":\"https:\/\/setblau.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/9104069be4bfdffbd23837a15a8bd394dc6ebccfd101b9a57e30743adafe7d9f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/9104069be4bfdffbd23837a15a8bd394dc6ebccfd101b9a57e30743adafe7d9f?s=96&d=mm&r=g\",\"caption\":\"Llu\u00eds Gonz\u00e0lez\"},\"description\":\"Director and Founder from setblau.com\",\"sameAs\":[\"http:\/\/www.setblau.com\"],\"url\":\"https:\/\/setblau.com\/blog\/author\/lgonzalez\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Romper el monolito - Setblau","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/setblau.com\/blog\/romper-el-monolito\/","og_locale":"es_ES","og_type":"article","og_title":"Romper el monolito - Setblau","og_description":"\u00bfQu\u00e9 desacoplar y cu\u00e1ndo? A medida que los sistemas monol\u00edticos se vuelven demasiado grandes para lidiar con ellos, muchas empresas est\u00e1n dispuestas a dividirlos en el estilo arquitect\u00f3nico de los microservicios, como se hizo en su d\u00eda en el desarrollo con OOP, ahora le ha llegado el momento a los sistemas.\u00a0Es un viaje que vale la pena, pero no es f\u00e1cil.\u00a0Hemos aprendido que para hacer esto bien, debemos comenzar con un servicio simple, pero luego extraer servicios basados \u200b\u200ben capacidades verticales que sean importantes para el negocio y est\u00e9n sujetas a cambios frecuentes.\u00a0Estos servicios deben ser grandes al principio y, de preferencia, no dependen del monolito restante.\u00a0Debemos asegurarnos de que cada paso de la migraci\u00f3n representa\u00a0una mejora at\u00f3mica de la arquitectura general que adem\u00e1s de justificar los costes nos permite motivarnos m\u00e1s.\u00a0 La migraci\u00f3n de un sistema monol\u00edtico a un\u00a0ecosistema de microservicios\u00a0es un viaje \u00e9pico.\u00a0Los que se embarcan en este viaje tienen aspiraciones como aumentar la escala de operaci\u00f3n, acelerar el ritmo del cambio y escapar del alto costo del cambio.\u00a0Quieren aumentar su n\u00famero de equipos al tiempo que les permite entregar valor en paralelo e independientemente uno del otro.\u00a0Quieren experimentar r\u00e1pidamente con las capacidades centrales de su negocio y entregar valor m\u00e1s r\u00e1pido.\u00a0Tambi\u00e9n quieren escapar del alto costo asociado con hacer cambios en sus sistemas monol\u00edticos existentes. Para trabajar bien no hace falta cambiar de arquitectura.. quiz\u00e1s sus mismos servicios si fueran ‘SOLID oriented’ cumpl\u00edan todas sus necesidades.\u00a0Vale la pena estudiar el escenario en que aplica cada paradigma. Decidir qu\u00e9 capacidad de desacoplar cu\u00e1ndo y c\u00f3mo migrar de manera incremental son algunos de los desaf\u00edos arquitect\u00f3nicos de descomponer un monolito a un ecosistema de microservicios.\u00a0En este art\u00edculo, compartimos algunas t\u00e9cnicas que pueden guiar a los equipos de entrega (desarrolladores, arquitectos, gerentes t\u00e9cnicos) para tomar estas decisiones de descomposici\u00f3n a lo largo del viaje. El ecosistema del microservicio Antes de embarcarse, es fundamental que todos tengan un entendimiento com\u00fan de un ecosistema de microservicios. El ecosistema de microservicios es una plataforma de servicios que encapsula una capacidad empresarial. Una capacidad comercial representa lo que hace una empresa en un dominio particular para cumplir sus objetivos y responsabilidades. Cada microservicio expone una API que los desarrolladores pueden descubrir y utilizar de forma autom\u00e1tica. Los microservicios tienen un ciclo de vida independiente. Los desarrolladores pueden construir, probar y lanzar cada microservicio de forma independiente. El ecosistema de microservicios impone una estructura organizativa de equipos aut\u00f3nomos de larga vida, cada uno es responsable de uno o varios servicios. Contrariamente a la percepci\u00f3n general y al ‘micro’ en microservicios, el tama\u00f1o de cada servicio es lo m\u00e1s importante y puede variar seg\u00fan la madurez operativa de la organizaci\u00f3n. Roadmap Antes de sumergirse en la gu\u00eda, es importante saber que hay un alto costo general asociado con la descomposici\u00f3n de un sistema existente para microservicios y puede tomar muchas iteraciones. Es necesario que los desarrolladores y arquitectos eval\u00faen detenidamente si la descomposici\u00f3n de un monolito existente es el camino correcto y si los microservicios en s\u00ed son el destino correcto . Habiendo aclarado eso, vamos a repasar la gu\u00eda. Calentando motores con una capacidad simple y bastante desacoplada Iniciar una ruta hacia los microservicios requiere un nivel m\u00ednimo de preparaci\u00f3n operativa. Requiere acceso al entorno de implementaci\u00f3n, la creaci\u00f3n de nuevos canales, integraci\u00f3n continua para construir, probar e implementar de forma independiente los servicios ejecutables, y la capacidad de proteger, depurar y monitorear una arquitectura distribuida. Se requiere madurez de preparaci\u00f3n operacional y equipos bien formados ya sea para un nuevo proyecto o descomponiendo un sistema existente. Nuestra sugerencia es que los desarrolladores y los equipos de operaci\u00f3n construyan la infraestructura subyacente, los procesos de integraci\u00f3n continua y el sistema de administraci\u00f3n de API con el primer y segundo servicio que descomponen o construyen. Comience con las capacidades que est\u00e1n bastante desacopladas del monolito, no requieren cambios en muchas aplicaciones de cara al cliente que actualmente usan el monolito y posiblemente no necesitan un almac\u00e9n de datos. Lo que los equipos est\u00e1n optimizando es validar sus enfoques de entrega, mejorar la capacidad de los miembros del equipo y desarrollar la infraestructura m\u00ednima necesaria para entregar servicios seguros de implementaci\u00f3n independiente que exponen las API de autoservicio. Primero recomendamos desacoplar los servicios simples. A continuaci\u00f3n, adoptamos un enfoque diferente: capacidades de desacoplamiento profundamente integradas en el sistema monol\u00edtico. Aconsejamos realizar servicios de vanguardia primero porque al comienzo del viaje, el mayor riesgo de los equipos de entrega es no operar los microservicios correctamente. Por lo tanto, es bueno usar los servicios perimetrales para practicar los requisitos previos operativos que necesitan. Una vez que han abordado eso, pueden abordar el problema clave de dividir el monolito. Minimiza la dependencia de regreso al monolito Como principio fundamental, los equipos de entrega necesitan minimizar las dependencias de los microservicios reci\u00e9n formados para el monolito. Un beneficio importante de los microservicios es tener un ciclo de lanzamiento r\u00e1pido e independiente. Tener dependencias en el monolito (datos, l\u00f3gica, API) acopla el servicio al ciclo de lanzamiento del monolito, lo que proh\u00edbe este beneficio. A menudo, la principal motivaci\u00f3n para alejarse del monolito es el alto costo y el lento ritmo de cambio de las capacidades bloqueadas en \u00e9l, por lo que queremos avanzar progresivamente en una direcci\u00f3n que desacople estas capacidades b\u00e1sicas al eliminar las dependencias del monolito. Si los equipos siguen esta gu\u00eda a medida que desarrollan capacidades en sus propios servicios, lo que encuentran es, en cambio, dependencias en la direcci\u00f3n inversa. Del monolito a los servicios. Esta es una direcci\u00f3n de dependencia deseada, ya que no ralentiza el ritmo de cambio para los nuevos servicios. Las siguientes pautas ofrecen otras formas de decidir el orden en el que los desarrolladores desacoplan los servicios. Esto significa que es posible que no siempre puedan evitar las dependencias al monolito. En los casos en que un nuevo servicio termina con una llamada al monolito, sugiero exponer una nueva API del monolito. Es mejor crear una capa en el nuevo servicio para asegurarse de que los conceptos de monolito no se filtren. Esfu\u00e9rcese por definir la API que refleje los conceptos y estructuras de dominio bien definidos, aunque la implementaci\u00f3n interna del monolito podr\u00eda ser diferente. En este desafortunado caso, los equipos de entrega sufragar\u00e1n el costo y la dificultad de cambiar el monolito, probar y liberar los nuevos servicios junto con el lanzamiento del monolito. Separar las funcionalidades acopladas Estoy asumiendo que en este punto los equipos de entrega se sienten c\u00f3modos con la creaci\u00f3n de microservicios y est\u00e1n listos para atacar los problemas persistentes. Sin embargo, pueden verse limitados con las capacidades que pueden desacoplar a continuaci\u00f3n sin una dependencia del monolito. La causa principal de esto, a menudo es una capacidad dentro del monolito con fugas, no bien definida como un concepto de dominio, con muchas de las capacidades del monolito que dependen de \u00e9l. Para poder progresar, los desarrolladores necesitan identificar la funcionalidad acoplada, deconstruirla en conceptos de dominio bien definidos y luego replicar esos conceptos de dominio en servicios separados. Por ejemplo, en un monolito basado en web, la noci\u00f3n de ‘sesi\u00f3n (web)’ es uno de los factores de acoplamiento m\u00e1s comunes.\u00a0 A menos que abordemos el desacoplamiento, la deconstrucci\u00f3n y la replicaci\u00f3n de la actual \u00absesi\u00f3n\u00bb, nos esforzaremos por desacoplar muchas de las capacidades futuras ya que se enredar\u00e1n con el monolito a trav\u00e9s de los conceptos de la sesi\u00f3n con fugas. Los desarrolladores pueden extraer microservicios de forma progresiva de las funcionalidades acopladas a un servicio a la vez. Como ejemplo, es posible refactorizar primero la ‘lista de deseos del cliente’ y extraer eso en un nuevo servicio, luego refactorizar las ‘preferencias de pago del cliente’ en otro microservicio y rep\u00edtalo. Desacoplar verticalmente y liberar los datos El principal impulsor de las capacidades de desacoplamiento de un monolito es poder liberarlas de forma independiente. Este primer principio deber\u00eda guiar todas las decisiones que los desarrolladores toman sobre c\u00f3mo realizar el desacoplamiento. Un sistema monol\u00edtico a menudo est\u00e1 compuesto de capas estrechamente integradas o incluso de m\u00faltiples sistemas que deben liberarse juntos y tener interdependencias fr\u00e1giles. La mayor\u00eda de los intentos de desacoplamiento comienzan con la extracci\u00f3n de componentes orientados al usuario y algunos servicios de front-end para proporcionar API de f\u00e1cil uso para las interfaces de usuario modernas, mientras que los datos permanecen bloqueados en un esquema y sistema de almacenamiento. Aunque este enfoque ofrece algunas ventajas r\u00e1pidas, como cambiar la interfaz de usuario con m\u00e1s frecuencia, cuando se trata de capacidades b\u00e1sicas, los equipos de entrega solo pueden moverse tan r\u00e1pido como la parte m\u00e1s lenta, el monolito y su almac\u00e9n de datos monol\u00edtico. En pocas palabras, sin desacoplar los datos, la arquitectura no es microservicios. Mantener todos los datos en el mismo almac\u00e9n de datos es contrario a la caracter\u00edstica de administraci\u00f3n de datos descentralizada de los microservicios. La estrategia es mover las capacidades verticalmente, desacoplar la capacidad central con sus datos y redirigir todas las aplicaciones de front-end a las nuevas API. Tener m\u00faltiples aplicaciones de escritura y lectura desde y hacia los datos compartidos centralmente es el principal bloqueador para desacoplar los datos junto con el servicio. Los equipos de entrega deben incorporar una estrategia de migraci\u00f3n de datos que se adapte a su entorno en funci\u00f3n de si son capaces de redirigir y migrar todos los lectores \/ escritores de datos al mismo tiempo o no. La estrategia de migraci\u00f3n de datos de cuatro fases se aplica a muchos entornos que requieren migrar de manera incremental las aplicaciones que se integran a trav\u00e9s de la base de datos, mientras que todos los sistemas bajo cambio deben ejecutarse continuamente. Desacople lo que es importante para el negocio y los cambios con frecuencia La capacidad de desacoplamiento del monolito es dif\u00edcil. Extraer una capacidad implica extraer cuidadosamente los datos, la l\u00f3gica, los componentes del usuario y redirigirlos al nuevo servicio. Debido a que esta es una cantidad de trabajo no trivial, los desarrolladores necesitan evaluar continuamente el costo de la disociaci\u00f3n con los beneficios que obtienen, por ejemplo, ir m\u00e1s r\u00e1pido o crecer en escala. Por ejemplo, si el objetivo de los equipos de entrega es acelerar las modificaciones a las capacidades existentes bloqueadas en un monolito, deben identificar la capacidad que m\u00e1s se est\u00e1 modificando para sacar. Desacople partes del c\u00f3digo que est\u00e1n continuamente cambiando y recibiendo mucho cari\u00f1o por parte de los desarrolladores y las est\u00e1n limitando para entregar valor r\u00e1pidamente. Los equipos de entrega pueden analizar los patrones de compromiso de c\u00f3digo para descubrir qu\u00e9 ha cambiado hist\u00f3ricamente m\u00e1s, y superponer eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. y superponga eso con la hoja de ruta y la cartera del producto para comprender las capacidades m\u00e1s deseadas que recibir\u00e1n atenci\u00f3n en el futuro cercano. Necesitan hablar con los gerentes de negocios y de productos para comprender las capacidades de diferenciaci\u00f3n que realmente les interesan. Capacidad de desacoplamiento sin reescribir Cuando los desarrolladores desean extraer un servicio de un sistema existente, tienen dos formas de hacerlo: extraer c\u00f3digo o reescribir la capacidad. A menudo, de forma predeterminada, la extracci\u00f3n del servicio o la descomposici\u00f3n monol\u00edtica se imagina como un caso de reutilizaci\u00f3n de la implementaci\u00f3n existente tal como est\u00e1 y de extraerla en un servicio separado. En parte porque tenemos un sesgo cognitivo hacia el c\u00f3digo que dise\u00f1amos y escribimos. El trabajo de construir, no importa cu\u00e1n doloroso sea el proceso o el resultado imperfecto, nos hace crecer el amor por \u00e9l. De hecho, esto se conoce como el efecto IKEA . Desafortunadamente, este sesgo va a frenar el esfuerzo de descomposici\u00f3n del monolito. Hace que los desarrolladores y, lo que es m\u00e1s importante, los gerentes t\u00e9cnicos ignoren el alto costo y el bajo valor de extraer y reutilizar el c\u00f3digo. Alternativamente, los equipos de entrega tienen la opci\u00f3n de volver a escribir la capacidad y retirar el c\u00f3digo anterior. La reescritura les da la oportunidad de revisar la capacidad del negocio, iniciar una conversaci\u00f3n con negocio para simplificar el proceso heredado y desafiar las suposiciones y restricciones antiguas incorporadas con el tiempo en el sistema. Tambi\u00e9n brinda la oportunidad de una actualizaci\u00f3n tecnol\u00f3gica, implementando el nuevo servicio con un lenguaje de programaci\u00f3n y una pila de tecnolog\u00eda que es m\u00e1s adecuado para ese servicio en particular. Esta capacidad es posiblemente un buen candidato para reutilizaci\u00f3n y extracci\u00f3n. En contraste, el ‘perfil del cliente’ es una capacidad CRUD simple que se compone principalmente de c\u00f3digo repetitivo para la serializaci\u00f3n, manejo de almacenamiento y configuraci\u00f3n, por lo tanto, es un buen candidato para volver a escribir y retirarse. En nuestra experiencia, en la mayor\u00eda de los escenarios de descomposici\u00f3n, es mejor que los equipos reescriban la capacidad como un nuevo servicio y retiren el c\u00f3digo anterior. Esto est\u00e1 considerando el alto costo y el bajo valor de la reutilizaci\u00f3n, debido a las siguientes razones: Existe una gran cantidad de c\u00f3digo repetitivo que se ocupa de las dependencias del entorno, como el acceso a la configuraci\u00f3n de la aplicaci\u00f3n en tiempo de ejecuci\u00f3n, el acceso a los almacenes de datos, el almacenamiento en cach\u00e9 y se construye con marcos antiguos. La mayor parte de este c\u00f3digo repetitivo debe ser reescrito. La nueva infraestructura para alojar un microservicio es muy diferente del tiempo de ejecuci\u00f3n de la aplicaci\u00f3n desde hace d\u00e9cadas y requerir\u00e1 un tipo muy diferente de c\u00f3digo repetitivo. Es muy probable que las capacidades existentes no se construyan alrededor de conceptos de dominio claros. Esto resulta en el transporte o almacenamiento de estructuras de datos que no reflejan los nuevos modelos de dominio y requieren una gran reestructuraci\u00f3n. Un c\u00f3digo heredado de larga duraci\u00f3n que ha pasado por muchas iteraciones de cambio podr\u00eda tener un alto nivel de toxicidad de c\u00f3digo y un bajo valor para su reutilizaci\u00f3n. A menos que la capacidad sea relevante, alineada con un concepto de dominio claro y con alta propiedad intelectual, recomiendo encarecidamente volver a escribir y retirar el c\u00f3digo anterior. Primero macro, luego micro Encontrar los l\u00edmites del dominio en un monolito heredado es tanto un arte como una ciencia. Como regla general, la aplicaci\u00f3n de t\u00e9cnicas de dise\u00f1o controladas por dominio para encontrar los contextos delimitados que definen los l\u00edmites de los microservicios es un buen lugar para comenzar. Con demasiada frecuencia, vemos una sobrecorrecci\u00f3n de monolito grande a servicios realmente peque\u00f1os, servicios realmente peque\u00f1os cuyo dise\u00f1o est\u00e1 inspirado e impulsado por la vista normalizada existente de los datos. Este enfoque para identificar los l\u00edmites de los servicios casi siempre conduce a un gran n\u00famero de servicios id\u00e9nticos para acceder a los recursos de CRUD. Para muchos nuevos en la arquitectura de microservicios, esto crea un entorno de alta fricci\u00f3n que, en \u00faltima instancia, falla la prueba de la liberaci\u00f3n y ejecuci\u00f3n independientes de los servicios. Crea un sistema distribuido que es dif\u00edcil de depurar, un sistema distribuido que se rompe a trav\u00e9s de los l\u00edmites transaccionales y, por lo tanto, dif\u00edcil de mantener consistente, un sistema que es demasiado complejo para la madurez operativa de la organizaci\u00f3n. Aunque hay algunas pistas, sobre c\u00f3mo de ‘micro’ debe ser el microservicio: el tama\u00f1o del equipo, el tiempo para volver a escribir el servicio, la cantidad de comportamiento que debe encapsular, etc. Nuestro consejo es que el tama\u00f1o depende de cu\u00e1ntos servicios pueden proporcionar los equipos de entrega y operaci\u00f3n de forma independiente liberar, monitorear y operar. Comience con servicios m\u00e1s grandes en torno a un concepto de dominio l\u00f3gico, y divida el servicio en m\u00faltiples servicios cuando los equipos est\u00e9n listos para la operaci\u00f3n. Migrar en pasos evolutivos at\u00f3micos La idea de desvanecer un legado monolito en el aire al disociarlo en microservicios bellamente dise\u00f1ados es algo as\u00ed como un mito y posiblemente indeseable. Cualquier ingeniero experimentado puede compartir historias de migraciones e intentos de modernizaci\u00f3n que se planificaron e iniciaron con un optimismo total y, en el mejor de los casos, se abandonaron en un momento suficientemente bueno. Los planes a largo plazo de tales esfuerzos se abandonan debido a que cambian las condiciones macro: el programa se queda sin dinero, la organizaci\u00f3n gira su enfoque hacia otra cosa o el liderazgo en su apoyo. Por lo tanto, esta realidad debe dise\u00f1arse en la forma en que los equipos abordan el viaje del monolito al microservicio. Yo llamo a este enfoque ‘migraci\u00f3n en pasos at\u00f3micos de la evoluci\u00f3n de la arquitectura’, donde cada paso de la migraci\u00f3n deber\u00eda acercar la arquitectura a su estado objetivo. Cada unidad de evoluci\u00f3n puede ser un peque\u00f1o paso o un gran salto, pero es at\u00f3mica, ya sea completa o revierte. Esto es especialmente importante ya que estamos adoptando un enfoque iterativo e incremental para mejorar la arquitectura general y los servicios de desacoplamiento. Cada incremento debe dejarnos en un lugar mejor en t\u00e9rminos del objetivo de la arquitectura, la funci\u00f3n de la aptitud arquitect\u00f3nica despu\u00e9s de cada paso at\u00f3mico de la migraci\u00f3n debe generar un valor m\u00e1s cercano al objetivo de la arquitectura. Imagine que el objetivo de la arquitectura de microservicio es aumentar la velocidad de los desarrolladores modificando el sistema general para ofrecer valor. El equipo decide desacoplar la autenticaci\u00f3n del usuario final en un servicio separado basado en el protocolo OAuth 2.0. Este servicio est\u00e1 destinado tanto a reemplazar la forma en que la aplicaci\u00f3n cliente existente (arquitectura antigua) autentica al usuario final, como a los nuevos servicios de arquitectura que validan al usuario final. Llamemos a este incremento en la evoluci\u00f3n, ‘Introducci\u00f3n al servicio de autenticaci\u00f3n’. Una forma de presentar el nuevo servicio es seguir estos pasos primero: Cree el servicio Auth, implementando el protocolo OAuth 2.0. Agregue una nueva ruta de autenticaci\u00f3n en el back-end monolito para llamar al servicio Auth para autenticar al usuario final en cuyo nombre est\u00e1 procesando una solicitud.Si el equipo se detiene aqu\u00ed y gira para construir otro servicio o caracter\u00edstica, deja la arquitectura general en un estado de mayor entrop\u00eda. En este estado, hay dos formas de autenticar al usuario, la nueva ruta base de OAuth 2.0 y la ruta basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente. En este punto, los equipos est\u00e1n realmente m\u00e1s lejos de su objetivo general de hacer cambios m\u00e1s r\u00e1pido. Cualquier nuevo desarrollador del c\u00f3digo monolito necesita lidiar con dos rutas de c\u00f3digo, una mayor carga cognitiva de comprensi\u00f3n del c\u00f3digo y un proceso m\u00e1s lento para cambiarlo y probarlo. Reemplace la autenticaci\u00f3n basada en contrase\u00f1a \/ sesi\u00f3n del antiguo cliente con la ruta OAuth 2.0 Retire la ruta del c\u00f3digo de autenticaci\u00f3n anterior del monolito En este punto, podemos argumentar que los equipos se han acercado a la arquitectura de destino. A menudo encontramos que los equipos finalizan la migraci\u00f3n de una capacidad fuera del monolito y claman la victoria tan pronto como se construye la nueva capacidad sin retirar la ruta del c\u00f3digo antiguo, el anti-patr\u00f3n descrito anteriormente. Las razones principales para esto son: (a) El enfoque en los beneficios a corto plazo de la introducci\u00f3n de una nueva capacidad y (b) La cantidad total de esfuerzo requerido para retirar las implementaciones antiguas al tiempo que se enfrentan a prioridades competitivas para crear nuevas caracter\u00edsticas. Para hacer lo correcto, debemos esforzarnos por hacer los pasos at\u00f3micos lo m\u00e1s peque\u00f1os posible. Al migrar con este enfoque, podemos dividir el viaje en viajes m\u00e1s cortos. Podemos detenernos, revivir y sobrevivir con seguridad en este largo viaje, matando al monolito. Herramientas Para llevar a cabo un desarrollo orientado a microservicios, las \u00abnuevas\u00bb herramientas como docker y los nuevos servicios en la nube (PaaS) son un gran aliado si nuestro negocio nos permite alojar nuestros datos en una nube p\u00fablica. Para implementar de una forma escalable y sin complejas adaptaciones en nuestro departamento de sistemas podemos usar kubernetes\u00a0on premise o con nuestro PaaS de confianza. Conclusiones Adem\u00e1s del volumen hay que tener en cuenta el tema de la complejidad. Es decir, para nosotros, la ventaja la ves cuando tienes una plataforma empresarial donde la gente implanta soluciones, etc, y empiezas a identificar temas recurrentes como: Autenticaci\u00f3n\/Autorizaci\u00f3n, o un servicio de subida de im\u00e1genes. No tiene sentido que cada aplicaci\u00f3n que tenga que subir una imagen lo vuelva a implementar. Si implementas un servicio de subida de im\u00e1genes (que adem\u00e1s as\u00ed lo tienes optimizado y que si hay cualquier cambio no tiene impacto en cada una de las soluciones que lo consumen) y de paso estandarizas, monitorizas recursos, etc. De estas forma descargas a los proveedores que desarrollan aplicaciones de negocio de servicios cross que implican integrarse en tu infraestructura, etc, etc. Partiendo de escenarios reales, esto lo acabas viendo en plan \u00abarquitectura emergente\u00bb.. a partir de cada soluci\u00f3n puedes ver la funcionalidad que es candidata a ser Cross. Pero.. si por contra quieres hacer Cross toda una soluci\u00f3n de negocio.. por un lado puede que en s\u00ed mismo no tenga sentido (voy a poner la funci\u00f3n de planificar una reuni\u00f3n as a service para toda la compa\u00f1\u00eda?) lo que implica puede no ser viable por costes, tiempo y complejidad de implantaci\u00f3n ya que: Por lo pronto tienes que refactorizar el c\u00f3digo para aislarlo por dominios, subdominios, etc Al atomizar los componentes tienes m\u00e1s complejidad de operaci\u00f3n y de trazabilidad.. a nivel de testing se complican las pruebas de integraci\u00f3n, etc. Tienes que incorporar un message queue o ESB, etc, con lo que es m\u00e1s infraestructura que gestionar. Las alternativas cloud han simplificado un poco esto, pero crea otros problemas en operaci\u00f3n \/ TIC. Pero volviendo al refactor de c\u00f3digo, tienes que saber manejar: Patrones como Strangler para aislar dominios. Log Aggregators para centralizar los logs Patrones como SAGA para orquestar el acceso a base de datos para garantizar la transaccionalidad ya que ahora cada microservice tiene su propio repositorio y no puedes hacer cosas tan b\u00e1sicas como un \u00abdrop cascade\u00bb Un Service Registry para que cada servicio se registre y que los servicios clientes no tengan que guardar urls que pueden romperse, verificar que los servicios est\u00e1n activos etc. Si todo esto no lo tienes muy claro o la gente que lo implementa no tiene experiencia esto se acaba estancando y eternizando. Si adem\u00e1s se plantea como un proyecto SCRUM de \u00abvamos haciendo y mockeando que a alg\u00fan sitio llegaremos\u00bb sin una definici\u00f3n de la arquitectura.. pues.. acabas teniendo una chapuza luego inmantenible y sobre todo que genera muchos m\u00e1s problemas que una aplicaci\u00f3n cl\u00e1sica, cada problema es m\u00e1s dif\u00edcil de diagnosticar, etc.. Como suele pasar, cuando no hay planificaci\u00f3n y te consumes el presupuesto.. los tests se abandonan.. con lo que despu\u00e9s de todo el sufrimiento tienes una fant\u00e1stica aplicaci\u00f3n Legacy en producci\u00f3n de nuevo cu\u00f1o. En general, en la vida real el problema es la falta de la figura del arquitecto.. tanto los \u00abresponsables\u00bb como los chavales quieren probar cosas nuevas \u00abporque est\u00e1n de moda\u00bb.. pero.. luego.. \u00bfqui\u00e9n paga la fiesta? Bibliograf\u00eda: https:\/\/martinfowler.com\/articles\/break-monolith-into-microservices.html ","og_url":"https:\/\/setblau.com\/blog\/romper-el-monolito\/","og_site_name":"Setblau","article_publisher":"https:\/\/www.facebook.com\/setblau","article_published_time":"2018-10-23T09:34:34+00:00","article_modified_time":"2018-10-23T10:25:21+00:00","og_image":[{"width":640,"height":484,"url":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg","type":"image\/jpeg"}],"author":"Llu\u00eds Gonz\u00e0lez","twitter_card":"summary_large_image","twitter_creator":"@Setblau","twitter_site":"@Setblau","twitter_misc":{"Escrito por":"Llu\u00eds Gonz\u00e0lez","Tiempo de lectura":"21 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#article","isPartOf":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/"},"author":{"name":"Llu\u00eds Gonz\u00e0lez","@id":"https:\/\/setblau.com\/blog\/#\/schema\/person\/66c35168882c827bb8dc164524a3da4a"},"headline":"Romper el monolito","datePublished":"2018-10-23T09:34:34+00:00","dateModified":"2018-10-23T10:25:21+00:00","mainEntityOfPage":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/"},"wordCount":4210,"commentCount":0,"publisher":{"@id":"https:\/\/setblau.com\/blog\/#organization"},"image":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage"},"thumbnailUrl":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg","keywords":["desarrollo","microservices","microservicio","patr\u00f3n"],"articleSection":["Tecnolog\u00eda"],"inLanguage":"es","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/setblau.com\/blog\/romper-el-monolito\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/","url":"https:\/\/setblau.com\/blog\/romper-el-monolito\/","name":"Romper el monolito - Setblau","isPartOf":{"@id":"https:\/\/setblau.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage"},"image":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage"},"thumbnailUrl":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg","datePublished":"2018-10-23T09:34:34+00:00","dateModified":"2018-10-23T10:25:21+00:00","breadcrumb":{"@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#breadcrumb"},"inLanguage":"es","potentialAction":[{"@type":"ReadAction","target":["https:\/\/setblau.com\/blog\/romper-el-monolito\/"]}]},{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#primaryimage","url":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg","contentUrl":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2018\/10\/comepiedras.jpg","width":640,"height":484,"caption":"comepiedras"},{"@type":"BreadcrumbList","@id":"https:\/\/setblau.com\/blog\/romper-el-monolito\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Portada","item":"https:\/\/setblau.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Romper el monolito"}]},{"@type":"WebSite","@id":"https:\/\/setblau.com\/blog\/#website","url":"https:\/\/setblau.com\/blog\/","name":"Setblau","description":"Tutoriales y novedades","publisher":{"@id":"https:\/\/setblau.com\/blog\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/setblau.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"es"},{"@type":"Organization","@id":"https:\/\/setblau.com\/blog\/#organization","name":"Setblau","url":"https:\/\/setblau.com\/blog\/","logo":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/setblau.com\/blog\/#\/schema\/logo\/image\/","url":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2015\/11\/setblau.gif","contentUrl":"https:\/\/setblau.com\/blog\/wp-content\/uploads\/2015\/11\/setblau.gif","width":394,"height":83,"caption":"Setblau"},"image":{"@id":"https:\/\/setblau.com\/blog\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/setblau","https:\/\/x.com\/Setblau"]},{"@type":"Person","@id":"https:\/\/setblau.com\/blog\/#\/schema\/person\/66c35168882c827bb8dc164524a3da4a","name":"Llu\u00eds Gonz\u00e0lez","image":{"@type":"ImageObject","inLanguage":"es","@id":"https:\/\/setblau.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/9104069be4bfdffbd23837a15a8bd394dc6ebccfd101b9a57e30743adafe7d9f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/9104069be4bfdffbd23837a15a8bd394dc6ebccfd101b9a57e30743adafe7d9f?s=96&d=mm&r=g","caption":"Llu\u00eds Gonz\u00e0lez"},"description":"Director and Founder from setblau.com","sameAs":["http:\/\/www.setblau.com"],"url":"https:\/\/setblau.com\/blog\/author\/lgonzalez\/"}]}},"_links":{"self":[{"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/posts\/549","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/comments?post=549"}],"version-history":[{"count":4,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/posts\/549\/revisions"}],"predecessor-version":[{"id":554,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/posts\/549\/revisions\/554"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/media\/550"}],"wp:attachment":[{"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/media?parent=549"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/categories?post=549"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/setblau.com\/blog\/wp-json\/wp\/v2\/tags?post=549"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}