Arquitectura monolítica frente a microservicios: ¿cuál funciona mejor para usted?

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

Supongamos que comenzó a trabajar para una empresa emergente de tecnología y se le asignó la tarea de implementar un plan de TI para la nueva empresa. Se enfrenta a una letanía de decisiones, pero ninguna tan básica o de tan largo alcance como decidirse por una arquitectura monolítica o una arquitectura de microservicios. La elección de la arquitectura de software no debe hacerse en el vacío o sin una comprensión clara de las necesidades iniciales y eventuales de procesamiento de datos de su organización, ya que cualquier enfoque arquitectónico que se elija tendrá efectos profundos en la capacidad de la organización para ejecutar de manera significativa sus objetivos comerciales.

Por lo tanto, lo que está en juego aquí es considerable. Y debido a que usted es el nuevo director de TI, también es una decisión importante para usted personalmente, una que podría llevarlo a un camino dorado de avance profesional incalculable, si elige sabiamente.

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

Como se indicó, la arquitectura monolítica es el modelo tradicional de desarrollo de software. En él, una base de código lleva a cabo múltiples funciones (es decir, funciones comerciales). El kernel de la computadora 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: “lado del cliente” se refiere a lo que se muestra en el dispositivo informático del usuario. La interfaz de usuario (IU) gestiona lo que ve el usuario, incluidas imágenes, texto y cualquier otra cosa que pueda transmitirse a través de la pantalla de la interfaz de usuario (IU), como 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 donde los puntos de datos están relacionados entre sí.

• Aplicación del lado del servidor: una aplicación del lado del servidor gestiona 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 crear con un desarrollo más rápido.

• Despliegue básico: la arquitectura monolítica funciona con un archivo o directorio ejecutable, lo que hace que el despliegue sea menos difícil. Una arquitectura monolítica también es más fácil de mantener en virtud del uso de menos componentes.

• Depuración simple: las operaciones de prueba y depuración están menos involucradas con arquitecturas monolíticas. Las operaciones de prueba de extremo a extremo se realizan desde un sistema de registro central.

• Mayor seguridad: debido a que una arquitectura monolítica es un sistema cerrado, sus actividades de procesamiento 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: debido a que las aplicaciones monolíticas suelen estar estrechamente acopladas, puede ser difícil integrar nuevas tecnologías en ellas.

• Escalabilidad reducida: incluso si la cantidad de escalamiento necesaria es relativamente menor (como ajustar una sola función), es posible que deba desmantelar y reconstruir el sistema de manera efectiva para reflejar el nuevo cambio. Eso puede resultar lento y laborioso.

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 microservicios tienen su propia pila tecnológica, que es una colección de tecnologías que trabajan juntas para realizar un trabajo en particular.

La principal ventaja de los microservicios es que el sistema se puede actualizar fácilmente para abordar nuevas capacidades dentro de la aplicación sin afectar a todo el sistema. Esto puede traducirse en grandes ahorros de tiempo y mano de obra.

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

• Mayor escalabilidad: los microservicios se destacan en 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 sola instrucción para escalar se puede transmitir a varios servicios simultáneamente. Además, los microservicios son muy adecuados para manejar 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.

• Operación independiente: la arquitectura de microservicios divide cada servicio en una celda operativa. Con este tipo de operación independiente, no hay peligro de que el flujo de trabajo de una aplicación de microservicios se entrometa en los flujos de trabajo de otras aplicaciones de microservicios.

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

• Obstáculos en las pruebas: con los microservicios, las operaciones de depuración no comienzan hasta que se probaron las distintas partes de una aplicación. Esto incluye verificar dependencias, actividades de almacenamiento en caché y 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 puerta de enlace de interfaz de programación de aplicaciones (API). Una API gateway puede crear vulnerabilidades de seguridad en la autenticación y otras actividades críticas.

• Aumento de la latencia: los microservicios amplían las aplicaciones de manera impresionante, pero esto puede crear problemas con retraso y latencia adicionales. 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 identificar 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 inicial crítico. Según el colaborador de DZone Pier-Jean Malandrino, “... empresas como IBM fueron fundamentales para definir la arquitectura temprana de software a través de su desarrollo de computadoras 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 ser leídas por una sola máquina. Debido a que solo una máquina contenía todo el sistema, todos los componentes de la computadora estaban estrechamente acoplados. El escalamiento 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 estuvo allí primero, antes que cualquier otro sistema de arquitectura de software. Y ha demostrado ser consistentemente ú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 una industria en la que lo único que suele permanecer es el cambio incesante.

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. En la década de 1990, se había preparado el escenario para los sistemas distribuidos que podrían usar los avances recientes en la computación en red.

Esto finalmente condujo al desarrollo de microservicios, que se generalizaron después del inicio de la computación en la nube 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 orientándolo para un escalado rápido y sistemas descentralizados.

Ahora, en la década de 2020, el desarrollo de software deriva tanto de la arquitectura monolítica como de la arquitectura de microservicios. Con base en lo que esperamos del cambio tecnológico, nuestro pensamiento inicial podría ser asumir que la tecnología que llegó más recientemente es superior y, en algunas circunstancias, ese es definitivamente el caso.

Sin embargo, hacer ese tipo de declaración general es peligroso, en gran parte porque simplemente no es cierto. Todavía hay numerosas situaciones informáticas que obtienen beneficio de la simplicidad 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 proyectadas 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 ejecutarse.

• 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 aplicaciones más pequeñas y desplegables que permiten las operaciones de servicios independientes.

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

• Crecimiento: la arquitectura monolítica y la arquitectura de microservicios pueden ser eficaces durante su uso inicial. Pero el crecimiento lo cambia todo, especialmente cuando las organizaciones se dan cuenta de que pronto se expandirán más allá de su sistema inicial. En ese momento, las empresas necesitan una etapa más grande de operaciones, y los microservicios lo proporcionan al presentar más formas de escalar las operaciones que la arquitectura monolítica.

• Tiempo de comercialización: esta métrica clave desempeña un papel fundamental en el comercio al medir la cantidad de tiempo que lleva fabricar bienes e ingresarlos 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 un único código base, los desarrolladores pueden evitar el tiempo y el trabajo adicionales de incorporar software de varias fuentes.

• Escalabilidad: la arquitectura de microservicios se basa en servicios individuales que se pueden compartimentar en formas modulares y obtienen beneficio del acoplamiento flexible y la intercomunicación logrados mediante el uso de API. Por otro lado, la arquitectura monolítica muestra menos 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 software para detectar y localizar problemas de programación y, a continuación, solucionarlos. La arquitectura monolítica maneja la depuración mejor que los microservicios porque es más simple 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 mediante el uso de una arquitectura monolítica o una arquitectura de microservicios. Estos son algunos de los más frecuentes.

• Startups: las empresas que recién comienzan necesitan dos cosas: flexibilidad y financiamiento inicial (y mucho de ambos). Una arquitectura monolítica es la mejor manera de iniciar negocios incipientes. Además, puede ser construida por equipos de desarrollo lean de una manera rentable que no imponga una curva de aprendizaje demasiado pronunciada en esos equipos pequeños.

• Proyectos básicos: tener un código base único paga dividendos en conveniencia, especialmente con proyectos que son 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: ejecutar una plataforma internacional de entretenimiento requiere la capacidad de navegar 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 de la transmisión de video hizo la transición de una arquitectura monolítica a una arquitectura de microservicios basada en la nube. El nuevo backend de Netflix contiene una gran cantidad de soporte para 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 realidad la magia del mercado electrónico con una experiencia de usuario 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 microservicios suele requerir las habilidades de implementación y administración de equipos de DevOps capacitados que puedan crear los servicios específicos necesarios para esa infraestructura. Esas habilidades son especialmente útiles cuando se encuentran 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 es su trabajo no solo seleccionar el sistema arquitectónico óptimo para su organización, sino también estimar con precisión el sistema arquitectónico que su empresa necesitará en los próximos meses y años. De alguna manera, se le asigna la tarea de predecir el futuro.

Por lo tanto, si bien una arquitectura monolítica puede parecer perfectamente ideal para su startup, 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 considerar:

• Lógica empresarial en uso: así como la lógica informática dicta lo que es y no es posible con una computadora, la lógica empresarial se basa en reglas de negocio que rigen cómo se puede y no se puede operar una empresa. Técnicamente, se traduce en los algoritmos que definen cómo se pasa la información entre una base de datos y una interfaz de usuario.

• Desarrollo frontend: tan pronto como planifique el frontend de su arquitectura de software, debe definir qué enfoque arquitectónico está siguiendo, porque cada uno tiene una estructura única. En una arquitectura monolítica, la aplicación frontend se manifiesta como una gran base de código que alberga todo el código de la aplicación. En una aplicación de microservicios frontend, se pueden poner en funcionamiento múltiples microservicios que operan de forma independiente.

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

• Tasa de cambio esperada: la elección entre arquitectura monolítica y arquitectura de microservicios no es simplemente una 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 arquitectura de microservicios, como ciclos de desarrollo más rápidos y escalabilidad mejorada.