Las redes han sido durante mucho tiempo el obstáculo en las aspiraciones empresariales hacia arquitecturas de alto rendimiento, multinube o híbridas. Si bien estas arquitecturas alguna vez fueron palabras de moda de marketing aspiracionales, son la realidad empresarial actual. Ahora, con el lanzamiento de Cilium Mesh, las empresas obtienen “una nueva capa de red universal para conectar cargas de trabajo y máquinas en la nube, en las instalaciones y en el perímetro”. Cilium Mesh, que consta de un componente de red de Kubernetes, un plano de conectividad de varios clústeres y una puerta de enlace de tránsito, ayuda a las empresas a unir sus activos de red locales en un mundo nativo de la nube.
Suena genial, y es genial, pero llegar a este punto fue cualquier cosa menos simple. También sigue siendo complejo para las empresas que esperan conectar su infraestructura existente con enfoques más modernos.
A veces damos por sentadas las arquitecturas nativas de la nube porque no apreciamos los requisitos complejos que imponen en la capa de infraestructura. Por ejemplo, el software de infraestructura ahora debe ser capaz de ejecutarse igualmente bien en infraestructura de nube pública o privada. Debe ser altamente escalable para cumplir con la agilidad de los contenedores y CI/CD. Debe ser muy seguro porque a menudo se ejecuta fuera de las instalaciones de la empresa. Y aún debe cumplir con los requisitos de redes empresariales tradicionales en términos de interoperabilidad, observabilidad y seguridad, todo mientras que en general es de código abierto y algo impulsado por la comunidad.
Ah, y para ser relevante para las empresas, toda esta bondad nativa de la nube debe traducirse en la “maldad” de la infraestructura heredada que las empresas han estado ejecutando durante años. Esto es lo que Cilium Mesh hace por la capa de red, y es lo que Thomas Graf, cofundador y director de tecnología de Isovalent, el creador de Cilium, se tomó el tiempo de explicar.
Salta a:
En camino a la nube nativa
Cilium y Kubernetes surgieron aproximadamente al mismo tiempo, con Cilium ganando rápidamente su lugar como la abstracción de red predeterminada para todas las principales ofertas de proveedores de servicios en la nube (por ejemplo, Azure Kubernetes Service y Amazon EKS Anywhere). No es que todos manejen Cilium a sabiendas. Para muchos, obtienen Cilium como un bono oculto mientras usan los servicios administrados de una nube. Según Graf, cuánto sabe una empresa sobre el uso de Cilium tiene mucho que ver con el lugar en el que se encuentra en su viaje a la nube.
En la etapa inicial de un viaje de Kubernetes, a menudo es solo un equipo de aplicaciones el que usa Kubernetes mientras construyen una versión inicial de la aplicación. Vemos un uso intensivo de los servicios administrados en esta fase y requisitos muy limitados en la red, además de la necesidad de exponer la aplicación públicamente a través de una puerta de enlace Ingress o API. Graf señaló: “Estos casos de uso iniciales se resuelven muy bien mediante servicios gestionados y ofertas en la nube, que han acelerado el camino hacia el desarrollo masivo de servicios. Los equipos de aplicaciones pequeños pueden ejecutar e incluso escalar servicios con bastante facilidad al principio”.
Sin embargo, con más experiencia y una mayor adopción de Kubernetes, esto cambia y, a veces, de forma drástica.
Para los usuarios de Kubernetes de empresas más grandes, destacó Graf, aportan los requisitos empresariales típicos, como la microsegmentación, el cifrado y la integración SIEM. Si bien “estos requisitos no han cambiado mucho” a lo largo de los años, enfatizó, “su implementación debe ser completamente diferente hoy”. ¿Cómo? Bueno, para empezar, su implementación ya no puede interrumpir el flujo de trabajo de desarrollo de aplicaciones. Los equipos de aplicaciones ya no están interesados en presentar tickets para escalar la infraestructura, abrir puertos de firewall y solicitar bloques de direcciones IP. En otras palabras, resumió: “El equipo de la plataforma tiene la tarea de cumplir con todos los requisitos de la empresa sin interrumpir ni deshacer las ganancias que se han logrado en la agilidad y la eficiencia del desarrollador”.
Además, la plataforma construida es independiente de la nube y funciona igualmente bien en nubes públicas y privadas. Los requisitos más recientes incluso exigen integrar servidores y máquinas virtuales existentes en la combinación sin ralentizar los procesos altamente ágiles basados en los principios de CI/CD y GitOps. No es trivial; sin embargo, con Cilium Mesh, es muy factible.
Este cambio cambiará las redes más que las SDN
Con Cilium Mesh, el proyecto ha unificado algunos tipos específicos de problemas de redes híbridas y multinube, como la conectividad de clústeres, la malla de servicios y ahora los entornos heredados. Ahora que Kubernetes se ha convertido en una plataforma estándar, sugirió Graf, ha establecido un conjunto de principios que deben encontrar su camino en la infraestructura existente de una empresa. En otras palabras, como continuó Graf, “las redes existentes con flotas de máquinas virtuales o servidores deben poder conectarse a la nueva estrella polar de los principios de infraestructura: Kubernetes”.
Aquí es donde las cosas se ponen interesantes y es donde Cilium Mesh se vuelve crítico.
“Con Cilium Mesh, llevamos todo Cilium, incluidas todas las API creadas sobre Kubernetes, al mundo fuera de Kubernetes”, declaró Graf. En lugar de ejecutarse en los nodos de trabajo de Kubernetes, Cilium se ejecuta en máquinas virtuales y servidores en forma de puertas de enlace de tránsito, equilibradores de carga y puertas de enlace de salida para conectar las redes existentes con nuevos principios nativos de la nube, incluida la aplicación de seguridad de confianza cero basada en la identidad, totalmente planos de control distribuido y observabilidad moderna con Prometheus y Grafana.
Es importante destacar que Cilium Mesh es igualmente atractivo para los equipos de la plataforma Kubernetes y los equipos de NetOps más tradicionales. El enfoque nativo de Kubernetes brinda a los equipos de la plataforma la confianza necesaria para asumir una responsabilidad adicional en la administración de la infraestructura que no es de Kubernetes, mientras que el uso de componentes básicos conocidos, como las puertas de enlace de tránsito y el Protocolo de puerta de enlace fronteriza (esencialmente, el servicio postal para Internet), brinda a NetOps equipo un camino claro pero incremental hacia un mundo de Kubernetes.
Este es un gran problema para las empresas que luchan por dar sentido a la multinube, que incluye a casi todos. Es cierto que el concepto de nube múltiple se ha discutido durante mucho tiempo, pero solo ahora estamos superando la exageración (es decir, la capacidad de implementar simultáneamente en múltiples nubes públicas para optimizar los costos) a la realidad desordenada de la TI empresarial ( es decir, diferentes equipos usan diferentes herramientas por una serie de razones diferentes). La lucha principal, señaló Graf, “se trata menos de cómo conectar a todos los proveedores de nube pública (y más bien) de cómo llegar a una arquitectura unificada para conectar la infraestructura local existente con cada oferta de nube pública mientras se mantiene una seguridad y una observabilidad uniformes. capas.”
Este cambio a los principios de estilo Kubernetes que impulsan la capa de red tiene una variedad de beneficios. El principal de ellos serán equipos significativamente más pequeños que operarán y proporcionarán infraestructura de manera más efectiva al tiempo que ofrecerán plataformas que permitirán a las empresas adoptar prácticas de desarrollo modernas para seguir siendo competitivas. Es un gran problema, y promete cambiar las redes incluso más completamente de lo que alguna vez lo hicieron las redes definidas por software.
Divulgación: trabajo para MongoDB, pero las opiniones expresadas aquí son mías.
