Arquitectura de software monolítica vs. microservicios

Resumen

Esta semana volé a Gotemburgo para reunirme con gente de una gran naviera internacional y hablar del desarrollo de software empresarial. En la sala había varios expertos, y uno de ellos me preguntó cómo elegir la arquitectura de software adecuada (para apps grandes, complejas y de nivel empresarial). Una pregunta muy buena, que merece un artículo en el blog.

Texto completo

Arquitectura de software

Cuando diseñas apps, no basta con pensar en el aspecto y el tacto: un buen diseño abarca también cómo funciona todo en conjunto. La arquitectura de software son las estructuras fundamentales de un sistema de software. Cada estructura se compone de elementos, de las relaciones entre ellos y de las propiedades de ambos.

Es como la arquitectura de un edificio. Cuando ya has definido e implementado una arquitectura, cambiarla después sale caro. Por eso conviene elegir la arquitectura de software adecuada antes de empezar a construir.

En una app sencilla, la arquitectura puede ser evidente, pero a medida que la aplicación crece en tamaño y funcionalidad, el número de estructuras del sistema puede dispararse. Pasa con el tiempo, según crecen las necesidades de tus clientes. Cuantas más estructuras, más relaciones entre ellas y más complejo se vuelve todo.

Cómo lidiar con un diseño de software complejo

Si esperas que tu software maneje muchas cosas distintas, lo más probable es que tengas que lidiar con la complejidad. Desde el punto de vista de la arquitectura hay varios enfoques para afrontarla.

Arquitectura monolítica

La arquitectura monolítica se describe mejor como “un gran bloque”. Todo lo que hace tu app forma parte del mismo código base.

En una “arquitectura monolítica” el software suele estar organizado en capas, y cada capa consta de distintos tipos de componentes:

• capa de presentación: se encarga de la interfaz de usuario y/o de programación de aplicaciones (UI / API).
• lógica de negocio: aquí se definen las reglas de negocio reales. Es el núcleo de la aplicación, muy pegado a los procesos reales de la empresa.
• capa de acceso a datos: ofrece una interfaz común entre la aplicación en ejecución y los almacenes persistentes del backend.
• base de datos y sistema de archivos: aquí se guardan todos los datos y los recursos estáticos (archivos, imágenes, etc.).

Cuanto más crece la aplicación, más crece cada capa. Eso hace más difícil escalar una arquitectura monolítica: llega un punto en que todo es sencillamente demasiado grande y complejo.

Cada vez que cambias algo en la aplicación, se ve afectado todo el código base. En aplicaciones (muy) grandes eso complica el mantenimiento, porque exige entender la aplicación entera.

Como toda la aplicación es interdependiente, los problemas en una parte suelen afectar mucho a todo el sistema. Además, la comunicación entre las distintas partes es interna, a nivel de código. Eso obliga a programarlas en el mismo lenguaje (o en lenguajes compatibles), y es un obstáculo para adoptar nuevas tecnologías en el futuro, porque no puedes cambiar fácilmente el lenguaje de una parte del sistema.

Arquitectura de microservicios

En lugar de construir una gran aplicación monolítica, puedes dividirla en servicios más pequeños e interconectados. Cada microservicio es una pequeña aplicación por sí misma, con su propia arquitectura (más pequeña y más simple), su lógica de negocio y sus capas de datos.

Los servicios se comunican entre sí mediante API definidas con independencia de la tecnología, a menudo con una “estructura de API” común como REST, JSON, Redis y XML. Así, el conjunto de microservicios funciona como “un solo sistema”.

Al descomponer la aplicación de “gran bloque” en servicios más pequeños, resulta más fácil entender cada parte del sistema. También es más fácil mantenerlo, porque cada microservicio se puede desarrollar por separado. Y cuesta menos adoptar tecnologías nuevas, porque puedes elegir la que mejor encaje con cada servicio. Una parte del sistema puede programarse en un lenguaje distinto al de las demás, y eso permite que trabajen juntos equipos distintos (con conocimientos distintos).

El arte, y la habilidad, de acertar con la arquitectura de microservicios está en saber definir bien cada microservicio. Si es demasiado amplio o demasiado granular, puede arruinar la arquitectura. Para definirlos puedes basarte en procesos de negocio o en una separación jerárquica o por dominios.

El reto de los microservicios es que añaden complejidad a todo el sistema, porque hace falta un mecanismo de comunicación distribuido. Las distintas API que se conectan entre sí pueden ser difíciles de probar y depurar, y resulta más complicado implementar cambios que afectan a varios servicios.

Definir, diseñar e implementar las API entre servicios exige ponerse de acuerdo sobre los datos que se intercambian, y eso puede ser difícil si quieres compartir estructuras de datos extensas y no universales.

Supervisar y desplegar una arquitectura de microservicios puede ser complejo cuando los servicios se multiplican. Simplemente hay más que gestionar, y cada servicio requiere más planificación y coordinación.

Elegir la arquitectura adecuada

Mi difunto padre me dijo una vez que “lo que más se gana es con las cosas que no se hacen”. Construir aplicaciones complejas es difícil por naturaleza, y lo mejor que puedes hacer es simplificar: no hacerlo todo. Céntrate en lo que de verdad importa y hazlo bien.

Si tu aplicación es simple y ligera, la arquitectura monolítica es el camino. Desarrollar, desplegar, mantener: todo es más fácil cuando las cosas son pequeñas.

Si no puedes escapar de la complejidad, entonces sí deberías plantearte los microservicios. Hazte estas preguntas:

• ¿Puedes definir un “lenguaje común” entre tus microservicios?
• ¿Hay procesos de negocio claramente distintos?
• ¿Hasta qué punto dependen unos de otros esos procesos?
• ¿Cómo esperas que evolucione tu aplicación con el tiempo? ¿Crecerá o se reducirá?
• ¿Cuántas tecnologías de programación distintas piensas usar? ¿Esperas que cambie en el futuro?
• ¿Quién va a construir y mantener el software? ¿Tiene experiencia con una arquitectura así?

Conclusión

No existe una respuesta “mágica” a la pregunta de qué arquitectura de software es la correcta. Los dos enfoques tienen sus pros y sus contras.

¡Lo mejor que puedes hacer es tomar una decisión consciente, bien meditada, y apostar fuerte por ella!