• ¿Porque abordar la transformación a una arquitectura basada en microservicios?

• Principios tecnológicos

• Marco de trabajo

• Estrategia teórica y plan general

• Precondiciones antes de empezar

• Hitos clave y plan técnico

• Patrones de refactorización

• Conclusiones y recomendaciones Onesait

¿Porque abordar la transformación a una arquitectura basada en microservicios?

Muchos productos con cierta historia y cuya arquitectura técnica no ha sido actualizada u optimizada para ser explotada en Cloud se preguntan porque deberían migrar a una arquitectura de microservicios y cuales son los beneficios potenciales que podrían conseguir. 

Precisamente, el comienzo idóneo es conocer esos teóricos beneficios de las arquitecturas de microservicios (MSA), para después buscar aquellos puntos concretos que queremos atacar y mejorar en un posible proyecto de migración.

Open

Principios tecnológicos

Que debe cumplir un microservicio desde el punto de vista Onesait:

• Tiene el objetivo de descomponer granularmente la funcionalidad.

• Se ejecuta en un proceso y es desplegado de  forma independiente a los demás.

• Es altamente:

  • Mantenible

  • Resiliente

  • Escalable

  • Testeable

• Se diseña y desarrolla minimizando acoplamiento , a través de APIs y eventos y dominios de datos independientes.

• Debe ayudar a Incrementar la frecuencia de entregas y versiones de funcionalidad.

Qué  podemos encontrar en el camino del monolito a microservicios  dependiendo de la granularidad de los servicios y la separación de recursos:

Microservicio

Es un componente de aplicación con una funcionalidad muy acotada (una parte concreta de un negocio), altamente desacoplado, encapsulado físicamente, que se pueden implementar, desarrollar y ejecutar/escalar independientemente.

Además, estos componentes son propietarios del dominio de datos que manejan de manera exclusiva y ningún otro componente puede interactuar con ese dominio si no es a través de la API o mecanismo de interoperabilidad del microservicio.

Servicio/miniservicio

Concepto similar a microservicio, pero con un alcance funcional mucho más amplio (en ocasiones abarcando dominios completos de negocio) y restricciones arquitectónicas relajadas (por ejemplo, compartiendo dominios y bases de datos).

Al igual que un microservicio, el servicio es una aplicación altamente desacoplada, encapsulada físicamente que se pueden implementar, desarrollar y ejecutar/escalar independientemente.

Macroservicio

Es un componente que encapsula lógicamente la funcionalidad dentro de una aplicación monolítica. No tiene por qué estar desacoplada, ni se pueden implementar y ejecutar/escalar de forma independiente. Además, comparte con el resto de macroservicios el dominio y base de datos.

Monolito

Es una componente no modular que alberga toda la funcionalidad de una aplicación, encapsulada físicamente junta altamente cohesionada y que no permite implementar, ejecuatar/escalar ciertas piezas de manera independiente.

Marco de trabajo

Que conceptos y conocimientos son necesarios para abordar un proyecto de migración de esta dimensión:

• Conocimiento de los principales patrones (extensión, Split, strangle) y criterios (DDD, funcionalidad, recursos...) de refactorización para elegir los más adecuados.

• Cultura y metodología Agile y DevOps

• Automatización de la integración y despliegue - CI/CD

• Automatización de test y calidad.

• Dominio tecnológico:

  • Rest API y OpenAPI3

  • Event Driven (Kafka) y caché (hazelcast)

  • Docker y Kubernetes

  • Patrones cloud, IAM, etc…

Estrategia teórica y plan general

La visión más extrema de los microservicios (lado derecho de la imagen) es la que lleva al máximo los beneficios e impacto,  pero también la que es más compleja de diseñar, conseguir y mantener en una migración. Tanto es así que desde Onesait somos partidarios de encontrar un equilibrio coste/beneficio que determine la escala y granularidad que debemos tener en nuestra arquitectura sin tener que conseguir que todo sea microservicios llevados a la máxima expresión, y siendo totalmente válidos escenarios con miniservicios o incluso combinaciones de granularidad.

Open

Precondiciones antes de empezar

Hitos clave y plan técnico

Bajo nuestra experiencia se pueden identificar una serie de hitos intermedios que pueden formar parte de un proyecto de migración a microserivios para conseguir  llegar a la meta. En la imagen de más abajo se pueden ver algunos de ellos.

Como se indica de manera constante, es clave la iteración continua hasta lograr los objetivos, y también la evaluación para determinar el punto donde seguir refactorizando nuestro código deja de tener sentido. En esta situación, hay que tener en cuenta que el paso 6 de la imagen es el que lleva a tener microservicios "puros" y totalmente independientes, pero también es un paso que  infiere una gran complejidad  de consistencia de datos, así como cambios grandes de paradigma de programación etc etc. Es clave tener claro si merece la pena abordar por coste y complejidad esa transformación o es preferible quedarse en el hito 5 si nuestra solución ya es eficiente y cubre los objetivos marcados. 

Dentro del marco de referencia y aceleradores de arquitectura podrás encontrar información detallada que ayudará a completar con éxito cada etapa propuesta.

Patrones de refactorización

Algunos patrones extendidos en el sector que se suelen utilizar en los proyectos de migración a microservicios y que recomendamos conocer ya que ayudará a tomar decisiones son:

Conclusiones y recomendaciones Onesait

• MSA es un pilar tecnológico para la consecución de la estrategia de producto Onesait:

  • Crear productos cloud con explotación As a Service mantenibles, optimos y rentables.

  • Mejorar el time-to-market e iterar rápidamente.

• El uso de MSA debe tener un claro impacto en negocio, de otro modo no es el camino a seguir ya que incluye complejidad en nuestras arquitecturas de software.

• Se debe tener claro que una orientación a microservicios no tiene sentido si no va acompañado de metodologías ágiles y dominio de nuevas tecnologías y disciplinas cloud, CI/CD, docker, kubernetes, etc, así que tú equipo debe estar preparado.

• Tener docker o APIs por si solo no dan el titulo de microservicios a nuestra arquitectura

• No sólo los microservicios de manual son válidos. Hay que centrarse en servicios (mini o micro) que ayuden a cumplir con nuestros objetivos aunque en ocasiones no sean granulares, o compartan BBDD.

• La experiencia es importante para el éxito en el movimiento a los microservicios, pero también la necesidad de realizar PoCs, iterar hasta encontrar la solución optima, así que no planifiques exclusivamente un happy path.