A medida que la nube pública se ha expandido, posiblemente el sector que menos ha crecido somos nosotros, los humanos. Cada nuevo servicio responde a una necesidad de acelerar la programación o de simplificar la configuración y la implementación. AWS Transit Gateway ha logrado reducir la complejidad de las redes en la nube al actuar como un centro compartido central para VPC, pero el servicio solo funciona dentro de AWS.
F5 Volterra ofrece una solución que extiende y mejora el modelo de concentrador y radio dentro de otras nubes, así como a nivel global entre nubes, lo que incluye la simplificación de la configuración y la implementación del propio AWS Transit Gateway.
Las conexiones entre VPC de redes virtuales en la nube tradicionalmente han sido ad hoc, creando conexiones dondequiera que se perciba una necesidad. Para una implementación desde cero, esas conexiones pueden ser útiles para reflejar las relaciones entre microservicios y aplicar controles de acceso. También puede existir la necesidad de reflejar restricciones en los entornos físicos, como permitir conexiones entre nodos en la misma ubicación que de otro modo seguirían una ruta ineficiente como el clásico “trombón” o “boomerang”. Sin embargo, la infraestructura diseñada específicamente para una única implementación históricamente impone restricciones a cualquier cambio futuro, lo que conduce a la percepción de la necesidad de una reestructuración completa a medida que el diseño inicial evoluciona orgánicamente.
A medida que aumentan las conexiones ad hoc, la arquitectura tiende hacia una topología de malla, en la que cada nodo está conectado a muchos otros. Si bien las topologías de malla permiten una máxima flexibilidad en la ruta de datos(cada destino posible está conectado directamente), las mallas pueden ser notoriamente tediosas de crear y mantener sin una automatización sustancial.
A diferencia de la arquitectura ad hoc, la arquitectura de centro y radios es una forma disciplinada de organizar las conexiones. En un grupo de cosas, una cosa actúa como un centro para conectar con todas las demás cosas, pero ninguna de las otras se conecta entre sí. Visualmente esto suele dibujarse como una rueda de bicicleta, pero también se suele representar como una estructura de árbol, con el eje en la parte superior y los radios en la parte inferior, como un árbol genealógico. La mayor ventaja de un sistema de concentradores y radios o de un árbol es la simplicidad. Es fácil de dibujar y fácil de entender, porque el único camino entre los radios es a través del eje. Eso también significa que es más fácil de mantener; no solo lleva menos tiempo identificar el dominio del problema durante un incidente, sino que la estructura básica no se ve afectada por ningún movimiento, adición o cambio de nodos.
Las desventajas generalmente se consideran como falta de flexibilidad y menor rendimiento. Sin embargo, un centro bien implementado permite que el tráfico se mueva rápidamente, y las ventajas de mantenimiento continuo derivadas de la simplicidad superan cualquier beneficio temporal de flexibilidad durante la configuración. El concentrador y radio también proporciona una ruta de datos garantizada entre dos nodos, acercándose a la flexibilidad de una malla completa y reduciendo la necesidad de conexiones ad hoc.
Las redes en la nube inicialmente requerían conexiones ad hoc entre instancias de cómputo hasta la llegada de las redes virtuales VPC. Las VPC proporcionan conectividad directa en cada subred, lo que simplifica enormemente la configuración y la aplicação de políticas. Es útil pensar en cada VPC como si fuera un centro y un radio.
AWS Transit Gateway interconecta las VPC de la misma manera que las VPC interconectan las instancias de cómputo. Básicamente, actúa como un concentrador y radios escalonados, un centro de concentradores o una VPC de VPC. Los nodos en diferentes VPC pueden conectarse entre sí si esas VPC están conectadas a la misma puerta de enlace de tránsito. Las puertas de enlace de tránsito también pueden permitir compartir recursos dedicados, como la combinación de VPN mediante múltiples VPC para obtener ancho de banda adicional o acceso remoto simplificado de usuarios.
F5 Volterra proporciona una interfaz de usuario uniforme para crear conexiones entre nubes, configurar VPC en esas nubes utilizando sus API nativas de infraestructura como código y administrar el tráfico y la prestación de servicios. En AWS, proporciona configuración completa y control del ciclo de vida de los Transit Gateways. Si no se utilizan AWS Transit Gateway u otros servicios nativos del proveedor de nube , la consola Volterra proporciona una forma uniforme de establecer y controlar conexiones entre redes virtuales, convirtiendo la intención del administrador en la configuración específica de la nube. En escenarios donde existe la necesidad de conexiones arbitrarias entre subredes de redes virtuales, Volterra incluso automatizará la creación de una malla completa si el administrador lo desea. La configuración rápida reduce enormemente el tedio y la automatización casi elimina las posibilidades de errores.
Volterra extiende el concepto de red de múltiples niveles y de radios al nivel global, funcionando efectivamente como una puerta de tránsito de múltiples nubes para conectar nubes públicas y privadas. La consola Volterra basada en SaaS proporciona un control global unificado en todas las regiones de todas las principales nubes públicas, así como en cualquiera de las nubes privadas que el cliente quiera conectar. La arquitectura global es completamente configurable, ya sea que requiera conexiones ad hoc, una malla multi-nube completa o un concentrador y radio que utiliza la red global de F5 como una columna vertebral privada dedicada de alta velocidad.
La aplicación de la automatización y la arquitectura de múltiples niveles simplifica la tarea de un administrador a la hora de gestionar el escalamiento horizontal de las nubes, pero los beneficios reales provienen de los administradores de escalamiento horizontal. La consola Volterra es multiinquilino de forma nativa y admite la subdivisión de la organización en diferentes espacios de nombres. Cada espacio de nombres es completamente invisible para todos los demás, incluso en la capa IP. Dentro de cada espacio de nombres, los administradores pueden establecer políticas basadas en intenciones y luego delegar el control a los desarrolladores para la gestión de autoservicio del ciclo de vida de sus conexiones y servicios seguros específicos del proyecto, sin riesgo de perturbar otros proyectos o exceder los parámetros de seguridad y red preestablecidos. Esto representa escalabilidad humana en toda la organización, brindando a los ingenieros de base control y visibilidad de la red multi-cloud dentro de sus propios silos, con supervisión global completa para los administradores de la red en la nube.