Close

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

Cuando los monolitos crecen demasiado, puede que sea el momento de pasar a los microservicios

Primer plano de Chandler Harris
Chandler Harris

Escritor y estratega de marketing


Una aplicación monolítica se compila como una sola unidad unificada, mientras que una arquitectura de microservicios es una serie de servicios pequeños que se pueden implementar de forma independiente. ¿Cuál deberías elegir tú? La respuesta depende de varios factores.

En 2009, Netflix tuvo problemas de crecimiento. Su infraestructura no podía seguir el ritmo de la demanda de sus servicios de streaming de video, que crecía a toda velocidad. En esta situación, la empresa decidió migrar su infraestructura de TI de sus centros de datos privados a una nube pública y reemplazar la arquitectura monolítica por otra de microservicios. El único problema era que el término "microservicios" no existía en aquella época, y que la estructura tampoco era muy conocida.

Netflix se convirtió en una de las primeras empresas destacadas en migrar de un monolito a una arquitectura de microservicios basada en la nube. Ganó el premio JAX Special Jury de 2015, en parte debido a esta nueva infraestructura que internalizó DevOps. En la actualidad, Netflix tiene más de un millar de microservicios que administran y respaldan partes independientes de la plataforma, mientras que sus ingenieros implementan código con frecuencia, a veces miles de veces al día.

Netflix fue pionero en lo que, desde entonces, es algo cada vez más habitual: la transición de una arquitectura monolítica a otra de microservicios.

Logotipo de Compass.

Prueba Compass gratis

Mejora tu experiencia de desarrollador, cataloga todos los servicios y mejora el estado del software.

¿Qué es una arquitectura monolítica?


Una arquitectura monolítica es un modelo tradicional de un programa de software que se compila como una unidad unificada y que es autónoma e independiente de otras aplicaciones. La palabra "monolito" suele evocar algo grande y glacial, una imagen que no está alejada de la realidad de las arquitecturas monolíticas para el diseño de software. Una arquitectura monolítica es una red informática grande y única, con una base de código que aúna todos los intereses empresariales. Para hacer cambios en este tipo de aplicación, hay actualizar toda la pila, lo que requiere acceder a la base de código y compilar e implementar una versión actualizada de la interfaz del lado del servicio. Esto hace que las actualizaciones sean restrictivas y lentas.

Los monolitos pueden resultar prácticos al principio de un proyecto para aliviar la sobrecarga cognitiva de la gestión de código, así como la implementación. De esta forma, es posible publicar a la vez todo lo presente en el monolito.

imagen de una arquitectura monolítica
icono de compilación de código
Material relacionado

Cómo crear microservicios

Icono de tres anillos
VER LA SOLUCIÓN

Mejora tu experiencia de desarrollador con Compass

Ventajas de una arquitectura monolítica


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.

Desventajas de una arquitectura monolítica


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.

¿Qué son los microservicios?


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.

imagen de una arquitectura de microservicios

La trayectoria de Atlassian hacia los microservicios


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.

Ventajas de los 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.

Desventajas de los microservicios


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.

imagen de monolito frente a microservicios

Consejos de Atlassian para migrar de una arquitectura monolítica a una de microservicios


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:

Traza una estrategia de migración

Dedicamos muchísimo tiempo a determinar el orden en el que queríamos migrar a los clientes. Sabíamos que muchos de nuestros clientes tendrían diferentes perfiles y dinámicas de uso una vez que los migráramos, por lo que planificamos en consecuencia de antemano.

Herramientas

Contar con las herramientas adecuadas es esencial cuando se hace una migración a microservicios. No migramos clientes de inmediato, sino que primero invertimos y creamos herramientas para la migración, conscientes de que no estábamos corriendo un sprint, sino una carrera de fondo. La herramienta más importante que compilamos fue Microscope, nuestro propio catálogo de servicios interno para rastrear los microservicios. Todos los desarrolladores de Atlassian pueden utilizar Microscope para consultar información de cualquier microservicio de la empresa.

También compilamos herramientas en Microscope llamadas ServiceQuest, que detectan automáticamente las comprobaciones del código antes de la producción: comprobaciones de calidad, diseño del servicio, privacidad, seguridad o fiabilidad.

Además, creamos una herramienta en torno a nuestras pilas tecnológicas. Tenemos un servicio interno que permite poner en marcha un nuevo servicio en una pila en particular y precede a cosas como el registro, la supervisión y el almacenamiento en caché. Por último, automatizamos todo lo que pudimos, incluido el proceso de migración en sí. Creamos nuestro propio panel de control para ver todas las migraciones de manera efectiva y en tiempo real.

Gestiona las expectativas

"La transformación de una empresa requiere un patrocinador ejecutivo sénior que sea responsable de los resultados y esté dispuesto a hacer cumplir los compromisos necesarios", apuntó Sri Viswanath, CTO de Atlassian. Esta persona debe ayudar a la organización a invertir en herramientas, sistemas y procesos nuevos para que las mejoras perduren.

En el caso de las migraciones de grandes infraestructura con muchas personas involucradas, las empresas quieren conocer el retorno de la inversión, señaló Mike Tria, director de plataforma de Atlassian. Es muy importante mantener la comunicación con el equipo ejecutivo, las partes interesadas, los clientes, los socios y el resto de los equipos de I+D. Todos deben saber lo que estás haciendo y las ventajas previstas. Además, es importante celebrar los éxitos, así que no olvides hacerlo.

Cambia la cultura

"La cultura es muy importante en este tipo de proyectos de tanta envergadura", explica Viswanath. "Quieres asegurarte de que cada vez que surja una incidencia se detecte". Hacer una migración no solo es una cuestión técnica, sino un cambio en las personas y la organización. En 2015, en Atlassian se programaba el código y se pasaba la pelota al equipo de operaciones, que se encargaba de ejecutarlo e implementarlo. Sin embargo, a finales de 2017, se adoptó la cultura de DevOps con el concepto "you built it, you run it" (tú lo creas, tú lo gestionas). Con esta nueva filosofía, los desarrolladores de Atlassian ejecutan sus propios servicios.

"Dediqué más tiempo a asegurarme de que el equipo de SRE tuviera éxito en este proyecto que a prácticamente cualquier otra tarea, porque, como resultado de Vértigo, el cambio de cultura era lo que iba a marcar la mayor diferencia a largo plazo para Atlassian", explica Tria.

Busca el equilibrio entre velocidad y confianza

Vértigo podría haberse hecho mucho más rápido. En los primeros cuatro meses habíamos completado el 80 por ciento de las migraciones. Podríamos haber migrado los últimos usuarios a pesar de que no podíamos garantizar que tuvieran la fiabilidad y el rendimiento que queríamos. Pero seguimos uno de los valores fundamentales de Atlassian: "No #!%@$ al cliente".

Con la ayuda del equipo de ingeniería, establecimos un sistema de control y equilibrio para mantener una alta fiabilidad y cumplimos con los altos estándares que nos habíamos marcado. Porque, si compilas bien a la primera, te ahorras tiempo y quebraderos de cabeza a la larga.

Cuando llegamos a los últimos 500 clientes, que eran los más difíciles de migrar, utilizamos la integración de Jira y Trello para asignar un ingeniero de Atlassian a cada uno.

En resumen…


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.

Chandler Harris
Chandler Harris

Chandler Harris es estratega de marketing y redactor de Atlassian. Ha escrito para más de 40 publicaciones diferentes sobre temas que abarcan desde la tecnología hasta la ciencia, los negocios, las finanzas y la educación.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

Comunidad de Compass

ilustración de superar obstáculos

Tutorial: Crear un componente

Ilustración de un mapa

Comienza a usar Compass de forma gratuita

Suscríbete para recibir el boletín de DevOps

Thank you for signing up