Sobre monolitos versus microservicios
Los microservicios (y sus mejores amigos, los contenedores, a los que a menudo se hace referencia) están comenzando a apoderarse de los corazones y las mentes de los desarrolladores en general. No son solo las empresas emergentes las que están adoptando los principios de diseño granular, de solo API y poco acoplados de los microservicios; las grandes empresas también se están sumando al juego.
Con la creciente adopción ( Datadog , un proveedor de monitoreo de infraestructura en la nube, ha visto un crecimiento de casi 5 veces en los 12 meses desde septiembre de 2014), surgen los gritos muy fuertes que declaran la muerte de las aplicações monolíticas y su arquitectura completamente inapropiada, que no solo están obsoletas, sino que son simplemente malas.
Pero, como se señaló en un artículo reciente en Gigaom , hay que tener en cuenta ciertas desventajas antes de sacar el martillo neumático y dividir cada monolítico en cien microservicios diferentes. Este no es un concepto nuevo, por cierto. El padre de los microservicios, Martin Fowler, escribió sobre estas compensaciones hace mucho tiempo y advirtió sobre lo que solo puede considerarse una “adopción a ciegas” de los microservicios. De hecho, el artículo de Gigaom en general plantea los mismos puntos que Fowler, aunque en un formato más conciso.
Si buscas el resumen de ambos, básicamente se reduce a esto: los microservicios agregan complejidad operativa y pueden afectar negativamente la experiencia de la aplicação en términos de rendimiento. Ambas son consecuencias indeseables, y a menudo no intencionadas, que es necesario comprender de antemano, antes de que ese tipo allí en su centro de datos empiece con el martillo neumático alegórico.
Dicho todo esto, ¿por qué carajo le importa a Lori? Después de todo, ni ella ni F5 se dedican a crear o diseñar aplicações. F5 entregará esas aplicaciones ya sean monolitos o microservicios o la próxima arquitectura de aplicaciones aquí>.
Todo cierto. Pero nuestro negocio es construir e implementar servicios de aplicação que entregan esas aplicações , y movimientos recientes como DevOps y microservicios (y la fiebre de los contenedores) traen las mismas preguntas a nuestro dominio. Es decir, ¿debería descomponer los servicios de aplicaciones que normalmente se implementan en una plataforma ADC en sus servicios más granulares y afines a la aplicación en un modelo que se alinee más de cerca con la arquitectura de microservicios?
Todavía se trata de compensaciones
Independientemente de si hablamos de arquitectura de aplicaciones o de arquitecturas de servicios de aplicaciones, la respuesta sigue siendo comprender las ventajas y desventajas involucradas antes de tomar tal decisión.
El enfoque de plataforma (monolítico)
Este es el enfoque tradicional para brindar los servicios de aplicaciones necesarios para proteger, escalar y optimizar aplicações de todo tipo. Los servicios se implementan en una única plataforma compartida. Debido a la arquitectura del proxy subyacente, este enfoque tiene la ventaja de mejorar el rendimiento. Esto se debe a que todas las solicitudes (y respuestas) pueden atravesar los servicios requeridos sin abandonar el mismo entorno. Esto significa que no son necesarios saltos de red adicionales (y la latencia asociada) ni conexiones (recursos, latencia). Cada servicio puede escalarse y gestionarse individualmente, pero todos dependen de una única pieza de hardware compartida (COTS o personalizada). Esto significa que el hardware compartido es un único punto de falla que afectará no a uno sino a muchos servicios.
El enfoque de proxy por aplicación (microservicios)
Este modelo se alinea más de cerca con DevOps y las prácticas de arquitectura de aplicação emergentes. Cada servicio se implementa, gestiona y escala individualmente. Si bien esto genera costos administrativos adicionales (después de todo, hay más instancias que administrar), algunos de esos costos se mitigan si cada servicio se implementa en la misma plataforma, pero ofrece la posibilidad de “mezclar y combinar” servicios de diferentes proveedores. Las ventajas de este enfoque son que los servicios pueden asociarse más estrechamente con la arquitectura de la aplicação (y, por lo tanto, incluirse como parte de ella), incluida la integración con marcos de automatización populares.
Los mismos inconvenientes, es decir, los de rendimiento y creciente complejidad, están asociados con la descomposición de la entrega de aplicação en sus servicios de aplicação compuestos. Por el contrario, las mismas razones por las que los desarrolladores adoptan microservicios y evitan los monolitos (es decir, el deseo de agilidad, diversidad y modularidad) también son válidas para la entrega de aplicação .
Voy a citar simplemente a Martin Fowler: “ Muchos equipos de desarrollo han descubierto que el estilo arquitectónico de microservicios es un enfoque superior a una arquitectura monolítica. Pero otros equipos han descubierto que suponen una carga que socava la productividad. Como cualquier estilo arquitectónico, los microservicios conllevan costos y beneficios. Para tomar una decisión sensata es necesario comprenderlos y aplicarlos a nuestro contexto específico”.
Esta afirmación se aplica igualmente a los servicios de aplicação . Tanto el enfoque tradicional (monolítico) como el moderno (microservicios) tienen costos y beneficios que deben considerarse dentro del contexto de la aplicação que se van a entregar, proteger y optimizar.