Microservicios: menos micro y más servicios
La arquitectura orientada a servicios (SOA) fue declarada muerta hace casi diez años. Un factor que contribuyó a su desaparición, aunque rara vez se discute, fue la red. La latencia entre servicios impidió que los arquitectos descompusieran completamente las aplicações en servicios con la granularidad necesaria para fomentar la reutilización y, en última instancia, aplicações componibles.
Ingresa la arquitectura de microservicios (MSA). Sus principios exigen una descomposición aún mayor, con un enfoque en la función (verbos) sobre el objeto (sustantivos) como criterio principal para dividir una aplicação. De este cambio de enfoque aparentemente sutil surge una mayor granularidad de los servicios: hay muchas más funciones que objetos en un sistema determinado.
La red está lista. Las velocidades y los avances de la red física han aumentado drásticamente. La informática también ha avanzado de acuerdo con la Ley de Moore y ha hecho que la latencia de la red sea prácticamente un problema sin importancia.
Desafortunadamente, la latencia de la comunicación ocupará su lugar.
Hemos replicado en el interior de los entornos contenedores utilizados para desplegar microservicios la complejidad de Internet. Si bien un microservicio puede no necesitar DNS, aún depende del mismo tipo de resolución basada en nombres que ejecuta Internet. Las etiquetas de aplicação (metadatos) deben traducirse a una dirección IP. Los registros de servicio y las entradas de tablas IP complejas actúan como DNS en miniatura, traduciendo etiquetas en direcciones y permitiendo la comunicación entre servicios.
Lo que agrava la latencia asociada con este proceso es la naturaleza efímera de los microservicios y sus contenedores asociados. Dado que la duración de la vida se mide en segundos o minutos en lugar de horas o meses, la resolución de nombres debe ocurrir con cada llamada. El tiempo de vida (TTL) dentro del mundo de los contenedores es, efectivamente, cero.
Incluso si ignoramos esta reproducción de una de las mayores fuentes de latencia de comunicación, nos queda la asociada con TCP. No es (ni nunca ha sido) gratuito iniciar o interrumpir una conexión TCP. Esta fuente de latencia es ciertamente pequeña pero absolutamente aditiva. Cada conexión (cada microservicio) necesaria para ejecutar una sola transacción agrega latencia que eventualmente supera la tolerancia al retraso.
HTTP/2, a pesar de sus dramáticos cambios en el comportamiento, no aborda este problema. HTTP/2 está diseñado para facilitar la transferencia de múltiples objetos a través de la misma conexión, reduciendo así la latencia para contenido de múltiples objetos, como páginas web y aplicações basadas en web. Los microservicios están diseñados idealmente para que cada servicio devuelva una única respuesta. Si bien varias solicitudes a través de una conexión establecida ciertamente reducirán la sobrecarga de comunicaciones, no pueden hacerlo en un sistema donde varias solicitudes se distribuyen entre múltiples servicios discretos .
El problema entonces no es la latencia de la red sino la latencia de la comunicación. Las conexiones todavía cuentan, y las mejoras en los protocolos diseñados para mejorar el rendimiento de las comunicaciones multitransaccionales basadas en la Web no ayudarán a las transacciones multiservicio.
El resultado es SOMA. Microarquitecturas orientadas a servicios. Un extraño híbrido de arquitecturas orientadas a servicios y microservicios que deja a uno preguntándose dónde termina una y comienza la otra. La descomposición de las aplicações en sus servicios compuestos basados en funciones está limitada por la latencia de la comunicación y, en última instancia, por la sostenibilidad de la base del código. Si bien es cierto que los avances en la red han aumentado la granularidad con la que se puede lograr razonablemente la descomposición, no han eliminado la restricción. Otro factor es que hay órdenes de magnitud más de funciones en una aplicação que de objetos, lo que hace que la tarea de administrar una aplicação con arquitectura de microservicios puros sea una pesadilla logística para las operaciones de red, y más aún para los desarrolladores de aplicaciones. Combinado con el problema inherente que plantea la latencia de las comunicaciones, las organizaciones están desarrollando cada vez más microservicios orientados a objetos en lugar de microservicios verdaderamente orientados a funciones.
En definitiva, este es el motivo por el que vemos que la aplicação se descompone más allá de la arquitectura tradicional de tres niveles, pero no hasta el punto de ser una representación fiel de la descomposición basada en funciones.
Hasta que no abordemos la latencia inherente a las comunicaciones basadas en conexión (TCP), ya sea con algo nuevo o concentrándonos en las implementaciones a nivel de sistema, seguiremos limitados a arquitecturas de microservicios que son menos micro y más servicios.