Llegamos a ustedes gracias a:



Reportajes y análisis

Cómo hacer la transición a una arquitectura de microservicios

[02/11/2018] En este punto, ya debe saber qué son los microservicios y cómo funcionan. Ahora es el momento de abordar temas clave: el tema muy crítico de cómo abordar la transición a los microservicios.

Figura 1. Estructura básica de una aplicación monolítica.
Arquitectura microservicios
La necesidad de transición de microservicios

Una aplicación monolítica es muy grande (en términos de líneas de código) y compleja (en términos de interdependencias de funciones, datos, etc.), sirve a cientos de miles de usuarios en distintas regiones geográficas, y requiere varios desarrolladores e ingenieros de TI. Una aplicación monolítica puede parecerse a la Figura 1.

A veces, incluso con todas estas características, la aplicación puede funcionar bien al principio. Es posible que no encuentre desafíos en términos de escalabilidad o rendimiento de la aplicación. Pero con el tiempo y el uso, surgirán problemas, y pueden ser diferentes para diferentes aplicaciones.

Por ejemplo, para una aplicación web o en la nube, puede tener problemas de escalabilidad debido a que más usuarios consumen sus servicios, o puede resultar costoso y difícil lanzar nuevas actualizaciones regulares debido a tiempos de compilación más largos y pruebas de regresión. Como se muestra en la Figura 2, los usuarios o desarrolladores de aplicaciones monolíticas pueden experimentar uno o más problemas enumerados a la derecha.

Figura 2. Problemas potenciales con una aplicación monolítica.
Arquitectura microservicios

Ahí es cuando una migración a microservicios puede comenzar a parecer más que una idea moderna; sonará como un salvavidas. La transición será similar a la aplicación que se muestra en la Figura 3.

Figura 3. Transición de monolito a microservicios.
Arquitectura microservicios

Entonces, ¿cómo va a hacer tal cambio? Hay dos escenarios posibles:

  • Creación de una nueva aplicación.
  • Convertir o migrar una aplicación monolítica que ya existe.

El último escenario es mucho más probable, pero vale la pena conocer los entresijos de ambos escenarios, independientemente de su situación actual.

Creando una nueva aplicación con microservicios.

No he visto muchos escenarios reales en los que se crea una aplicación basada en microservicios desde cero. Normalmente, una aplicación ya está en su lugar, y la mayoría de las aplicaciones en las que he trabajado son más bien una transición a una arquitectura de microservicios desde una arquitectura monolítica. En estos casos, la intención de los arquitectos y desarrolladores siempre ha sido reutilizar parte de la implementación existente.

Pero a medida que las habilidades estén disponibles en el mercado y se publiquen algunas implementaciones exitosas, veremos más ejemplos de cómo crear aplicaciones basadas en microservicios desde cero, por lo que sin duda vale la pena explorar este escenario.

Supongamos que tiene todos los requisitos resueltos y está listo para entrar en el diseño de arquitectura de la aplicación que va a construir. Hay muchas mejores prácticas comunes en las que debe pensar al comenzar, las cuales se tratan en las siguientes secciones.

Preparación organizacional

La primera pregunta que debe hacerse es si su organización está lista para la transición a microservicios. Eso significa que los distintos departamentos de su organización ahora tienen que pensar de manera diferente acerca de cómo construir y lanzar software de las siguientes maneras:

  • Estructura de equipo. El equipo de aplicación monolítica (si existe) debe dividirse en varios equipos pequeños de alto rendimiento que conozcan o estén capacitados en las mejores prácticas de microservicios. Como vio en la Figura 3, el nuevo sistema consistirá en un conjunto de servicios independientes, cada uno responsable de ofrecer un servicio específico. Esta es una de las ventajas clave del paradigma de los microservicios: reduce los gastos generales de comunicación, incluidas las múltiples reuniones sin escalas. Los equipos deben estar organizados por problemas de negocios o áreas que intentan abordar. La comunicación se convierte entonces en el tiempo y el conjunto de estándares/protocolos a seguir para que estos microservicios puedan trabajar entre sí como una plataforma.
  • Cada equipo debe estar preparado para funcionar independientemente de los demás. Deben ser del tamaño de un equipo de SCRUM estándar; de lo contrario, la comunicación volverá a ser un problema. La ejecución es la clave, y cada equipo debe ser capaz de abordar las cambiantes necesidades comerciales.
  • Herramientas y formación. Una de las necesidades clave es la disposición de la organización para invertir en nuevas herramientas y capacitación de personas. Las herramientas y los procesos existentes, en la mayoría de los casos, tendrían que ser retirados y reemplazados por los nuevos. Esto requerirá una gran inversión de capital, así como una inversión en la contratación de personas con nuevas habilidades y la capacitación de los miembros del personal existentes. A largo plazo, si la decisión es correcta para obtener microservicios, las organizaciones verán ahorros y recuperarán la inversión.

Enfoque basado en servicios

A diferencia de las aplicaciones monolíticas, con los microservicios debe adoptar un enfoque basado en servicios auto sostenidos. Piense en su aplicación como un grupo de servicios acoplados que se comunican entre sí para proporcionar una funcionalidad completa de la aplicación. Cada servicio debe considerarse como un servicio independiente y autónomo con su propio ciclo de vida que puede ser desarrollado y mantenido por equipos independientes. Estos equipos pueden seleccionar entre una variedad de tecnologías, incluidos idiomas o bases de datos que mejor se adapten a las necesidades de sus servicios.

Por ejemplo, para un sitio de comercio electrónico, el equipo escribiría un servicio completamente independiente, como un microservicio de carrito de compras, con una base de datos en memoria; y otro, como un microservicio de pedidos, con una base de datos relacional. Una aplicación del mundo real puede usar microservicios para funciones básicas como autenticación, cuenta, registro de usuario y notificación con la lógica de negocios encapsulada en una puerta de enlace API que llama a estos microservicios en función del cliente y las solicitudes externas.

Solo un recordatorio: un microservicio puede ser un pequeño servicio implementado por un solo desarrollador, o un servicio complejo que requiere unos cuantos desarrolladores. Con microservicios, el tamaño no importa; todo depende de la función que debe proporcionar un servicio.

Otros aspectos que deben considerarse en este punto son la escala, el rendimiento y la seguridad. Las necesidades de escalamiento pueden ser diferentes y proporcionarse según sea necesario en cada nivel de microservicio. Se debe pensar en la seguridad en todos los niveles, incluidos los datos en reposo, la comunicación entre procesos, los datos en movimiento, etc.

Comunicación entre procesos (servicio a servicio)

Los aspectos clave en los que se debe pensar son el protocolo de seguridad y comunicación. La comunicación asíncrona es el camino a seguir, ya que mantiene todas las solicitudes en curso y no retiene los recursos durante largos períodos de tiempo.

El uso de un bus de mensajes como RabbitMQ puede resultar beneficioso para este tipo de comunicación. Es simple y puede escalar a cientos de miles de mensajes por segundo. Para evitar que el sistema de mensajería se convierta en un punto único de falla si se apaga, el bus de mensajería debe estar diseñado adecuadamente para una alta disponibilidad. Otras opciones incluyen ActiveMQ, que es otra plataforma de mensajería ligera.

La seguridad es clave en esta etapa. Además de seleccionar el protocolo de comunicación correcto, se pueden usar herramientas estándar de la industria como AppDynamics para monitorear y comparar la comunicación entre procesos. Cualquier anomalía debe ser reportada automáticamente al equipo de seguridad.

Cuando hay miles de microservicios, se vuelve complejo manejar todo. Explico cómo abordar estos problemas a través de los servicios de descubrimiento y las puertas de enlace API en el Capítulo 3.

Selección de tecnologia

La mayor ventaja de la transición a microservicios es que permite opciones. Cada equipo puede seleccionar de forma independiente el idioma, la tecnología, la base de datos, etc., que sean los más adecuados para el microservicio dado. Por lo general, en un enfoque monolítico, el equipo no tiene esta flexibilidad, así que asegúrese de no pasarla por alto y perder la oportunidad.

Incluso si un equipo está manejando múltiples microservicios, cada microservicio debe considerarse como un servicio autónomo, y debe analizarse. Al elegir la tecnología para cada microservicio, se debe tener en cuenta la escalabilidad, la implementación, el tiempo de compilación, las integraciones y la funcionalidad de los complementos, etc. Para microservicios con datos más ligeros, pero con un acceso más rápido, una base de datos en memoria puede ser la más adecuada, mientras que otros pueden compartir las mismas bases de datos relacionales o NoSQL.

Implementación

La implementación es la fase crítica; aquí es donde todo el conocimiento sobre capacitación y mejores prácticas es útil. Algunos de los aspectos críticos a tener en cuenta incluyen los siguientes:

  • Independencia. Cada microservicio debe ser altamente autónomo con su propio ciclo de vida, y ser tratado como tal. Necesita ser desarrollado y mantenido sin ninguna dependencia de otros microservicios.
  • Fuente de control. Se debe colocar un sistema de control de versiones adecuado, y cada microservicio debe cumplir con los estándares. La estandarización en un repositorio también es útil, ya que garantiza que todos los equipos utilicen el mismo control de origen. Ayuda en varios aspectos, como la revisión del código, que proporciona un fácil acceso a todo el código en un solo lugar. A largo plazo, tiene sentido tener todos los servicios en el mismo control de origen.
  • Entornos. Todos los entornos diferentes, como desarrollo, prueba, escenario y producción, deben estar debidamente protegidos y automatizados. La automatización aquí incluye el proceso de construcción; de esa manera, el código se puede integrar según sea necesario, principalmente a diario. Hay varias herramientas disponibles, aunque Jenkins es ampliamente utilizado. Jenkins es una herramienta de código abierto que ayuda a automatizar el proceso de compilación y lanzamiento del software, incluida la integración continua y la entrega continua (CI/CD).
  • A prueba de fallos. Las cosas pueden salir mal, y la falla del software es inevitable. Las fallas de manejo de los servicios posteriores deben abordarse en el desarrollo de microservicio. La falla de otros servicios debe ser elegante en la medida en que la falla sea invisible para el usuario. Esto incluye la administración de los tiempos de respuesta del servicio (tiempos de espera), el manejo de los cambios de API para los servicios posteriores y la limitación del número de reintentos automáticos.

Con los microservicios, no tenga miedo de reutilizar el código usando copiar y pegar, pero hágalo dentro de los límites. Esto puede causar algo de duplicación de código, pero es mejor que usar código compartido que puede terminar acoplando servicios. En microservicios, desea desacoplamiento, no acoplamiento apretado. Por ejemplo, escribirá código para consumir la respuesta de salida de un servicio. Puede copiar este código cada vez que llame al mismo servicio desde cualquier cliente. Otra forma de reutilizar el código es creando bibliotecas comunes. Varios clientes pueden usar la misma biblioteca, pero cada cliente debe ser responsable de mantener sus bibliotecas.

A veces puede ser un desafío cuando crea demasiadas bibliotecas y cada cliente mantiene una versión diferente. En ese caso, es posible que tenga que incluir varias versiones de la misma biblioteca, y el proceso de compilación puede volverse difícil debido a la compatibilidad con versiones anteriores y problemas similares. Dependiendo de sus necesidades, puede ir en cualquier dirección siempre que pueda controlar la cantidad de bibliotecas y versiones de los clientes y establecer un proceso estricto alrededor de ellas. Esto le ahorrará mucho de la duplicación de código.

Dado el gran número de microservicios, la depuración de un problema puede ser difícil, por lo que necesita hacer algún tipo de instrumentación en esta etapa. Una de las mejores prácticas es etiquetar cada solicitud con un ID de solicitud único y registrar cada una de ellas. Este ID único identifica la solicitud de origen y debe ser pasado por cada servicio a cualquier solicitud posterior.

Cuando ve problemas, puede rastrear claramente a través de los registros e identificar el servicio problemático. Esta solución será más efectiva si establece un sistema de registro centralizado. Todos los servicios deben iniciar sesión en todos los mensajes de este sistema compartido en un formato estandarizado, para que los equipos puedan reproducir los eventos según sea necesario desde un solo lugar, desde la infraestructura hasta la aplicación. Merece la pena mirar una biblioteca compartida para el registro centralizado. Existen varias herramientas de administración y agregación de registros en el mercado, como ELK (Elasticsearch, Logstash, Kibana) y Splunk, que son ideales.

Despliegue

La automatización es la clave durante el despliegue. Sin ella, el éxito con un paradigma de microservicios es casi imposible. Puede haber cientos o miles de microservicios, y para la entrega ágil, la automatización es una necesidad.

Piense en desplegar miles de microservicios y mantenerlos. ¿Qué pasa cuando uno de los microservicios deja de funcionar? ¿Cómo sabe qué máquina tiene suficientes recursos para ejecutar sus microservicios? Se vuelve muy complicado gestionar esto sin la automatización en su lugar. Se pueden usar varias herramientas, como Kubernetes y Docker Swarm, para automatizar el proceso de implementación.

Operaciones

La parte de operaciones del proceso también debe automatizarse. Nuevamente, estoy hablando de cientos o miles de microservicios: las capacidades organizativas necesitan madurar lo suficiente para manejar este nivel de complejidad. Necesitará un sistema de soporte, que incluye lo siguiente:

  • Desde la infraestructura hasta las APIs de la aplicación y el rendimiento de la última milla, todo debe ser monitoreado y se deben poner alertas automáticas con los umbrales adecuados. Considere la creación de paneles de control en vivo con datos y alertas que surgen durante los problemas.
  • Escalabilidad bajo demanda. Con microservicios, la escalabilidad es la tarea más simple. Aprovisione otra instancia del microservicio que desea escalar y simplemente póngala detrás del equilibrador de carga existente; y estará listo. Pero en un entorno escalado, esto también necesita ser automatizado. Se trata de configurar un valor entero para indicar la cantidad de instancias que desea ejecutar para un microservicio en particular.
  • Exposición de la API. En la mayoría de los casos, deseará exponer las APIs externamente para que los usuarios externos las consuman. Esto se hace mejor usando un servidor perimetral, que puede manejar todas las solicitudes externas. Puede usar la puerta de enlace API y el servicio de descubrimiento para hacer su trabajo, y puede usar un servidor perimetral por tipo de dispositivo (como dispositivo móvil o navegador) o caso de uso. Se puede usar una aplicación de código abierto creada por Netflix, llamada Zuul, para esta función y otras más.
  • Cortacircuitos. Enviar una solicitud a un servicio fallido no tiene sentido. Por lo tanto, se puede construir un interruptor automático que rastree el éxito y el fracaso de cada solicitud realizada a cada servicio. En el caso de fallas múltiples, todas las solicitudes a ese servicio en particular deben ser bloqueadas (romper el circuito) por un tiempo establecido. Una vez transcurrido el tiempo establecido, se debe realizar otro intento, y así sucesivamente. Una vez que la respuesta sea exitosa, reconecte el circuito. Esto debe hacerse a nivel de instancia de servicio. Hystrix de Netflix proporciona una implementación de interruptor de código abierto.

Migración de una aplicación monolítica a microservicios

Si bien la mayoría de las mejores prácticas para crear una nueva aplicación basada en microservicios también se aplican a la migración desde una aplicación monolítica existente, existen algunas pautas adicionales que, si se siguen, harán que la migración sea más sencilla y eficiente.

Aunque puede parecer correcto convertir toda la aplicación monolítica en una aplicación completamente basada en microservicios, puede no ser eficiente o puede ser muy costoso en algunos casos convertir todas las funciones o capacidades en microservicios. Después de todo, podría terminar escribiendo la aplicación desde cero. La forma correcta de migrar puede requerir un enfoque gradual, como se muestra en la Figura 4.

Figura 4. Pasos básicos de migración, de monolíticos a microservicios.
Arquitectura microservicios

La siguiente pregunta es: ¿Dónde comienzo con la aplicación monolítica actual? Si la aplicación es realmente antigua, si llevaría mucho tiempo y si sería difícil sacar las piezas (es decir, si el nivel de cohesión es muy alto), probablemente sea mejor comenzar desde cero. En otros casos, donde partes del código pueden deshabilitarse rápidamente y la arquitectura tecnológica no está completamente desactualizada, es mejor comenzar con la reconstrucción de los componentes como microservicios y reemplazar el código antiguo.

Criterios de microservicios

La pregunta entonces es qué componentes deben migrarse primero o incluso migrarse en absoluto. Eso me lleva a lo que llamo los "criterios de microservicios", que describen una de las posibles formas de seleccionar y priorizar las funciones que deben migrarse a los microservicios. Son un conjunto de reglas que establece, que califica o descalifica la conversión de los componentes de su aplicación monolítica existente a microservicios, dadas las necesidades de la organización en ese momento.

Ese "momento" es muy importante aquí, porque con el tiempo las necesidades de la organización pueden cambiar, y es posible que tenga que regresar y convertir más componentes a microservicios más adelante. En otras palabras, con necesidades cambiantes, los componentes adicionales de su aplicación monolítica pueden calificar para la conversión.

Estas son las mejores prácticas que pueden considerarse como criterios de microservicios durante el proceso de conversión:

  • Necesita determinar qué funciones son altamente utilizadas. Convierta primero los servicios altamente utilizados o la funcionalidad de la aplicación como microservicios. Recuerde: un microservicio realiza solo un servicio bien definido. Tenga en cuenta el principio y divida la aplicación en consecuencia.
  • Es probable que haya componentes que no estén funcionando bien, y otras alternativas estén fácilmente disponibles. Es posible que haya un complemento de código abierto disponible o que desee crear un servicio desde cero. Una de las cosas clave a tener en cuenta es el límite de un microservicio. Siempre que diseñe su microservicio para que haga una sola cosa bien, es bueno. Determinar el límite a menudo será difícil, y le resultará más fácil hacerlo con la práctica. Otra forma de ver el límite del microservicio es que debería poder reescribir todo el microservicio en unas pocas semanas (si es necesario) en lugar de tomarse unos meses para volver a escribir el servicio.
  • Mejores alternativas tecnológicas o programación políglota. Se pueden usar lenguajes específicos de dominio para ayudar con los dominios problemáticos. Esto es particularmente aplicable a los componentes para los que recibió muchas solicitudes de mejoras en el pasado y espera que continúen. Si piensa que no solo se puede simplificar la implementación de un componente de este tipo utilizando un nuevo lenguaje o capacidad en el mercado, sino también que el mantenimiento y las actualizaciones futuras serán más fáciles, ahora es el momento adecuado para abordar dichos cambios. En otros casos, puede encontrar otro lenguaje que ofrezca abstracciones más sencillas para la concurrencia que la utilizada actualmente. Puede usar el nuevo idioma para un microservicio determinado, mientras que el resto de la aplicación aún puede usar un idioma diferente. Del mismo modo, es posible que desee que algunos microservicios sean extremadamente rápidos y que decida escribirlos en C para obtener las máximas ganancias, en lugar de escribir en otro lenguaje de alto nivel. La conclusión es aprovechar esta flexibilidad.
  • Alternativas de almacenamiento o persistencia políglota. Con el aumento de Big Data, algunos componentes de la aplicación pueden proporcionar valor al utilizar bases de datos NoSQL en lugar de bases de datos relacionales. Si alguno de estos componentes en la aplicación puede beneficiarse de esta alternativa, entonces puede ser el momento adecuado para cambiarse a NoSQL.
  • Estos son los aspectos clave que debe considerar para cada servicio o función en su aplicación monolítica, y primero debe priorizar la conversión de dichos elementos. Una vez que haya derivado el valor de los elementos de prioridad alta, puede aplicar otras reglas.
  • Solicitudes de modificación. Una cosa importante a seguir en cualquier ciclo de vida del software, son las nuevas mejoras o solicitudes de cambios. Las características que tienen un mayor número de solicitudes de cambio pueden ser adecuadas para microservicios debido al tiempo de compilación y despliegue. La separación de dichos servicios reduce el tiempo de compilación y despliegue, ya que no tendrá que compilar toda la aplicación, solo el microservicio modificado, lo que también puede aumentar el tiempo de disponibilidad para el resto de la aplicación.
  • Siempre hay algunas partes de la aplicación que agregan complejidad de implementación. En una aplicación monolítica, incluso si una característica particular está intacta, aún debe pasar por el proceso completo de construcción y despliegue. Si existen tales casos, es beneficioso cortarlos y reemplazarlos con microservicios para que el tiempo total de implementación se reduzca para el resto de la aplicación monolítica. Hablamos más sobre esto después de aprender sobre los contenedores.
  • Servicios de ayuda. En la mayoría de las aplicaciones, el servicio principal depende de algunos de los servicios de ayuda. La falta de disponibilidad de tales funciones de ayuda puede afectar la disponibilidad del servicio central. Por ejemplo, en la aplicación de la mesa de ayuda, la emisión de boletos depende del servicio de catálogo de productos. Si el servicio de catálogo de productos no está disponible, el usuario no puede enviar un ticket. Si existen tales casos, los servicios de ayuda se deben convertir en microservicios y deben estar disponibles de forma adecuada para que puedan prestar un mejor servicio a los servicios principales. (Estos también se denominan servicios de interruptores automáticos).

Dependiendo de la aplicación, estos criterios pueden requerir que la mayoría de los servicios se conviertan en microservicios, y eso está bien. La intención aquí es simplificar el proceso de conversión para que pueda priorizar y definir la hoja de ruta para su migración a una arquitectura basada en microservicios.

Rearquitectura de los servicios

Una vez que haya identificado las funciones que se migrarán como microservicios, es hora de comenzar la rearquitectura, o rearchitecting, de los servicios seleccionados siguiendo las mejores prácticas del escenario anterior. Aquí están los aspectos a tener en cuenta:

  • Definición de microservicios. Para cada función, defina los microservicios apropiados, que deben incluir el mecanismo de comunicación (API), la definición de la tecnología, etc. Considere los datos que utiliza su función existente, o cree y planifique en consecuencia la estrategia de datos para microservicios. Si la función está en bases de datos pesadas como Oracle, ¿tiene sentido pasarse a MySQL? Determine cómo va a gestionar la relación de datos. Finalmente, ejecute cada microservicio como una aplicación separada.
  • Código refactor. Puede reutilizar parte del código si no está cambiando el lenguaje de programación. Piense en la capa de almacenamiento / base de datos: compartida vs. dedicada, en memoria vs. externa. El objetivo no es agregar nuevas funciones a menos que sea necesario, sino volver a empaquetar el código existente y exponer las APIs necesarias.
  • Antes de comenzar a codificar, decida el control de origen y el mecanismo de control de versiones y asegúrese de que se sigan estos estándares. Cada microservicio debe ser un proyecto separado e implementado como una aplicación separada.
  • Migración de datos. Si decide crear una nueva base de datos, también tendrá que migrar los datos heredados. Esto generalmente se maneja al escribir scripts SQL simples, dependiendo de su origen y destino.
  • Código monolítico. Inicialmente, deje el código existente en su lugar en la aplicación monolítica en caso de que tenga que retroceder. Puede actualizar el resto del código para usar los nuevos microservicios o, mejor, dividir el tráfico de su aplicación, si es posible, para usar tanto la versión monolítica como la de microservicios. Esto le brinda la oportunidad de probar y vigilar el rendimiento. Una vez que esté seguro, puede mover todo el tráfico a microservicios y deshabilitar o deshacerse del código anterior.
  • Creación, implementación y gestión independientes. Construya y despliegue cada microservicio de forma independiente. A medida que desarrolla nuevas versiones de microservicios, puede volver a dividir el tráfico entre la versión anterior y la nueva por algún tiempo. Esto significa que puede tener dos o más versiones del mismo microservicio ejecutándose en el entorno de producción. Parte del tráfico del usuario se puede enrutar a la nueva versión de microservicio, para asegurarse de que el servicio funciona correctamente. Si la nueva versión no está funcionando de manera óptima o como se esperaba, es fácil revertir todo el tráfico a la versión anterior y enviar la nueva versión al desarrollo. La clave aquí es configurar el proceso de implementación automatizada repetible y avanzar hacia la entrega continua.
  • Eliminación de código antiguo. Puede eliminar su código temporal y eliminar los datos de la ubicación de almacenamiento anterior solo después de haber verificado que todo se haya migrado correctamente y que funcione como se espera. Asegúrese de hacer copias de seguridad en el camino.

Un enfoque híbrido a los microservicios.

Al escribir una nueva aplicación, los desarrolladores pueden seguir directamente los principios de arquitectura de los microservicios y el plano para construir la aplicación de software.

Los desarrolladores a veces siguen un tipo de enfoque híbrido de microservicios y monolíticos. En este caso, pueden desarrollar parte de su aplicación como microservicios, y el resto siguiendo prácticas estándar de SOA/MVC basadas en ciertos criterios. La idea es que no todos los componentes de la aplicación pueden calificar como microservicios.

Los microservicios ofrecen mucha flexibilidad, pero esta flexibilidad tiene un costo. El enfoque híbrido consiste en equilibrar los aspectos de flexibilidad y costo con el entendimiento de que, con el tiempo, los componentes pueden extraerse de la parte monolítica y convertirse en microservicios según sea necesario. La clave es tener en cuenta ambos enfoques, junto con los criterios de microservicios, durante esta transición.