Diferencias entre las arquitecturas de microservicios y las arquitecturas monolíticas

Las arquitecturas de microservicios son una tendencia relevante en materia de software que puede repercutir considerablemente no solo en los equipos de TI de las empresas, sino también en la transformación digital de toda la organización.Pero ¿en qué se diferencia una arquitectura de microservicios de una arquitectura monolítica? Y, lo que es más importante, ahora que los gigantes tecnológicos como Netflix, Google y Amazon se están decantando por las arquitecturas de microservicios, ¿cuáles son las ventajas de estas arquitecturas?

Antes de nada, comparemos las arquitecturas de microservicios con las arquitecturas monolíticas. Una aplicación monolítica se crea como una sola unidad. Las aplicaciones empresariales constan de tres partes:

• Una base de datos compuesta por muchas tablas, normalmente en un sistema de gestión de bases de datos relacionales
• Una interfaz de usuario en el lado del cliente compuesta por páginas HTML y/o JavaScript que se ejecuta en un navegador
• Una aplicación en el lado del servidor que gestionará las solicitudes HTTP, ejecutará la lógica específica del dominio, recuperará y actualizará los datos de la base de datos y generará las vistas HTML que se enviarán al navegador.

Y esto es lo que constituye el monolito de las aplicaciones monolíticas: se trata de un único ejecutable lógico. Para realizar cambios en el sistema, los desarrolladores deben crear y desplegar una versión actualizada de la aplicación en el lado del servidor.

A diferencia de una arquitectura monolítica, las funcionalidades de los microservicios se expresan formalmente con API orientadas al negocio. Cada microservicio encapsula una funcionalidad empresarial principal y la implementación del servicio —que puede conllevar integraciones con sistemas de registro— queda totalmente oculta, ya que la interfaz se define puramente en términos empresariales.

El hecho de que los servicios se estén convirtiendo en activos valiosos para la empresa anima de forma implícita a adaptarlos para su uso en múltiples contextos. Un mismo servicio se puede reutilizar en más de un proceso empresarial o en diferentes canales empresariales o puntos de contacto digitales.

La dependencia entre los servicios y sus consumidores se minimiza al aplicar el principio de conexión indirecta. Al estandarizar los contratos que se expresan mediante API orientadas al negocio, los consumidores no se ven afectados por los cambios en la implementación del servicio. De esta forma, los propietarios de los servicios pueden cambiar la implementación y modificar los sistemas de registro o las composiciones de servicios, que pueden no ser visibles en la interfaz, y sustituirlos sin que haya repercusiones en el flujo general.

Los procesos de desarrollo de software tradicionales (en cascada, ágiles, etc.) suelen requerir que grandes equipos trabajen en un único despliegue monolítico. Los responsables de proyecto, los desarrolladores y el personal operativo pueden alcanzar diversos grados de éxito con estos modelos, creando prototipos de aplicaciones que la empresa puede verificar, especialmente a medida que se familiarizan con una pila de software y una pila de despliegue determinadas. Sin embargo, estos enfoques tradicionales tienen una serie de problemas subyacentes:

• Las aplicaciones monolíticas pueden volverse tan complejas que no haya un solo desarrollador o grupo de desarrolladores que comprenda toda la aplicación
• Es difícil reutilizar las aplicaciones monolíticas
• Escalar las aplicaciones monolíticas supone todo un reto
• Es complicado ofrecer agilidad operativa en repetidos despliegues de artefactos de aplicaciones monolíticas.
• Por definición, las aplicaciones monolíticas se implementan mediante una sola pila de desarrollo (como JEE o .NET), por lo que puede que no siempre haya una "herramienta idónea para el trabajo".

Una arquitectura de microservicios, combinada con tecnologías de despliegue en la nube, gestión de APIs e integración, permite enfocar el desarrollo de software de una manera distinta. El monolito se divide en una serie de servicios independientes que se desarrollan, despliegan y mantienen por separado. Y esto tiene las siguientes ventajas:

• Se fomenta que los servicios sean pequeños e, idealmente, resultado del trabajo de unos pocos desarrolladores.
• Otros servicios y aplicaciones pueden consumir y reutilizar los microservicios sin necesidad de una conexión directa mediante enlaces de lenguajes o bibliotecas compartidas.
• Los servicios existen como artefactos de despliegue autónomos y se pueden escalar independientemente de otros servicios.
• Como los servicios se desarrollan por separado, los desarrolladores pueden utilizar el marco de desarrollo idóneo para cada tarea.

La concesión que se debe hacer a cambio de esta flexibilidad es la complejidad. Gestionar un número elevado de servicios a escala es complicado por dos motivos:

1. Los equipos de proyecto tienen que poder identificar fácilmente los servicios que podrían reutilizar en un futuro. Estos servicios deben contar con recursos, como documentación y consolas para pruebas, que permitan que sea mucho más sencillo reutilizarlos que crearlos desde cero.
2. Es necesario conocer al detalle las interdependencias entre servicios. El tiempo de indisponibilidad, las interrupciones y las actualizaciones de los servicios, entre otras situaciones, pueden causar un efecto dominó en el flujo general, por lo que se debe analizar rigurosamente su impacto.

Es importante asegurarse de que la entrega de microservicios se gestiona cuidadosamente y el ciclo de vida de gestión de sistemas está todo lo automatizado posible. Y es que la falta de automatización y coordinación al estilo DevOps en los equipos puede hacer que las iniciativas de microservicios acaben siendo contraproducentes.