Comparación entre la arquitectura monolítica y la arquitectura de microservicios

Las arquitecturas monolíticas y las de microservicios ofrecen diferentes ventajas a las organizaciones en función de diversos factores. Al desarrollar con una arquitectura monolítica, la ventaja principal es la velocidad de desarrollo, gracias a la simplicidad de tener una aplicación basada en una única base de código.

Estas son algunas ventajas de una arquitectura monolítica:

Implementación sencilla: un único archivo o directorio ejecutable facilita la implementación.

Desarrollo: desarrollar una aplicación compilada con una única base de código es más sencillo.

Rendimiento: en una base de código y un repositorio centralizados, una API suele realizar la misma función que muchas API en el caso de los microservicios.

Pruebas simplificadas: una aplicación monolítica es una unidad única y centralizada, por lo que las pruebas integrales se pueden hacer más rápido que con una aplicación distribuida.

Depuración sencilla: con todo el código ubicado en un solo lugar, es más fácil rastrear las solicitudes y localizar incidencias.

Como en el caso de Netflix, las aplicaciones monolíticas pueden ser bastante efectivas, hasta que crecen demasiado y la escalabilidad se convierte en un desafío. Para hacer un pequeño cambio en una sola función, hay que compilar y probar toda la plataforma, lo que va en contra del concepto ágil que prefieren los desarrolladores de hoy en día.

Estas son algunas desventajas de una arquitectura monolítica:

Velocidad de desarrollo más lenta: con una aplicación grande y monolítica, el desarrollo es más complejo y lento.

Escalabilidad: no se pueden escalar componentes individuales.

Fiabilidad: si hay un error en algún módulo, puede afectar a la disponibilidad de toda la aplicación.

Barrera para la adopción de tecnología: cualquier cambio en el marco o el lenguaje afecta a toda la aplicación, lo que hace que los cambios suelan ser costosos y lentos.

Falta de flexibilidad: un monolito está limitado por las tecnologías que se utilizan en él.

Implementación: un pequeño cambio en una aplicación monolítica requiere una nueva implementación de todo el monolito.

Una arquitectura de microservicios, o simplemente "microservicios", es un método de arquitectura que se basa en una serie de servicios que se pueden implementar de forma independiente. Estos servicios tienen su propia lógica empresarial y base de datos con un objetivo específico. La actualización, las pruebas, la implementación y el escalado se llevan a cabo dentro de cada servicio. Los microservicios desacoplan los principales intereses específicos de dominios empresariales en bases de código independientes. Los microservicios no reducen la complejidad, pero hacen que cualquier complejidad sea visible y más gestionable, ya que separan las tareas en procesos más pequeños que funcionan de manera independiente entre sí y contribuyen al conjunto global.

La adopción de microservicios suele ir de la mano de DevOps, ya que son la base de las prácticas de entrega continua con las que los equipos pueden adaptarse rápidamente a los requisitos de los usuarios.

En Atlassian pasamos a la arquitectura de microservicios en 2018, después de los desafíos crecientes que tuvimos que afrontar con Jira y Confluence a la hora de escalar. Determinamos que nuestras arquitecturas monolíticas de inquilino único, que se ejecutaban de forma local, no podrían adaptarse a las necesidades del futuro.

Por eso, decidimos redefinir la arquitectura de Jira y Confluence, y pasarlos de un sistema monolítico con control de estado y un solo inquilino a aplicaciones en la nube con varios inquilinos y sin control de estado alojadas en Amazon Web Services (AWS). A continuación, los fuimos descomponiendo gradualmente en microservicios. El proyecto se denominó Vértigo, en honor a las palabras de un ingeniero sénior: "La idea me encanta, pero me da vértigo". Fue nuestro mayor proyecto de infraestructura hasta la fecha: la transición a AWS tardó dos años en completarse y migramos a más de 100 000 clientes en poco más de 10 meses sin interrupciones del servicio. También nos comprometimos a descomponer los servicios en microservicios.

Los microservicios no son una poción mágica que valga para todo, pero resuelven una serie de problemas para las empresas y el software en crecimiento. Una arquitectura de microservicios consiste en unidades que se ejecutan de forma independiente, por lo que cada servicio se puede desarrollar, actualizar, implementar y escalar sin que afecte a los demás. Las actualizaciones de software se pueden realizar con más frecuencia, de forma más fiable y mejorando el tiempo de actividad y el rendimiento. Pasamos de enviar actualizaciones una vez a la semana a hacerlo dos o tres veces al día.

A medida que Atlassian crece, los microservicios nos permiten escalar equipos y ubicaciones geográficas de manera más fiable, al dividirlos en líneas de propiedad del servicio. Antes de poner en marcha el proyecto Vértigo, en Atlassian teníamos cinco centros de desarrollo diferentes en todo el mundo. Estos equipos distribuidos estaban limitados por un monolito centralizado y necesitaban asistencia de manera autónoma. Y los microservicios nos permiten hacerlo.

Vértigo ofrece ventajas, como una mayor velocidad de implementación, recuperación ante desastres, costes reducidos y mayor rendimiento. Esto nos permite alcanzar nuestro objetivo más rápido y, en el camino, ofrecer más valor incremental a los clientes.

Además, en términos más generales, los microservicios facilitan a los equipos la actualización del código y aceleran los ciclos de publicación con integración continua y entrega continua (CI/CD). Los equipos pueden hacer pruebas con el código y dar marcha atrás si algo no funciona como esperan.

En pocas palabras, estas son las ventajas de los microservicios:

Agilidad: promueve formas ágiles de trabajar con equipos pequeños que implementen con frecuencia.

Escalado flexible: si un microservicio está alcanzando su capacidad de carga, se pueden implementar rápidamente nuevas instancias de ese servicio al clúster que lo acompaña para aliviar la presión. Ahora tenemos varios inquilinos y no tenemos control de estado, con clientes repartidos en varias instancias. Así, podemos respaldar tamaños de instancias mucho mayores.

Implementación continua: tenemos ciclos de lanzamiento frecuentes y más rápidos. Antes enviábamos actualizaciones una vez a la semana y ahora podemos hacerlo dos o tres veces al día.

Muy fácil de mantener y probar: los equipos pueden hacer pruebas con el código y dar marcha atrás si algo no funciona como esperan. Esto facilita la actualización del código y acelera el tiempo de salida al mercado de nuevas funciones. Además, es fácil aislar y corregir fallos y errores en los servicios individuales.

Implementación independiente: los microservicios son unidades individuales, por lo que permiten una implementación independiente rápida y sencilla de funciones individuales.

Flexibilidad tecnológica: con las arquitecturas de microservicios, los equipos pueden elegir con libertad las herramientas que desean.

Alta fiabilidad: puedes implementar cambios para un servicio en concreto sin el riesgo de que se caiga toda la aplicación.

Equipos más satisfechos: los equipos de Atlassian que trabajan con microservicios están mucho más satisfechos, ya que son más autónomos y pueden compilar e implementar de forma independiente, sin esperar semanas a que se apruebe una solicitud de incorporación de cambios.

Cuando pasamos de una pequeña cantidad de bases de código monolíticas a un gran número de sistemas y servicios distribuidos para nuestros productos, surgió una complejidad no deseada. Al principio nos costó añadir nuevas capacidades con la misma velocidad y confianza que hasta entonces. Los microservicios pueden aumentar la complejidad, lo que conduce a un desarrollo descontrolado o a un crecimiento rápido y no administrado. Puede ser difícil determinar cómo se relacionan los diferentes componentes entre sí, quién es el propietario de un componente de software en particular o cómo evitar interferir con los componentes dependientes.

Con Vértigo, creamos una funcionalidad común para impulsar nuestros productos existentes y los productos futuros que adquirimos y creamos. Si se trata de una empresa de un solo producto, es posible que los microservicios no sean necesarios.

Estas son algunas desventajas de los microservicios:

Desarrollo descontrolado: los microservicios suman complejidad en comparación con las arquitecturas monolíticas, ya que hay más servicios en más lugares creados por varios equipos. Si el desarrollo descontrolado no se gestiona adecuadamente, se reduce la velocidad de desarrollo y el rendimiento operativo.

Costes exponenciales de infraestructura: cada nuevo microservicio puede tener su propio coste para el conjunto de pruebas, los manuales de estrategias de desarrollo, la infraestructura de alojamiento, las herramientas de supervisión, etc.

Más sobrecarga organizativa: los equipos deben agregar otro nivel de comunicación y colaboración para coordinar las actualizaciones e interfaces.

Desafíos para la depuración: cada microservicio tiene su propio conjunto de registros, lo que complica la depuración. Además, un solo proceso empresarial puede ejecutarse en varias máquinas, lo que aún lo dificulta más.

Falta de estandarización: sin una plataforma común, puede haber una proliferación de idiomas, de estándares de registro y de supervisión.

La propiedad no está clara: a medida que se introducen más servicios, también lo hace el número de equipos que los ejecutan. Con el tiempo, se hace difícil conocer los servicios disponibles que un equipo puede aprovechar y con quién hay que hablar para obtener asistencia.

En principio, muchos proyectos comienzan como un monolito y, luego, evolucionan hasta convertirse en una arquitectura de microservicios. A medida que se añaden nuevas funciones a un monolito, puede empezar a ser complicado que muchos desarrolladores trabajen en una sola base de código. Los conflictos de código se vuelven más frecuentes y aumenta el riesgo de que las actualizaciones en una función introduzcan errores en una función no relacionada. Cuando aparecen estos patrones no deseados, puede ser el momento de considerar una migración a los microservicios.

Estas son algunas prácticas recomendadas que podemos aconsejar a partir de todo lo aprendido durante nuestra migración:

En enero de 2016, teníamos unos 15 microservicios en total. Ahora son más de 1300. Trasladamos a 100 000 clientes a la nube, creamos una nueva plataforma, transformamos nuestra cultura y terminamos con nuevas herramientas. El resultado es que tenemos equipos autónomos más satisfechos y una mejor cultura de DevOps.

Es posible que los microservicios no sean para todo el mundo. De hecho, una arquitectura monolítica heredada puede funcionar de maravilla y quizá no valga la pena descomponerla. Sin embargo, a medida que las organizaciones crecen y aumentan las demandas de sus aplicaciones, la arquitectura de microservicios puede ser la solución.

Dado que la tendencia en muchas organizaciones son los microservicios con arquitecturas distribuidas, Atlassian ha desarrollado Compass para ayudar a las empresas a gestionar las complejidades de las arquitecturas distribuidas a medida que escalan. Es una plataforma de experiencia extensible para desarrolladores que reúne la información suelta sobre todos los procesos de ingeniería y colaboración en equipo en un lugar centralizado que permite hacer búsquedas.