La arquitectura orientada a servicios (SOA) se dio por muerta hace casi diez años. Un factor que contribuyó a su desaparición, aunque rara vez se menciona, fue la red. La latencia entre servicios impidió a los arquitectos descomponer por completo las aplicaciones en servicios con el nivel de granularidad necesario para fomentar su reutilización y, en última instancia, crear aplicaciones componibles.
Aquí entra en juego la arquitectura de microservicios (MSA). Sus principios exigen una descomposición aún mayor, centrándose en la función (verbos) por encima del objeto (sustantivos) como criterio principal para dividir una aplicación. Este cambio de enfoque, aparentemente sutil, da lugar a una mayor granularidad de los servicios, ya que en cualquier sistema hay muchas más funciones que objetos.
La red está preparada. La velocidad y el rendimiento de la red física han aumentado drásticamente. La capacidad de procesamiento también ha avanzado conforme a la ley de Moore, hasta el punto de que la latencia de red ha dejado prácticamente de ser un problema.
Por desgracia, la latencia en la comunicación ocupará su lugar.
Hemos reproducido la complejidad de Internet dentro de los entornos de contenedores utilizados para desplegar microservicios. Aunque un microservicio puede no necesitar DNS, sigue dependiendo del mismo tipo de resolución basada en nombres que hace funcionar Internet. Las etiquetas de las aplicaciones —los metadatos— deben traducirse a una dirección IP. Los registros de servicios y las complejas entradas de las tablas IP actúan como DNS en miniatura, traduciendo las etiquetas a direcciones y permitiendo la comunicación entre servicios.
La naturaleza efímera de los microservicios y sus contenedores asociados agrava la latencia vinculada a este proceso. Dado que su vida útil se mide en segundos o minutos, en lugar de horas o meses, la resolución de nombres debe realizarse en cada llamada. En el mundo de los contenedores, el tiempo de vida (TTL) es, en la práctica, cero.
Aunque ignoremos esta reproducción de una de las mayores fuentes de latencia en las comunicaciones, aún queda la asociada a TCP. Iniciar o cerrar una conexión TCP no es gratis, ni lo ha sido nunca. Esta fuente de latencia es ciertamente pequeña, pero totalmente acumulativa. Cada conexión —cada microservicio— necesaria para ejecutar una sola transacción añade latencia hasta que, finalmente, se supera el umbral de tolerancia al retardo.
HTTP/2, a pesar de sus drásticos cambios de comportamiento, no resuelve este problema. HTTP/2 está diseñado para facilitar la transferencia de varios objetos a través de una misma conexión, reduciendo así la latencia del contenido compuesto por varios objetos, como las páginas web y las aplicaciones web. Lo ideal es que los microservicios estén diseñados de modo que cada servicio devuelva una única respuesta. Aunque realizar varias solicitudes a través de una conexión ya establecida sin duda reduce la sobrecarga de las comunicaciones, esto no es posible en un sistema en el que las distintas solicitudes se distribuyen entre varios servicios independientes.
El problema, por tanto, no es la latencia de la red, sino la latencia de las comunicaciones. Las conexiones siguen siendo relevantes, y las mejoras en los protocolos diseñados para optimizar el rendimiento de las comunicaciones web con múltiples transacciones no servirán para las transacciones que impliquen varios servicios.
El resultado es SOMA: arquitecturas de microservicios orientadas a servicios. Un extraño híbrido entre las arquitecturas orientadas a servicios y las de microservicios que hace difícil discernir dónde termina una y comienza la otra. La descomposición de las aplicaciones en los servicios funcionales que las componen está limitada por la latencia de las comunicaciones y, en última instancia, por la sostenibilidad del código base. Aunque los avances en las redes han aumentado sin duda el nivel de granularidad con el que puede llevarse a cabo razonablemente la descomposición, no han eliminado esta limitación. Otro factor es que en una aplicación hay varios órdenes de magnitud más funciones que objetos. Esto hace que gestionar una aplicación con una arquitectura de microservicios pura sea una auténtica pesadilla logística para los equipos de operaciones de red, y no digamos para los desarrolladores de aplicaciones. Debido también al problema inherente que plantea la latencia de las comunicaciones, las organizaciones desarrollan cada vez más microservicios orientados a objetos en lugar de microservicios verdaderamente orientados a funciones.
En última instancia, esta es la razón por la que vemos que las aplicaciones se descomponen más allá de la arquitectura tradicional de tres capas, aunque sin llegar a constituir una representación fiel de la descomposición basada en funciones.
Hasta que no abordemos la latencia inherente a las comunicaciones basadas en conexiones (TCP), ya sea mediante algo nuevo o centrándonos en las implementaciones a nivel de sistema, seguiremos limitados a arquitecturas de microservicios que tienen menos de «micro» y más de «servicios».
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
Proteger los endpoints de las API dificulta la seguridad de las API
Descubre las complejidades de la seguridad de las API, los retos a los que se enfrentan las organizaciones, la evolución de los ataques contra endpoints de API y la necesidad de políticas de seguridad adaptadas.
¿Qué es el sesgo de la IA y por qué es importante para TI?
Descubre los fundamentos del aprendizaje de la IA. Aprende cómo pueden surgir sesgos en la IA y qué riesgos plantean para las TI y la transformación digital.
Redefiniendo la ciberseguridad en el extremo de la nube distribuida con IA y telemetría en tiempo real
La transformación digital y la adopción de tecnologías en la nube están provocando cambios en las arquitecturas de las aplicaciones. Estos cambios introducen nuevas superficies de ataque, que son el objetivo de métodos de ataque avanzados, altamente organizados y con motivaciones económicas. Mediante el uso del framework Morpheus de NVIDIA, F5 está investigando técnicas para detectar estas amenazas avanzadas con telemetría en tiempo real y análisis basados en IA.
El papel de la nube en las aplicaciones nativas del edge
No debería sorprender que, al igual que la aparición de la nube dio lugar a las aplicaciones nativas de la nube, el edge esté impulsando un conjunto de aplicaciones nativas del edge. Sin embargo, estas aplicaciones no residirán únicamente en el edge. Al mismo tiempo, están surgiendo nuevos patrones arquitectónicos que aprovechan las aplicaciones alojadas en la nube y en el centro de datos.
La creciente diversidad de ubicaciones y usuarios está impulsando a las empresas hacia el edge
En el contexto del ámbito de las aplicaciones, el término «usuario» siempre se ha referido a la entidad que interactúa con una aplicación. Del mismo modo que los cambios en las arquitecturas de las aplicaciones impulsan cambios en las tecnologías que permiten ofrecerlas y protegerlas, los cambios en la definición de usuario han provocado cambios en los lugares donde se despliegan las aplicaciones.
El edge está impulsando un renacimiento de las infraestructuras
A medida que las organizaciones aumentan la generación de datos y tratan de extraer valor empresarial de ellos, sin duda recurrirán a la analítica y la automatización basadas en la IA y el aprendizaje automático. Precisamente este tipo de cargas de trabajo son las que más se beneficiarían de una infraestructura optimizada y, sin embargo, hoy en día son las que menos probabilidades tienen de poder aprovecharla.