{"id":20024,"date":"2022-02-07T11:28:46","date_gmt":"2022-02-07T09:28:46","guid":{"rendered":"https:\/\/www.hiberus.com\/crecemos-contigo\/?p=20024"},"modified":"2023-11-28T09:13:07","modified_gmt":"2023-11-28T08:13:07","slug":"migracion-microservicios","status":"publish","type":"post","link":"https:\/\/www.hiberus.com\/crecemos-contigo\/migracion-microservicios\/","title":{"rendered":"Migraci\u00f3n a microservicios: la transici\u00f3n del monolito a los microservicios"},"content":{"rendered":"

Los monolitos pueden llegar a cumplir su funci\u00f3n en muchos<\/span> clientes.<\/span>\u00a0De hecho, hasta hace pocos a\u00f1os, eran la norma. Se empaquetaba todo en\u00a0<\/span>un \u00fanico servidor\u00a0<\/span><\/span>web<\/span>\u00a0<\/span><\/span>y no se iba m\u00e1s all\u00e1.<\/span>\u00a0Sin embargo,\u00a0<\/span>a d\u00eda de hoy,\u00a0<\/span>l<\/span>as arquitecturas basadas en microservicios<\/strong> est\u00e1n de moda<\/span>. <\/span><\/span><\/p>\n

Y<\/span> no es un sinsentido, ya que, como comentamos en el art\u00edculo anterior \u00abBeneficios de una arquitectura microservicios<\/a><\/strong>\u00ab,<\/span><\/span>\u00a0desplegar\u00a0<\/span>un sistema complejo<\/span>\u00a0e<\/span>n\u00a0<\/span>una arquitectura de\u00a0<\/span>microservicios supone una serie de beneficios que, tarde o temprano,\u00a0<\/span>notar\u00e1n\u00a0<\/span>los\u00a0<\/span>usuarios<\/span>\u00a0finales<\/span>.<\/span><\/span><\/p>\n

La decisi\u00f3n de llevar a cabo una migraci\u00f3n a una arquitectura de microservicios<\/a><\/strong> y, concretamente, a microservicios basados en eventos<\/a>, se suele tomar cuando el c\u00f3digo<\/span>\u00a0existente en un monolito<\/span> se hace insostenible<\/span>\u00a0<\/span><\/strong>por la gran cantidad de deuda t\u00e9cnica<\/strong> que alberga:\u00a0<\/span><\/span><\/p>\n

    \n
  1. Hay partes duplicadas<\/strong>.<\/span><\/span><\/li>\n
  2. No hay <\/span><\/span>tests<\/span>\u00a0<\/span><\/span><\/em><\/strong>autom\u00e1ticos<\/strong> que<\/span>\u00a0<\/span>prueben<\/span> casos de uso.<\/span><\/span><\/li>\n
  3. Existe la necesidad de escalar verticalmente<\/strong>, es decir, <\/span>mejorar el servidor web en el que est\u00e1 desplegado el monolito, <\/span>en fechas clave.<\/span><\/span><\/li>\n
  4. Para introducir cambios hay que parar todo el sistema<\/strong>.<\/span><\/span><\/li>\n
  5. Un error <\/span><\/span>hardware\u00a0<\/span><\/span><\/em>obliga a reiniciar<\/strong>.<\/span><\/span><\/li>\n<\/ol>\n

    Desde nuestra experiencia, los microservicios resuelven problemas de escalabilidad y de rendimiento, adem\u00e1s de mejorar el trabajo en equipo y la eficiencia de trabajo. Pero no solamente lo pensamos nosotros, sino que tambi\u00e9n lo piensan cientos de programadores<\/strong> que fueron encuestados en el a\u00f1o 2020 por The Software House (State of Microservices).<\/em><\/p>\n

     <\/p>\n

    \"Encuesta<\/p>\n

    <\/h2>\n

    \u00bfQu\u00e9 es una migraci\u00f3n?<\/h2>\n

    Pero, \u00bfen qu\u00e9 consiste una migraci\u00f3n?<\/strong> Se utiliza el verbo migrar<\/em><\/strong><\/span><\/span>\u00a0<\/span><\/span><\/strong>a conciencia. \u00bfPor qu\u00e9? Porque <\/span>no se tiran <\/em>ni el c\u00f3digo, ni los datos, <\/span>ni<\/span>\u00a0se empieza a\u00a0<\/span>implementar todo de<\/span>sde cero<\/span>, sino que, teniendo en cuenta lo viejo<\/strong>: aprendizaje sobre el dominio del problema, documentaci\u00f3n sobre qu\u00e9 partes han <\/span>sido complicadas de dise\u00f1ar\/implementar\/probar, etc.<\/span>,<\/span>\u00a0se construye una soluci\u00f3n que s<\/strong><\/span>igue<\/span>\u00a0satisfaciendo las necesidades de los\u00a0<\/span>clientes<\/span>\u00a0<\/span>pero\u00a0<\/span>de una<\/span> manera m\u00e1s eficiente, segura, sostenible<\/span>\u00a0<\/span>y auditable.<\/span><\/strong><\/span><\/p>\n

    8 pasos para hacer una migraci\u00f3n a microservicios<\/a><\/h2>\n

    Y, \u00bfc\u00f3mo se podr\u00eda hacer una migraci\u00f3n?<\/strong> Al no ser una ciencia exacta, es complicado redactar una receta gen\u00e9rica<\/em>, pues depende<\/strong> en gran parte de los requisitos funcionales del cliente, del estado del monolito y de qu\u00e9 enfoque arquitectural se le quiera dar (luego hablaremos m\u00e1s sobre esto).\u00a0<\/em>Sin embargo, como en Hiberus tenemos un equipo especializado en microservicios con varios a\u00f1os de experiencia, hemos recopilado 8 pasos que se han dado en todas nuestras migraciones:<\/strong><\/p>\n

      \n
    1. Es necesario identificar<\/strong> las partes del c\u00f3digo (dominios<\/strong>) que est\u00e1n altamente cohesionadas y bajo acopladas con el resto, puesto que son susceptibles de ser separadas a un microservicio aparte. Por ejemplo, si la aplicaci\u00f3n legada est\u00e1 construida en Java, sus paquetes nos pueden dar una idea de estas separaciones por dominio. Ejemplos de dominio pueden ser: usuarios, productos, tiendas…<\/span>\u00a0<\/span><\/li>\n
    2. Separar los dominios<\/strong> en distintos proyectos. Se pueden utilizar lenguajes de programaci\u00f3n distintos para cada proyecto, dependiendo de las necesidades de cada dominio. Nuestro consejo es que se trate de homogeneizar, a no ser que haya casos en los que de verdad merezca la pena implementar un dominio en un lenguaje de programaci\u00f3n espec\u00edfico. Ejemplo: queremos usar Python para el dominio de Business Intelligence porque hay muchas bibliotecas que nos pueden facilitar ese tipo de trabajo, pero no queremos usarlo en el resto de dominios, puesto que queremos un lenguaje fuertemente tipado.<\/span><\/li>\n
    3. Obtener un grafo de las dependencias existentes<\/strong> en el sistema legado monol\u00edtico entre los dominios identificados. Se puede utilizar alguna herramienta que analice el proyecto.<\/span><\/li>\n
    4. A partir de las dependencias, dise\u00f1ar una interfaz (dise\u00f1o\u00a0<\/strong><\/span>API\u00a0first<\/i><\/strong>)<\/strong> para cada uno de los dominios. Estas\u00a0APIs\u00a0(pueden ser REST,\u00a0GraphQL,\u00a0gRPC…) ser\u00e1n la nueva puerta de entrada a cada uno de los mismos. Esto significa\u00a0que\u00a0si el dominio de tiendas necesita algo del dominio de productos, deber\u00e1\u00a0utilizar alguna de las operaciones que ofrece el dominio de productos en su API.<\/span><\/li>\n
    5. Una vez se hayan dise\u00f1ado las interfaces, habr\u00e1 que implementarlas<\/strong>. Es en este momento cuando nos acordamos de que nuestro monolito ten\u00eda una \u00fanica base de datos y en las tablas se mezcla la informaci\u00f3n de distintos dominios. \u00bfQu\u00e9 hago ahora con la tabla \u201ccompras\u201d cuyas filas representan a un \u201cusuario\u201d que ha adquirido un \u201cproducto\u201d en una \u201ctienda\u201d? Como se puede apreciar, es s\u00edntoma de que hay otros dominios que no hab\u00edamos identificado en el paso 1 porque no estaban expl\u00edcitamente diferenciados en el c\u00f3digo pero s\u00ed lo estaban en la base de datos<\/strong>. El dominio de compras puede ser perfectamente v\u00e1lido, y una soluci\u00f3n a este tipo de problemas es reflejarlo en la nueva arquitectura. Es momento de migrar los datos a los nuevos esquemas de datos de cada uno de los diferentes microservicios. Este paso puede llegar a ser muy costoso<\/strong>, a la par que complicado<\/strong>. Por eso es necesario disponer de un equipo de profesionales altamente cualificado que sea capaz de llevar a cabo esta migraci\u00f3n de datos.<\/strong><\/span><\/li>\n
    6. Una vez todos y cada uno de los microservicios son sencillos<\/em>, hacen lo que tienen que hacer (y no m\u00e1s) con la ayuda (o no) de una o varias BBDD, es hora de integrarlos. Esto es, hacer que interact\u00faen entre ellos, convirtiendo las dependencias de m\u00f3dulos que hab\u00eda en el monolito en llamadas a sus APIs.<\/strong><\/span><\/li>\n
    7. Se deber\u00edan implementar\u00a0<\/strong><\/span>tests\u00a0<\/i>unitarios<\/strong>\u00a0<\/span><\/i>para cada uno de los microservicios\u00a0(entendiendo el microservicio como unidad), adem\u00e1s de\u00a0<\/strong><\/span>tests<\/i><\/strong>\u00a0de integraci\u00f3n<\/strong> que comprueben que saben trabajar en conjunto. Estos \u00faltimos deber\u00edan\u00a0tener en cuenta las particularidades que tiene todo sistema distribuido: p\u00e9rdida de mensajes, particiones de red, ca\u00edda de\u00a0los microservicios…<\/span><\/li>\n
    8. \u00a1A desplegar!<\/strong> Cada microservicio puede estar alojado en uno o varios servidores distintos, proporcionando: alta disponibilidad, elasticidad, escalabilidad, mantenibilidad y auditabilidad.<\/strong><\/span><\/li>\n<\/ol>\n

       <\/p>\n

      Antes hemos comentado que hablar\u00edamos m\u00e1s sobre enfoques arquitecturales<\/strong>, y es que, dentro de las arquitecturas de microservicios, podemos identificar, como m\u00ednimo, un par de enfoques:<\/p>\n

        \n
      • S\u00edncrono:<\/strong> se produce una\u00a0conversaci\u00f3n\u00a0<\/em>entre los microservicios, puesto que siguen un esquema de petici\u00f3n-respuesta. Este es el caso que hemos ejemplificado en los pasos anteriores, puesto que todos los microservicios exponen APIs s\u00edncronas.<\/li>\n
      • As\u00edncrono (event-driven):<\/strong> los microservicios no necesitan conocerse entre s\u00ed, sino que \u00fanicamente necesitan conocer un agente externo en el que van a publicar eventos de dominio<\/strong>. Estos eventos de dominio pueden ser, por ejemplo: \u00abse ha registrado un nuevo usuario que se llama Ra\u00fal, es de Huesca…\u00bb , \u00abla tienda XYZ se ha dado de baja\u00bb, etc. Apache Kafka<\/strong> y RabbitMQ <\/strong>son algunas de las tecnolog\u00edas con las que se pueden realizar este tipo de implementaciones. En Hiberus tenemos un equipo especializado en este tipo de tecnolog\u00edas.<\/li>\n<\/ul>\n

         <\/p>\n

        Para m\u00e1s detalle, en este webinar<\/strong> <\/em>hablamos alto y tendido sobre estos dos enfoques arquitecturales:<\/p>\n