Microservicios vs. arquitectura monolítica

La evolución de la tecnología ha cambiado la forma de diseñar la arquitectura de las aplicaciones. Docker, los servicios en la nube y los servicios de orquestación de contenedores nos permiten desarrollar soluciones distribuidas, más escalables y fiables. En este artículo comparamos la arquitectura de microservicios con la monolítica, vemos qué equipos y proyectos deberían optar por cada una y analizamos sus ventajas e inconvenientes.

A simple vista, la diferencia entre ambas se puede ilustrar así

No es del todo cierto que las aplicaciones monolíticas sean siempre sencillas, pero los microservicios suelen ser diez veces más grandes y casi siempre requieren más recursos.

Veamos punto por punto los pros y los contras de cada una.

Despliegue

Con una aplicación monolítica configuras el despliegue una vez y después solo tienes que ir ajustándolo según los cambios. Eso sí, también hay un único punto de fallo durante el despliegue y, si todo sale mal, puedes romper el proyecto entero.

Los microservicios exigen mucho más trabajo: tienes que desplegar cada microservicio por separado, ocuparte de las herramientas de orquestación e intentar unificar el formato de tus pipelines de CI/CD para reducir el tiempo que cuesta configurarlo en cada nuevo microservicio. Pero también tiene su lado bueno: si algo falla, solo rompes un pequeño microservicio, lo que es mucho menos grave que tumbar todo el proyecto. Además, es mucho más fácil hacer rollback de un microservicio pequeño que de una aplicación monolítica entera.

Mantenimiento

Si vas a usar una arquitectura de microservicios, incorpora un perfil DevOps al equipo y prepárate. No todos los desarrolladores conocen Docker ni herramientas de orquestación como Kubernetes, Docker Swarm, Mesosphere o cualquier otra que te ayude a gestionar una infraestructura con tantas piezas en movimiento. Alguien tiene que monitorizar y mantener en buen estado la configuración de CI de cada microservicio y de toda la infraestructura.

Fiabilidad

Aquí la arquitectura de microservicios gana de calle. Si falla un microservicio, solo se ve afectada una parte y solo tienen problemas los clientes que la usan, nadie más. Por ejemplo, si estás desarrollando una app bancaria y cae el microservicio encargado de las retiradas de dinero, es claramente menos grave que tener que parar toda la aplicación.

Escalabilidad

En escalabilidad, los microservicios vuelven a ser la mejor opción. Las aplicaciones monolíticas son difíciles de escalar porque, aunque pongas más workers, cada uno ejecuta el proyecto completo, lo que supone un uso ineficiente de los recursos. Peor aún: puede que el código esté escrito de forma que sea imposible escalarlo horizontalmente, y solo te quede el escalado vertical. Con microservicios es mucho más fácil: puedes afinar el uso de recursos y escalar solo las partes que realmente los necesitan.

Coste

El coste es difícil de calcular, porque la arquitectura monolítica sale más barata en unos casos y en otros no. Por ejemplo, gracias a la mejor escalabilidad de los microservicios, puedes configurar el autoescalado y pagar más solo cuando el volumen de usuarios de verdad lo exige. Pero, al mismo tiempo, para mantener esa infraestructura en marcha necesitas un perfil DevOps, y hay que pagarlo. Una aplicación monolítica pequeña puede funcionar en un hosting de 5-20 $ con los snapshots activados. Con una aplicación monolítica grande, en cambio, quizá tengas que contratar una instancia muy cara, porque no puedes repartirla entre varios servidores pequeños y baratos.

Desarrollo

En un proyecto con 16 microservicios, la experiencia demuestra que puede ser complicado de gestionar. La mejor manera de trabajar con microservicios es crear tu archivo docker-compose desde el principio y desarrollar con Docker. Así reduces el tiempo de incorporación de gente nueva: basta con levantar el sistema desde cero y arrancar los microservicios que hagan falta. Abrir más de 10 ventanas de terminal y ejecutar comandos para arrancar cada servicio por separado es un suplicio.

Por otro lado, cuando desarrollas un microservicio, puede que no necesites ejecutar el resto de la aplicación en absoluto. Y hay menos conflictos de git, porque las tareas se reparten mejor y los desarrolladores pueden trabajar aislados en microservicios distintos.

La revisión de código y el QA son más sencillos con microservicios; incluso puedes escribir cada microservicio en un lenguaje diferente.

Lanzamientos

Unos microservicios más pequeños, con una buena arquitectura de comunicación entre ellos, te permiten lanzar nuevas funcionalidades más rápido al reducir el tiempo de QA, de build y de ejecución de tests. Las aplicaciones monolíticas tienen muchas dependencias internas imposibles de separar. También hay más riesgo de que lo que subes dependa de cambios sin terminar de tus compañeros, lo que puede retrasar los lanzamientos.

¿Qué arquitectura te conviene?

Usa una arquitectura monolítica si:

• tienes un equipo pequeño.
• estás construyendo el MVP de un producto nuevo.
• no has conseguido millones de inversión para contratar perfiles DevOps ni dedicar tiempo extra a una arquitectura compleja.
• tienes experiencia desarrollando con frameworks sólidos, como Ruby on Rails, Laravel, etc.
• no ves cuellos de botella de rendimiento en funcionalidades clave.
• los microservicios te atraen solo porque están de moda.

Ten en cuenta que, si más adelante ves que tu proyecto necesita microservicios, siempre puedes ir dividiendo la arquitectura monolítica en microservicios más pequeños.

Usa una arquitectura de microservicios si:

• no tienes un plazo ajustado; los microservicios exigen investigar y planificar la arquitectura para que todo funcione.
• tu equipo domina distintos lenguajes.
• te preocupan mucho la escalabilidad y la fiabilidad de tu producto.
• es posible que tengas varios departamentos de desarrollo (quizá incluso en distintos países o husos horarios).
• ya tienes una aplicación monolítica y ves problemas en partes que podrían dividirse en varios microservicios.