Los microservicios (y sus inseparables compañeros, los contenedores) están empezando a conquistar a desarrolladores de todo tipo. No solo las startups están adoptando los principios de diseño granular, débilmente acoplado y basado exclusivamente en API de los microservicios; las grandes empresas también se están sumando a esta tendencia.
Con el aumento de la adopción (Datadog, un proveedor de monitorización de infraestructuras en la nube, ha experimentado un crecimiento de casi cinco veces en los 12 meses transcurridos desde septiembre de 2014), se alzan voces muy críticas que proclaman la muerte de las aplicaciones monolíticas y califican su arquitectura, totalmente inadecuada, no solo de obsoleta, sino de sencillamente mala.
Pero, como señaló un artículo reciente de Gigaom, hay que tener en cuenta ciertas contrapartidas antes de sacar el martillo neumático y descomponer cada aplicación monolítica en cien microservicios diferentes. Por cierto, este concepto no es nuevo. Martin Fowler, el padre de los microservicios, ya escribió hace tiempo sobre estas contrapartidas y ha advertido sobre lo que solo puede calificarse de «adopción ciega» de los microservicios. De hecho, el artículo de Gigaom plantea, en líneas generales, los mismos argumentos que Fowler, aunque de forma más concisa.
Si buscas la versión resumida de ambos, básicamente se reduce a esto: los microservicios añaden complejidad operativa y pueden afectar negativamente a la experiencia de uso de la aplicación en términos de rendimiento. Ambas son consecuencias indeseables —y a menudo imprevistas— que deben comprenderse de antemano, antes de que ese tipo de ahí, en tu centro de datos, empiece a usar el martillo neumático metafórico.
Dicho todo esto, ¿por qué demonios le importa a Lori? Al fin y al cabo, ni ella ni F5 se dedican a crear o diseñar aplicaciones. F5 va a entregar esas aplicaciones, ya sean monolíticas, microservicios o próxima arquitectura de aplicaciones aquí>.
Todo eso es cierto. Pero nosotros nos dedicamos a crear e implementar los servicios de aplicaciones que permiten ofrecer esas aplicaciones, y las tendencias recientes, como DevOps y los microservicios (y la fiebre de los contenedores), plantean las mismas preguntas en nuestro ámbito. En concreto, ¿deberían descomponerse los servicios de aplicaciones que suelen implementarse en una plataforma ADC en servicios más granulares y específicos para cada aplicación siguiendo un modelo que se ajuste mejor a la arquitectura de microservicios?
La cuestión sigue siendo encontrar el equilibrio
Independientemente de si hablamos de la arquitectura de una aplicación o de las arquitecturas de sus servicios, la clave sigue siendo comprender las ventajas y desventajas antes de tomar una decisión de este tipo.
El enfoque de plataforma (monolítico)
Este es el enfoque tradicional para proporcionar los servicios de aplicaciones necesarios para proteger, escalar y optimizar aplicaciones de todo tipo. Los servicios se implementan en una única plataforma compartida. Gracias a la arquitectura del proxy subyacente, este enfoque ofrece la ventaja de mejorar el rendimiento. Esto se debe a que todas las solicitudes (y respuestas) pueden atravesar los servicios necesarios sin salir del mismo entorno. Por tanto, no se requieren saltos de red adicionales (ni la latencia asociada) ni conexiones adicionales (recursos, latencia). Cada servicio puede seguir escalándose y gestionándose de forma individual, pero todos dependen de un único componente de hardware compartido (comercial o personalizado). Esto significa que el hardware compartido constituye un único punto de fallo que afectará no solo a uno, sino a muchos servicios.
El enfoque de proxy por aplicación (microservicios)
Este modelo se ajusta mejor a DevOps y a las nuevas prácticas de arquitectura de aplicaciones. Cada servicio se despliega, gestiona y escala de forma individual. Aunque esto conlleva costes administrativos adicionales (al fin y al cabo, hay más instancias que gestionar), algunos de esos costes se reducen si todos los servicios se despliegan en la misma plataforma. Además, permite combinar servicios de distintos proveedores. La ventaja de este enfoque es que los servicios pueden vincularse más estrechamente a la arquitectura de la aplicación y, por tanto, integrarse en ella, incluida la integración con marcos de automatización populares.
La descomposición de la entrega de aplicaciones en los distintos servicios que la componen presenta los mismos inconvenientes, a saber, problemas de rendimiento y una complejidad cada vez mayor. Por el contrario, las mismas razones por las que los desarrolladores están adoptando los microservicios y evitando las arquitecturas monolíticas —es decir, el deseo de agilidad, diversidad y modularidad— también son aplicables a la entrega de aplicaciones.
Me limitaré a citar 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. Sin embargo, otros equipos han comprobado que supone una carga que merma la productividad. Como cualquier estilo arquitectónico, los microservicios conllevan costes y beneficios. Para tomar una decisión sensata, hay que comprenderlos y aplicarlos al contexto específico de cada caso».
Esta afirmación se aplica igualmente a los servicios de aplicaciones. Tanto el enfoque tradicional (monolítico) como el moderno (basado en microservicios) presentan costes y ventajas que deben evaluarse en el contexto de la aplicación que van a entregar, proteger y optimizar.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.