Beneficios y costos de la arquitectura de microservicios y en qué casos usarla

Introducción

En mi último artículo hice una presentación muy rápida de lo que es la arquitectura de microservicios. En el artículo de hoy, vamos a entrar en más detalles.

Vamos en un primer paso enumerar los beneficios y los costos que tiene esta arquitectura, para analizar en qué contextos tiene sentido usarla.

Los beneficios

Unos de los beneficios de la arquitectura de microservicios:

• permite una programación políglota: los microservicios pueden estar escritos en diferentes lenguajes de programación según la necesidad. Si un microservicio necesita mucha velocidad, lo puedes escribir en Rust o en Go, en caso contrario lo puedes escribir a un alto nivel de abstracción usando Ruby, Python o Node.js. Naturalmente, no es aconsejable usar diez lenguajes de programación diferentes para diez microservicios, porque va a agregar mucha complejidad en tu organización.
• más fácil de escalar la aplicación: porque se pueden escalar los microservicios más solicitados (que forman el cuello de botella) sin tener que escalar toda la aplicación. Por ejemplo cada microservicio podría usar una máquina virtual, mientras el más solicitado se puede escalar sobre más máquinas. Esto resulta en costos menores de alojamiento.
• más fácil de entender: los microservicios son más fáciles de entender individualmente, porque cada microservicio tiene una función precisa y es bastante independiente. Algunas personas aconsejan que un microservicio se debería poder reescribir desde cero en menos de dos semanas.
• más robustez: la aplicación puede seguir funcionando aunque un microservicio no critico haya fallado. Por ejemplo en la tienda de Amazon la funcionalidad de recomendaciones de otros productos está implementada usando un microservicio. En caso de que falle este microservicio, las recomendaciones no aparecen en el sitio web, pero la venta que es el corazón de Amazon sigue funcionando sin que muchos usuarios se den cuenta del problema.
• se acopla mejor con la estructura de la organización: en el contexto de empresas muy grandes, cada equipo se encarga totalmente de un microservicio: la arquitectura, el diseño, la operación, el despliegue etc. Esto ayuda mucho a tener más independencia entre los equipos y evitar tener que solicitar varios equipos diferentes para sacar una nueva funcionalidad, resultando en una empresa mucho más ágil. Según la Ley de Conway, los microservicios permiten tener una mejor estructura en tu organización que facilita la comunicación.

Últimamente la arquitectura de microservicios está muy de moda, porque la mayoría de las empresas grandes las están implementando. Podríamos pensar que todos esos beneficios y el hecho que las empresas lideres lo estén usando justifica que usemos esta arquitectura todo el tiempo, ¿no cierto?

Los costos

Resulta que la arquitectura de microservicios también tiene muchos costos. Estos son unos de los más importantes:

• mayor complejidad de operación: con un monolito, cada vez que despliegues, despliegues solamente un servicio. Ahora, imagina que tienes que desplegar 5 microservicios. Seguramente el esfuerzo necesario va a aumentar drásticamente. Si no tienes todos tus procesos de operación automatizados, desde el despliegue hasta la creación y el mantenimiento de tu infraestructura de alojamiento, vas a perder mucho tiempo configurando todos los servidores que necesitas y comprobar que siguen funcionando.
• difícil de cambiar las junturas entre los servicios: si usaste microservicios demasiado temprano en tu aplicación y te das cuenta que no definiste bien sus fronteras, puede resultar muy costoso arreglar este error. En algunos casos es aconsejable juntar todos los microservicios en un monolito, arreglar las cosas allí para después definir mejores microservicios una vez que sus responsabilidades estén mejor definidas.
• más difícil de depurar: si hay un defecto en tu microservicio de pagos, puede ser que esto resulte en un error en otro microservicio. Es mucho más difícil rastrear de dónde viene el problema cuando usas microservicios. ¿Cómo juntar los logs de los microservicios, para encontrar la causa de un error?
• problemas de sistemas distribuidos: varios de los puntos ya mencionados tienen que ver con la complejidad inherente al trabajar con sistemas distribuidos. Hasta ahora los sistemas distribuidos es un campo en lo cual se hace mucha investigación. ¿Qué pasa si un microservicio falla, hace fallar a los otros microservicios? ¿Cómo rastrear una transacción lógica que necesita varios microservicios? ¿Cómo hacer un rollback a la misma? ¿Cómo saber si el microservicio falló, o si solamente se demora en responder? ¿Cómo setear los diferentes timeouts? ¿Cómo estar seguro que los datos de tus microservicios estén sincronizados?

Por el hecho que la arquitectura de microservicios no sea una bala de plata, es decir una solución a todos los problemas del desarrollo, veamos ahora en qué casos tiene sentido implementarla.

Cuando usar microservicios

Todos los beneficios presentados arriba se vuelven muy importantes cuando la aplicación tiene una complejidad alta. Si no, los costos resultan más importantes que los beneficios.
El gráfico que sigue resume muy bien este concepto: la arquitectura de microservicios tiene sentido para proyectos avanzados y bastante complejos.

El costo de la arquitectura de microservicios según la complejidad del proyecto. Del blog de Martin Fowler.

Según el criterio de Martin Fowler, durante su charla en la XConf Latinoamérica en Quito este último 30 de septiembre, un equipo de desarrollo de menos de 12 personas seguramente no necesita una arquitectura de microservicios.

Es de mi opinión que en Ecuador pocas empresas desarrollan aplicaciones que tengan la complejidad necesaria para justificar el uso de una arquitectura de microservicios. Así que si estás trabajando en una empresa no muy grande y que están pensando en implementar microservicios, porque es un concepto que está de moda, ¡piénsenlo dos veces!

¿Tiene sentido empezar un nuevo proyecto con microservicios?

Una pregunta que seguramente tienes, es si tiene sentido empezar un nuevo proyecto con microservicios desde un principio.

Primer punto, como vimos arriba, si la aplicación nunca va a tener la complejidad necesaria o el equipo va a ser muy grande, entonces no debería ser interesante usar la arquitectura de microservicios.

¿Pero qué pasa si sabes que en el futuro vas a necesitarlo, porque tienes requerimientos precisos de pasar a escala o que sabes que la aplicación va a ser muy complicada? ¿En este caso no deberías empezar desde un principio usando la arquitectura de microservicios?

De todo lo que leí hasta ahora, es aconsejado siempre empezar con un monolito.

La primera razón es que al principio del proyecto y siguiendo la metodología ágil, quieres sacar un MVP (Producto Mínimo Viable) al mercado lo más rápidamente posible. Empezar implementando una arquitectura de microservicios tiene un costo de operación alto que va a atrasar tu avance, atrasando el TTM (Time To Market, el plazo de lanzamiento).

La segunda razón y quizás la más importante, es que si te equivocas en dónde separar tus microservicios, arreglarlo va a ser muy costoso. Por esta razón se aconseja crear un microservicio solamente cuando tienes una idea muy precisa de cual va a ser su contexto limitado (Bounded Context). La idea de los contextos limitados es que cada servicio tenga una responsabilidad del mundo real y una interfaz explicita. Una vez que tus microservicios están definidos, pasar código del uno al otro es algo muy complicado, mucho más complicado si quieres pasar código de un lado al otro dentro de un monolito.

Un ejemplo de contextos limitados. Referencia.

Para más detalles sobre los argumentos de empezar con un monolito, te aconsejo leer este excelente artículo de Martin Fowler.

Conclusión

La arquitectura de microservicios sin duda tiene muchas ventajas en algunos contextos y se volvió muy famosa por el hecho que una mayoría de las empresas grandes de Norte-América estén migrando a ella. En particular permite a un producto escalar a totalmente otros niveles, lo que es una ventaja muy importante en la Sillicon Valley donde cualquier startup se puede volver el próximo Facebook en pocos meses.

Sin embargo es importante resistir al efecto de moda y interesarse de cerca a la viabilidad de una arquitectura de microservicios en el contexto de tu empresa para no terminar en más problemas.

A pesar de esta advertencia, la arquitectura de microservicios es algo muy interesante y usa muchos conceptos que pueden traerte muchos beneficios si les implementas individualmente.