Arquitectura monolítica vs. microservicios: ¿cuál es la mejor opción para usted?

El enfoque monolítico es el modelo de software tradicional. Los microservicios reflejan el desarrollo posterior de software, pero eso no ha hecho que la arquitectura monolítica quede obsoleta.

Supongamos que ha empezado a trabajar para una startup tecnológica y se le ha encomendado la tarea de implementar un plan de TI para la nueva empresa. Se enfrenta a una serie de decisiones, pero ninguna tan básica o trascendental como decidir entre una arquitectura monolítica o una arquitectura de microservicios. La elección de la arquitectura de software no debe realizarse de forma aislada o sin comprender claramente las necesidades iniciales y futuras de procesamiento de datos de su organización, ya que cualquier método arquitectónico que se elija tendrá efectos profundos en la capacidad de la organización para ejecutar de manera significativa sus objetivos comerciales.

Así pues, lo que está en juego es considerable. Y como usted es el recién nombrado director de TI, también es una decisión de peso para usted personalmente, que podría llevarle a un camino dorado de incalculable avance profesional, si elige sabiamente.

¿Cuál elige? Primero, conozcamos sus opciones.

Como se ha dicho, la arquitectura monolítica es el modelo tradicional de desarrollo de software. En él, una base de código desempeña varias funciones (es decir, funciones empresariales). El núcleo del ordenador controla todas las funciones. En las aplicaciones monolíticas, todo el código necesario para toda la aplicación se mantiene en una ubicación central.

Las aplicaciones monolíticas suelen contener los siguientes componentes:

• Interfaz de usuario (IU) del lado del cliente: el "lado del cliente" se refiere a lo que se muestra en el dispositivo informático del usuario. La IU gestiona lo que ve el usuario, incluidas las imágenes, el texto y cualquier otra cosa que se pueda transmitir a través de la pantalla de la IU, como la información relacionada con las acciones del navegador.

• Base de datos: las arquitecturas monolíticas utilizan un sistema de gestión de bases de datos relacionales (RDMS), un tipo de base de datos que organiza los datos en filas y columnas. Estas filas y columnas forman una tabla en la que los puntos de datos están relacionados entre sí.

• Aplicación del lado del servidor: una aplicación del lado del servidor se ocupa de los recursos del servidor, como la memoria, la CPU y el almacenamiento.

El uso de la arquitectura monolítica produce numerosos beneficios:

• Desarrollo de aplicaciones sin complicaciones: las aplicaciones construidas con una única base de código son más sencillas de construir y su desarrollo es más rápido.

• Implementación básica: la arquitectura monolítica funciona con un único archivo o directorio ejecutable, lo que facilita la implementación. Una arquitectura monolítica también es más fácil de mantener porque utiliza menos componentes.

• Depuración sencilla: las operaciones de prueba y depuración son menos complicadas con las arquitecturas monolíticas. Las operaciones de prueba de extremo a extremo se llevan a cabo desde un sistema de información de registro central.

• Mayor seguridad: porque una arquitectura monolítica es un sistema cerrado, sus actividades de proceso de datos están totalmente contenidas y protegidas contra las ciberamenazas.

El uso de la arquitectura monolítica también presenta posibles problemas:

• Resistente a las nuevas tecnologías: dado que las aplicaciones monolíticas suelen estar estrechamente acopladas, puede resultar difícil integrar nuevas tecnologías en ellas.

• Escalabilidad reducida: incluso si la cantidad de escalado necesaria es relativamente menor (como ajustar una sola función), es posible que tenga que desmantelar y reconstruir el sistema de manera efectiva para reflejar el nuevo cambio. Eso puede requerir mucho tiempo y trabajo.

El otro modelo de desarrollo de software, los microservicios, es un estilo arquitectónico nativo de la nube. Con los microservicios, una aplicación se basa en múltiples componentes o servicios individuales, débilmente acoplados. Las aplicaciones de microservicio tienen su propia pila tecnológica, que es un conjunto de tecnologías que funcionan juntas para realizar un trabajo determinado.

La principal ventaja de los microservicios es que el sistema se puede actualizar fácilmente para dirigirse a las nuevas capacidades empresariales dentro de la aplicación sin afectar a todo el sistema. Esto puede traducirse en un ahorro considerable tanto de tiempo como de mano de obra.

Las ventajas de los microservicios son múltiples. Se adaptan tanto al crecimiento constante del negocio como a los nuevos cambios tecnológicos:

• Aumento de escalabilidad: los microservicios destacan en la escalabilidad en comparación con las arquitecturas monolíticas. Los servicios individuales dentro de una arquitectura de microservicios se dividen en módulos, y una única instrucción para escalar hacia arriba puede transmitirse a varios servicios simultáneamente. Además, los microservicios son muy adecuados para gestionar aplicaciones grandes y complejas.

• Listo para la automatización: los microservicios en uso permiten a las organizaciones automatizar el proceso de integración continua/entrega constante (CI/CD). Esto permite el desarrollo de actualizaciones de código que se producen de acuerdo con un cronograma continuo.

• Funcionamiento independiente: la arquitectura de microservicios divide cada servicio en una célula de operaciones. Con este tipo de operación independiente, no hay peligro de que el flujo de trabajo de una aplicación de microservicio se entrometa en los flujos de trabajo de otras aplicaciones de microservicio.

Los microservicios ofrecen beneficios definidos, pero su complejidad crea ciertos problemas:

• Obstáculos de prueba: con los microservicios, las operaciones de depuración no se inician hasta que se han probado las distintas partes de una aplicación. Esto incluye la comprobación de dependencias, el almacenamiento en caché de actividades y el acceso a datos.

• Exposición potencial a la seguridad: el intercambio de datos que tiene lugar entre varios procesos dentro de un sistema de microservicios utiliza una pasarela de interfaz de programación de aplicaciones (API). Una pasarela API puede crear vulnerabilidades de seguridad en la autenticación y otras actividades críticas.

• Aumento de la latencia: los microservicios escalan aplicaciones de manera impresionante, pero esto puede crear problemas con retrasos adicionales y latencia. Cada vez que el sistema se amplía, aumenta la complejidad y la cantidad de datos que se transfieren, y esto puede ralentizar el procesamiento.

Antes de nuestra comparación directa de la arquitectura monolítica y la arquitectura de microservicios, debemos desarrollar la historia con algunos detalles históricos para proporcionar un contexto más amplio.

En cierto modo, es difícil rastrear el origen de la arquitectura monolítica hasta una sola fecha; cuanto más complicada sea la tecnología, más difícil puede ser determinar la entrega exacta de esa tecnología. Y lo mismo ocurre con las arquitecturas monolíticas, que comenzaron a desarrollarse a mediados del siglo XX.

International Business Machines (IBM) fue un actor importante en ese desarrollo crítico inicial. Según el colaborador de DZone, Pier-Jean Malandrino, "... empresas como IBM desempeñaron un papel decisivo en la definición de la arquitectura de software temprana mediante el desarrollo de los ordenadores mainframe en las décadas de 1960 y 1970"¹.

Las arquitecturas monolíticas no eran perfectas: a menudo estaban escritas en lenguajes ultrabásicos y estaban destinadas a que las leyera una sola máquina. Como solo una máquina contenía todo el sistema, todos los componentes del ordenador estaban perfectamente acoplados. El escalado era inexistente o apenas posible, y generalmente requería la reconstrucción completa de un sistema.

Alternativamente, si la arquitectura monolítica parece primitiva en retrospectiva, es en parte porque estaba allí primero, antes que cualquier otro sistema de arquitectura de software. Y ha demostrado ser siempre útil, incluso resiliente, a lo largo del tiempo. El hecho de que las arquitecturas monolíticas se sigan utilizando siete décadas después de su introducción dice mucho en un sector en el que lo único que suele permanecer son los cambios incesantes.

La arquitectura monolítica ha perdurado, pero ya no es el único juego en la ciudad, y no lo ha sido durante algún tiempo. A medida que avanzaba la década de 1980, la ingeniería de software experimentó un impulso hacia la modularidad y el uso de lenguajes de programación orientados a objetos. Para la década de 1990, se habían preparado las condiciones para que los sistemas distribuidos pudieran beneficiarse de los recientes avances de la computación en red.

Esto condujo finalmente al desarrollo de los microservicios, que empezaron a utilizarse ampliamente tras el inicio de la cloud computing y las tecnologías de contenerización en la década de 2000. La arquitectura de microservicios se creó para mejorar el modelo monolítico, preparándolo para sistemas descentralizados y de escalado rápido.

Ahora, en la década de 2020, el desarrollo de software pasa de la arquitectura monolítica o de la arquitectura de microservicios. Basándonos en lo que esperamos del cambio tecnológico, nuestro pensamiento inicial podría ser asumir que la tecnología que ha llegado más recientemente es superior y, en algunas circunstancias, ese es definitivamente el caso.

Sin embargo, hacer ese tipo de afirmación general es peligroso, en gran medida porque sencillamente no es cierto. Todavía hay numerosas situaciones informáticas que obtienen beneficio de la sencillez del modelo de arquitectura monolítica.

Ambas arquitecturas de software tienen sus ventajas e inconvenientes, y las empresas deben evaluar cuidadosamente ambos tipos y considerar sus necesidades previstas de desarrollo de aplicaciones antes de adoptar un sistema u otro.

¿Cómo se comparan la arquitectura monolítica y la arquitectura de microservicios cuando se ven a través del prisma de las etapas operativas clave?

• Creación: las diferencias clave entre los dos formatos arquitectónicos comienzan temprano, con la concepción del sistema deseado. Los sistemas monolíticos son más sencillos de construir porque utilizan un diseño más básico. Los microservicios son considerablemente más complejos y requieren más planificación para ejecutarlos.

• Estructura: una arquitectura monolítica se diseña y construye como una sola unidad. La arquitectura de microservicios defiende la idea de la modularidad mediante el uso de una colección de microservicios más pequeños e implementables que permiten la operación de servicios independientes.

• Complejidad: cuanto más complicado es un sistema, más se adapta a una arquitectura de microservicios. Los microservicios modulares dan la bienvenida a las nuevas características y tecnologías que tienden a acompañar a la complejidad añadida.

• Crecimiento: tanto la arquitectura monolítica como la de microservicios pueden ser eficaces durante su uso inicial. Pero el crecimiento lo cambia todo, sobre todo cuando las organizaciones se dan cuenta de que pronto van a expandirse más allá de su sistema inicial. En ese momento, las empresas necesitan una fase de operaciones más grande, y los microservicios lo proporcionan al ofrecer más formas de escalar las operaciones de las que puede hacer la arquitectura monolítica.

• Tiempo de comercialización: esta métrica clave desempeña un papel fundamental en el comercio al medir el tiempo que se tarda en fabricar los productos y en introducirlos en los canales de distribución. El tiempo de comercialización es un área en la que la arquitectura monolítica sobresale más allá de los microservicios. Al utilizar una única base de código, los desarrolladores pueden evitar el tiempo y el trabajo extra que supone incorporar software de varias fuentes.

• Escalabilidad: la arquitectura de microservicios se basa en servicios individuales que pueden compartimentarse en formas modulares y obtener un beneficio de la intercomunicación lograda mediante el uso de API. Por otro lado, la arquitectura monolítica muestra una menor adaptabilidad general debido a que tiene una estructura central densamente compuesta y un software estrechamente acoplado.

• Depuración: la depuración es el proceso de utilizar el software para detectar y localizar problemas de codificación y, a continuación, solucionarlos. La arquitectura monolítica gestiona la depuración mejor que los microservicios porque es más sencilla y directa. La depuración de una arquitectura de microservicios es considerablemente más lenta, más complicada y laboriosa.

Existe un suministro casi ilimitado de casos de uso que se pueden lograr utilizando una arquitectura monolítica o una arquitectura de microservicios. Estos son algunos de los más frecuentes:

• Startups: las empresas que acaban de empezar necesitan dos cosas: flexibilidad y financiación inicial (y muchas de ambas). Una arquitectura monolítica es la mejor manera de iniciar negocios incipientes. Además, lo pueden crear equipos de desarrollo ajustados de una manera rentable que no imponga una curva de aprendizaje demasiado pronunciada a los equipos pequeños.

• Proyectos básicos: contar con un único código base ofrece grandes ventajas en términos de comodidad, especialmente en proyectos de alcance rudimentario. Cuando el software puede pasar por el proceso de desarrollo sin necesidad de incorporar datos de múltiples fuentes, es una victoria para la organización.

• Plataformas de entretenimiento: dirigir una plataforma de entretenimiento internacional requiere la capacidad de aprovechar la marea cambiante de las cargas de trabajo, ya sea que esa demanda se convierta en cargas de trabajo ligeras o pesadas. En el caso de Netflix, el gigante del streaming de vídeo pasó de una arquitectura monolítica a una arquitectura de microservicios basada en la nube. El nuevo backend de Netflix contiene una gran cantidad de compatibilidad con equilibradores de carga, lo que ayuda en sus esfuerzos por optimizar las cargas de trabajo.

• Comercio electrónico: el comercio electrónico depende de la arquitectura de microservicios para hacer que la magia del mercado cobre vida con una experiencia perfecta. Con minoristas ambiciosos como Amazon (AWS) impulsando las ventas con mayor comodidad y entrega más rápida, es fácil ver por qué el mercado de ventas de comercio electrónico en 2023 superó los 5,8 billones de dólares².

• Trabajos más difíciles: el uso continuo de los microservicios normalmente requiere las habilidades de implementación y administración de equipos de DevOps capacitados que puedan dedicarse a crear los servicios específicos necesarios para ese marco. Estas habilidades son especialmente útiles a la hora de enfrentarse a aplicaciones complejas.

Cualquier implementación a gran escala de arquitectura monolítica o arquitectura de microservicios será inevitablemente errónea si su diseño se completa en un vacío efectivo, sin considerar primero la parte más importante de la ecuación: las necesidades particulares de su startup tecnológica.

Como director de TI, esta es la actividad crítica cuando se planifican las decisiones de infraestructura de software. Saber cuándo usar un estilo arquitectónico es esencial, al igual que comprender el sistema más adecuado en función de sus usos necesarios.

El ejercicio de autoanálisis es muy valioso porque su trabajo no solo consiste en seleccionar el sistema arquitectónico óptimo para su organización, sino también en estimar con precisión el sistema arquitectónico que su empresa necesitará en los próximos meses y años. En cierto modo, se le encomienda la tarea de predecir el futuro.

Así que, aunque una arquitectura monolítica puede parecer perfectamente ideal para su empresa emergente, depende de usted proyectar el crecimiento futuro. Y si se espera una expansión desenfrenada, podría resultar más prudente seguir adelante e invertir en una arquitectura de microservicios. Hay numerosas variables a tener en cuenta:

• La lógica empresarial en uso: al igual que la lógica informática dicta lo que es y no es posible con un ordenador, la lógica empresarial se basa en reglas empresariales que rigen cómo puede y no puede funcionar una empresa. Técnicamente, se traduce en los algoritmos que definen cómo se transmite la información entre una base de datos y una interfaz de usuario.

• Desarrollo front-end: ya desde la fase de planificación de la interfaz de usuario de la arquitectura de su software, debe definir qué método arquitectónico va a seguir, ya que cada uno tiene una estructura única. En una arquitectura monolítica, la aplicación frontal se manifiesta como una gran base de código que alberga todo el código de la aplicación. En una aplicación front-end de microservicios, se pueden poner en funcionamiento múltiples microservicios que operan de forma independiente.

• Tolerancia a fallos: otra consideración que debe tenerse en cuenta es cuánta tolerancia a fallos se espera que sea necesaria. La tolerancia a errores es un tema muy difícil, porque puede hacer caer toda una aplicación si solo falla un componente de ese sistema. Una arquitectura monolítica carece de aislamiento entre componentes, y eso puede agravar la falta de tolerancia a fallos y provocar periodos prolongados de tiempo de inactividad.

• Tasa de cambio prevista: la elección entre una arquitectura monolítica y una arquitectura de microservicios no es una mera cuestión de arquitectura de software. Es realmente una selección entre dos mentalidades empresariales, una que simplemente quiere entrar en funcionamiento y otra que insiste en lograr un crecimiento empresarial sustancial. El crecimiento puede ser complicado, pero está bien respaldado por atributos de la arquitectura de microservicios, como ciclos de desarrollo más rápidos y una mayor escalabilidad.