Cuándo usar microservicios

1. Arquitectura monolítica
2. Arquitectura basada en microservicios
3. ¿Cuándo usar microservicios?
4. Referencias

Hablar de arquitecturas actuales y escalables pasa hoy en día por hablar de microservicios. Son la “navaja suiza “de las arquitecturas, algo que se supone que sirve para hacer que todo funcione y, lo que ya funciona, lo haga mejor. Pero no siempre es así.

Los microservicios, o arquitecturas basadas en microservicios, surgen como contraposición y evolución a la clásica arquitectura monolítica, o monolito. Ambas soluciones presentan una serie de ventajas e inconvenientes, que trataremos en el resto del artículo, y al final de este, podremos concluir en qué situaciones es más conveniente el uso de una u otra.

Pero para ello, empecemos definiendo conceptos, ¿Qué es una arquitectura monolítica? ¿Qué es una arquitectura basada en microservicios? ¿Cuándo es más conveniente una u otra?

Arquitectura monolítica

El modelo tradicional de arquitectura para aplicaciones de servidor es la llamada arquitectura monolítica, la cual consiste en una unidad única y autocontenida, independiente de otras aplicaciones. Esto significa que la base de código es única, y acopla toda la lógica de negocio.

Algunas de las ventajas que presenta un monolito son las siguientes:

Facilidad de gestión del código: Una base única de código facilita su gestión en un repositorio único.

• Facilidad de despliegue: Una base única de código hace el despliegue muy sencillo.
• Desarrollo simplificado: El desarrollo de una aplicación con una base única de código simplifica las tareas de desarrollo.
• Alto rendimiento: En un sistema centralizado las APIs pueden hacer tareas que en un sistema distribuido realizarían varias APIs, reduciendo la sobrecarga, y mejorando el rendimiento.
• Facilidad de testeo: Al ser una pieza única y centralizada, el testeo es mucho más sencillo que en una aplicación distribuida.
• Facilidad de depurado: la depuración de un sistema centralizado hace mucho más sencilla la trazabilidad de una petición, así como encontrar y solventar incidencias.
• Facilidad de comprensión: la sobrecarga cognitiva de un proyecto centralizado es menor que la de un proyecto distribuido.

Por todas estas cuestiones, los monolitos suelen ser la primera elección de arquitectura de la inmensa mayoría de proyectos.

Pero según van creciendo más y más, los proyectos se vuelven cada vez más inmanejables. Y es dónde las desventajas de esta arquitectura afloran. ¿Cuáles son?:

• Disminución de la velocidad de desarrollo: Según va creciendo un proyecto, el añadir nuevas funcionalidades, o incluso el solventar errores, se va convirtiendo en un proceso más complejo y mucho más lento.
• Escasa escalabilidad: Un monolito no puede escalar partes independientes del monolito, ha de escalar todo el monolito, lo cual complica mucho la escalabilidad y la hace mucho más costosa a nivel de tiempo y recursos.
• Falta de flexibilidad: Cambios en el lenguaje o en el framework no se pueden acotar a una parte del proyecto, han de aplicarse al proyecto completo, haciendo que un cambio en dichas tecnologías sea mucho más costoso a nivel de tiempo y recursos.
• Dificultad de despliegue: Cualquier cambio en el monolito implica su despliegue completo, lo cual suele implicar una elevada dificultad y tiempos de parada no despreciables.
• Punto único de fallo: Debido a su alto grado de acoplamiento, la falta de funcionamiento de algún servicio puede y suele implicar la caída de la aplicación por completo.

Arquitectura basada en microservicios

Los microservicios, son la evolución natural de las arquitecturas monolíticas. Se basan en una serie de servicios que se despliegan de manera independiente. Estos tienen su propia lógica de negocio, sus propios almacenes de datos, y un propósito específico.

Es por ello que actividades como la actualización, despliegue, testeo y escalado suceden dentro de cada servicio y de manera independiente al resto que componen la arquitectura.

Los microservicios desacoplan las cuestiones específicas de negocio y de dominio en distintas bases de código, separadas e independientes. Por tanto, aumentan la complejidad de la arquitectura. Sin embargo, dicha complejidad está separada en piezas más pequeñas y manejables, que funcionan de manera independiente de las otras, cada una con su base de código específica, que implementan cuestiones de negocio y de domino específicas, manteniendo así el conjunto desacoplado.

Veamos una lista de las ventajas de los microservicios:

• Agilidad: Su misma estructura promueve el uso de metodologías ágiles que permiten trabajar con equipos más pequeños que realicen despliegues de manera frecuente.
• Escalado flexible: Cuando algún servicio alcanza su capacidad de carga máxima, nuevas instancias de dicho servicio pueden desplegarse de manera rápida y sencilla, de manera que disminuyamos el nivel de carga global del servicio. Es por ello que los servicios deben ser multi-tenant y stateless  , en la medida de lo posible.
• Despliegue continuo: Podremos tener ciclos de lanzamiento más frecuentes y rápidos, llegando incluso a varios despliegues al día.
• Altamente mantenible y testable: La implementación de nuevas funcionalidades y, en su caso, el roll-back a estados previos, es mucho más sencillo, reduciendo el time-to-market de nuevas versiones. Adicionalmente, es mucho más sencillo el aislar y solventar errores.
• Despliegues individuales: Al estar separado en servicios, los despliegues son sencillos y rápidos, afectando solo a cada servicio individual.
• Flexibilidad tecnológica: Los microservicios facilitan que cada equipo de desarrollo de un servicio decida las herramientas y tecnologías a usar, de manera independiente de la del resto de los servicios.
• Alta disponibilidad: Desplegar cambios en un servicio sin preocuparse de que pueda provocar la caída entera de la aplicación.
• Tolerancia a fallos: Como cada servicio corre en su propio espacio de procesamiento y está desacoplado del resto de los servicios, errores en servicios individuales no implican una parada completa de la aplicación.

Por esto y por mucho más, son muchos los defensores de los microservicios. Pero no son la panacea que todo lo cura. Proporcionan una serie de ventajas importantes, pero también tienen una serie de desventajas como, por ejemplo:

• Complejidad de desarrollo: Los microservicios, frente a un monolito, añaden complejidades al desarrollo, pues el número de servicios crece y están en mayor cantidad de servidores, cada uno manejado por un equipo distinto, lo cual puede derivar en un aumento en la complejidad del desarrollo, y a una disminución drástica del rendimiento.
• Gastos de infraestructura exponenciales: Ahora cada servicio tiene sus repositorios de código, infraestructuras de alojamiento, comunicaciones, monitorización, etc., multiplicando los costes de mantenimiento.
• Sobrecarga de gestión: Los distintos equipos encargados de cada servicio deben gestionar la gestión y comunicación para coordinar y actualizar la interconexión de dichos servicios.
• Dificultad de depurado: Los sistemas distribuidos, con sistemas de logs distribuidos, añaden un nivel de complicación adicional al depurado de una aplicación.

• Dispersión de tecnologías: Sin la necesidad de ceñirse a una tecnología concreta, los microservicios tienden a implicar cada vez más herramientas, lenguajes, frameworks, etc., haciendo el mantenimiento cada vez más complicado.

Implementar o migrar a una arquitectura basada en microservicios no es fácil, y mucho menos barato, y no todo son ventajas, sino que presenta una serie de inconvenientes claros y muy poderosos. Por lo tanto, la pregunta importante en este caso sería ¿Cuándo debemos usar microservicios?:

¿Cuándo usar microservicios?

Las arquitecturas basadas en microservicios y las arquitecturas monolíticas son mutuamente excluyentes, de manera que preguntarnos cuando usar microservicios es equivalente a preguntarnos cuando no usar monolitos, y por eso hemos dedicado el comienzo del artículo a detallar las ventajas e inconvenientes de cada una de las soluciones, para que nos pueda ayudar a decidir.

Un monolito suele ser la arquitectura inicial de cualquiera de las aplicaciones que vamos a desarrollar. Iniciar un proyecto con una arquitectura basada en microservicios solo está justificada en los casos en los que las cualidades diferenciales que proveen los microservicios justifican sus inconvenientes.

Según vaya creciendo en complejidad un proyecto, comenzaran a aparecer de manera más notable los inconvenientes asociados a los monolitos, y cada vez será más difícil y más costoso su mantenimiento, empezando a ser justificable la inversión en tiempo y recursos de transformar el monolito en microservicios.

La transformación de un monolito en microservicios es un tema complejo y que se podrá tratar en posteriores artículos. Simplemente comentar que, al transformar nuestro proyecto en microservicios, heredaremos muchos de los inconvenientes de dicha arquitectura, como el aumento de la complejidad, de los tiempos de desarrollo, y de los costes de mantenimiento, etc. Si no podemos aceptar alguno o ninguno de estos inconvenientes asociados, deberíamos plantearnos no romper el monolito, y mejorarlo para que se adapte mejor a nuestras necesidades.

Considerando que empresas con Amazon, Netflix, Facebook, eBay, etc. usan microservicios nos da una idea de cuan escalable y robusta se puede hacer una aplicación basada en dicha arquitectura, pero también nos da una idea de qué tipo de empresas y/o aplicaciones se benefician más de sus ventajas que de sus inconvenientes.

No existe una escala, ecuación o regla que nos indique cuando es más conveniente una arquitectura que otra, pero diremos que siempre que se pueda usaremos monolitos por su mayor facilidad y menores costes asociados, hasta que nos veamos forzados a migrar a soluciones más escalables, como microservicios.

Referencias

•  Microservices vs. monolithic architecture – Chandler Harris – Atlassian Software Development (https://www.atlassian.com/microservices/microservices-architecture/microservices-vs-monolith)
•  Microservices – James Lewis & Martin Fowler – martinfowler.com (https://martinfowler.com/articles/microservices.html)
• You don’t need Microservices – Matthew Spence – Novata (https://itnext.io/you-dont-need-microservices-2ad8508b9e27)
• Microservices vs. Monolithic: Which Architecture Suits Best for Your Project? – Maryna Demchenko – Ncube (https://ncube.com/blog/microservices-vs-monolithic-which-architecture-suits-best-for-your-project)