Migrar una aplicación monolítica a una arquitectura de microservicios

Introducción

Para seguir con mi serie de artículos sobre la arquitectura de microservicios, hoy te voy a presentar como puedes migrar una aplicación monolítica a una arquitectura de microservicios.

Lo más importante es saber reconocer los contextos limitados de tu aplicación. Una vez que definiste uno, puedes empezar a migrarlo a un microservicio.

La importancia de los contextos limitados

Una diferencia importante entre la arquitectura de microservicios y las arquitecturas orientadas a servicios (SOA) tradicionales, es que la frontera entre los diferentes servicios tienen que respetar los contextos limitados (Bounded Contexts). La idea de los contextos limitados es que cada servicio tenga una responsabilidad del mundo real y tenga una interfaz explicita.

Si en lugar de separar tus servicios por contextos limitados decides separar por contextos tecnológicos, seguramente vas a tener problemas. Por ejemplo separar el backend, el frontend y la base de datos de tu aplicación y tener un equipo para cada uno requiere para cada cambio comunicación entre los equipos, lo que hace perder tiempo a todo el mundo.
En la arquitectura de microservicios en cambio, cada servicio está responsable de toda una funcionalidad, desde la base de datos hasta el sitio web.

Es la diferencia entre un corte horizontal y un corte vertical. En lugar de tener un equipo de frontend, un equipo de backend y un equipo de base de datos, se trata de tener un equipo de un servicio inventario y un equipo de un servicio de ventas, cada equipo incluyendo personas de frontend, de backend y de base de datos.

Pero saber reconocer estos contextos limitados es un arte difícil que viene con la experiencia.

Con cual primer microservicio empezar

Netflix empezó su primer microservicio con una funcionalidad que no era critica para el sistema: su portal de empleo. Es decir la página que tenían en su sitio web para proponer puestos de trabajo en Netflix. Esta funcionalidad no era critica en el sentido que si el portal no funciona durante una hora, es grave, pero no impacta Netflix en su actividad principal que es el streaming de vídeo.

Este patrón es muchas veces recomendado como una buena manera de empezar con los microservicios: escoger dentro de su aplicación monolítica una funcionalidad bien definida, chiquita y que no sea critica, y extraerle en su propio microservicio.

Una vez que el equipo ya tiene experiencia con su primer microservicio, se puede concentrar en buscar una segunda funcionalidad quizás un poco más importante y pasarla a un microservicio.

Repites este proceso hasta que tu aplicación ya no sea monolítica, pero más bien esté compuesta por microservicios.

Este patrón se llama the strangler pattern, el patrón estrangulador, porque como vides estranguladoras que crecen y terminan matando al árbol huésped, los microservicios crecen poco a poco y reemplazan la aplicación monolítica. Puedes encontrar más detalles en este articulo (en inglés).

Lo peor que puedas decidir hacer es pasar tu aplicación monolítica a una arquitectura de microservicios en un solo paso, haciendo todo al mismo tiempo. Eso sin duda te va a dar muchos problemas y te va a costar mucho tiempo y trabajo. Siempre cuando sea posible, cualquier cambio a una aplicación que ya esté en producción se debería hacer de manera progresiva.

Conclusión

Vimos como se debe abordar una migración de un sistema monolítico a una arquitectura de microservicios, para reducir lo más posible los riesgos relacionados a este proceso. Puedes intentar con un microservicio chiquito para darte cuenta de los esfuerzos necesarios y de allí decidir si decides seguir implementando esta arquitectura, o si en cambio los costos son demasiado altos para justificar este trabajo.

Si ya estás decidido a intentarlo, te recomiendo mucho el libro Building Microservices: Designing Fine-Grained Systems, de Sam Newman, que es la referencia sobre el tema.

¡Como siempre, si tienes una pregunta, déjame un comentario y intentaré ayudarte!