El ADC listo para la nube
Un controlador de entrega de aplicação (ADC) listo para la nube no es un ADC tradicional. Disponible para implementación en hardware personalizado o COTS, es una solución de software escalable que satisface la necesidad de una entrega e implementación de aplicações rápidas, seguras y disponibles. Un ADC preparado para la nube permite un enfoque moderno de dos niveles para las arquitecturas de centros de datos que combinan la estabilidad, la seguridad y la escala tradicionales con funciones programáticas modernas, flexibles, compatibles con la nube y DevOps.
Es una bonita descripción pero ¿qué significa?
Ya he escrito anteriormente sobre lo que se necesita para ser considerado un proxy de aplicación moderno y eso es sin duda una parte de lo que requiere un ADC preparado para la nube, pero los exigentes entornos actuales necesitan más que solo capacidades técnicas, necesitan integración de ecosistemas y la capacidad de soportar arquitecturas de aplicação modernas y emergentes.
Y, honestamente, hay muchos ADC que harían las mismas afirmaciones sobre su preparación para la nube y soporte para arquitecturas de aplicação tradicionales y emergentes, entre otras afirmaciones. Por eso, hoy me gustaría analizar en profundidad qué hace que un ADC preparado para la nube sea diferente de un ADC tradicional, antes de analizar en mayor profundidad por qué es tan importante en el mundo de las aplicação actual.
Cinco grados de diferenciación
Básicamente, hay cinco (seis, si quieres ser un poco pedante) maneras en que un ADC listo para la nube se diferencia de un ADC tradicional. Y como F5 prácticamente definió lo que debería ser un ADC mucho antes de que yo llegara, entendemos el ADC mejor que nadie. Tanto lo que necesitaban ser como lo que deben evolucionar para seguir ofreciendo aplicaciones con la velocidad, seguridad y estabilidad que las empresas necesitan.
Rendimiento
Esto es obvio, ¿verdad? Después de todo, si vas a sentarte frente a las aplicaciones y hacer de proxy para ellas, más te vale ser rápido (o mejor aún, más rápido) que las aplicaciones que estás entregando. Los ADC tradicionales se entregan en formatos de dispositivos. Chasis, herrajes, electrodomésticos. Pero aún así los ADC tradicionales han estado limitados por las CPU en ese hardware personalizado con el que tienen que trabajar. Los ADC son plataformas, por lo que tienden a centrarse en la velocidad general, al igual que las CPU de propósito general se centran en el procesamiento general. Pero casi siempre incluyen una variedad de opciones de aceleración de hardware que deben determinarse antes de la implementación. Puede que estemos locos, pero creemos que un ADC preparado para la nube debería poder ir más allá de esa limitación, entendiendo que una aplicación puede necesitar un servicio más que otro, mientras que una aplicación diferente puede necesitar otro servicio más que otro. Al igual que la noción misma de reutilizar el procesamiento a pedido que sustenta todo el concepto de computación en la nube, las organizaciones que invierten en hardware de cualquier tipo también deberían poder reutilizarlo.
El motivo por el que esto es importante en los servicios en capas sobre la red es que descargar tareas comunes a hardware específico (FPGAs), lo que significa que la CPU queda liberada para hacer otras cosas, como inspección de solicitud/respuesta, modificación, limpieza, etc. Eso hace que toda la "parada" en el proxy sea más rápida, lo que se traduce en una menor latencia y usuarios más felices.
Es por eso que un ADC preparado para la nube puede romper barreras, aprovechando el rendimiento definido por software y permitiendo a las organizaciones aumentar programáticamente el rendimiento del ADC para ciertos tipos de procesamiento, como la seguridad. Esto significa que si las necesidades de la organización cambian, el perfil de rendimiento de ese hardware se puede cambiar junto con ellas, según demanda. Eso es agilidad en hardware. Lo sé, es paradójico ¿verdad? Pero eso es parte de ser un ADC preparado para la nube: la capacidad de reutilizar hardware especializado para proteger las inversiones y eliminar la necesidad de costosas actualizaciones.
Programabilidad
Una frustración de larga data que he escuchado personalmente una y otra vez de los clientes es la discordia entre NetOps y DevOps cuando se trata de capacidades de scripting. El problema es que el ADC tradicional solo ofrecía los scripts más básicos y en lenguajes más familiares para NetOps, no para DevOps. Ahora, DevOps estaba dispuesto a aprender a aprovechar la creación de scripts en la ruta de datos porque permitía una variedad de enrutamiento de solicitudes y respuestas más ágiles, estrategias de escalamiento e incluso servicios de seguridad. Pero con el ADC tradicional instalado en la parte superior de la red principal, NetOps no estaba dispuesto a permitir que DevOps implementara scripts que pudieran interferir con el flujo de tráfico.
La disponibilidad de ediciones virtuales significó que DevOps ahora tenía acceso a su propio ADC personal y privado en forma de máquina virtual, pero todavía estaban obligados a aprender un lenguaje de programación en red. Eso no es nada bueno. Un ADC preparado para la nube debe admitir tanto NetOps en la red principal como DevOps en la red de aplicaciones, es decir, en la nube. Y DevOps y los desarrolladores en particular prefieren lenguajes más amigables para el desarrollo, como node.js. No sólo porque conocen el lenguaje, sino porque ya existe un rico repositorio de bibliotecas (como NPM ) y servicios que permiten una integración más rápida con una infraestructura amigable para los desarrolladores. Es por eso que un ADC preparado para la nube debería admitir ambos.
Seguridad de aplicaciones
Los ADC tradicionales han brindado durante mucho tiempo seguridad básica para las aplicação . Estar sentado frente a una aplicación, en particular aplicaciones web, significa que estas eran (y siguen siendo) generalmente lo primero en el centro de datos en poder reconocer un ataque y hacer algo al respecto. La mayor parte de esa seguridad giraba, comprensiblemente, en torno a la seguridad a nivel de protocolo. La protección contra inundaciones SYN, la detección de DDoS y otras opciones de seguridad relacionadas con TCP y HTTP básico han sido parte integral de los ADC tradicionales desde hace algún tiempo.
Pero un ADC preparado para la nube debería ir más allá. Es probable que sean uno de los pocos "dispositivos" incluidos en la arquitectura de la aplicación en sí, para garantizar la escala inevitable que necesitan las aplicações actuales, por lo que tener un enfoque similar en la seguridad de pila completa simplemente tiene sentido. Al menos eso creemos, sobre todo porque al hacerlo se mejora el rendimiento. Si tienes que detenerte para realizar algún tipo de procesamiento, lo más lógico es hacer lo máximo que puedas al mismo tiempo. Es más eficiente y elimina la latencia necesaria para viajar de una caja a otra. Si has viajado largas distancias con niños sabes de qué estoy hablando. Hay un baño en la gasolinera. No querrás volver a detenerte en un área de descanso cinco minutos después, ¿verdad? Lo mismo ocurre con la seguridad en la red. Haga todo lo que pueda a la vez para eliminar los gastos generales que a menudo son fuente de frustración tanto para los clientes como para la empresa. El rendimiento es fundamental y un ADC preparado para la nube debe hacer todo lo posible para garantizar experiencias de aplicaciones más rápidas.
Esto puede significar ofrecer nuevos modelos para gestionar la creciente demanda (y, en algunos casos, requisito) de respaldar comunicaciones seguras entre dispositivos móviles y aplicaciones. Esto significa soporte para Forward Secrecy (FS) y la criptografía que lo habilita. Significa habilitar nuevos modelos para descargar el procesamiento computacionalmente costoso de cifrado y descifrado al hardware diseñado para manejarlo, sin romper las arquitecturas necesarias para soportar microservicios y aplicações emergentes. Un ADC preparado para la nube debe ser compatible con ambos, permitiendo comunicaciones rápidas y seguras y al mismo tiempo integrándose sin problemas en las arquitecturas y entornos de nube actuales.
Ecosistema de socios y automatización
La otra economía de API es fundamental para el éxito de la nube privada y la ventaja competitiva que brindan a las empresas los aumentos en la automatización y la orquestación. Pero por muy bueno que sea, siempre habrá una variedad de servicios en el centro de datos de diferentes proveedores, todos con diferentes modelos de objetos e integración. Eso a menudo significa una dolorosa automatización impulsada por API que requiere experiencia en todos los componentes necesarios. La realidad es que se requieren dos niveles de integración: uno para la orquestación y otro para la automatización (no, no son lo mismo) . Están las capacidades de automatización inherentes de la plataforma, a través de API y plantillas, y luego está la integración nativa en el ecosistema de socios, donde la orquestación reina suprema. Ambos son necesarios para un ADC preparado para la nube. El primero garantiza la automatización mediante productos propietarios o scripts y frameworks personalizados como Puppet y Chef, mientras que el segundo permite la orquestación mediante controladores cada vez más importantes como OpenStack, VMware y Cisco.
Un ADC preparado para la nube debe integrarse de forma nativa y ofrecer orquestación a través de los marcos y sistemas que se utilizan para proporcionar una solución de orquestación integral.
No debería ser necesario repetir más de una vez que un ADC preparado para la nube debe admitir plantillas en la nube.
Así que eso es todo lo que voy a decir al respecto.
Modelo de aplicación
Los ADC tradicionales nacieron de la necesidad de ofrecer un conjunto sólido de servicios para aplicações tradicionales. Monolitos, por así decirlo. Las aplicações actuales están cada vez más distribuidas, son diversas y diferentes que sus predecesoras tradicionales y aprovechan una variedad de arquitecturas, plataformas y modelos de implementación. Ya sean contenedores o máquinas virtuales, entornos en la nube o similares, las aplicações aún necesitan algunos de esos servicios. Y donde se necesite más de un servicio a la vez (como, por ejemplo, balanceo de carga y seguridad de aplicaciones), se necesitará un ADC. Si bien un ADC tradicional puede no ser adecuado para microservicios, un ADC preparado para la nube sí lo será. Esto incluye un conjunto más amplio de servicios que pueden beneficiarse del equilibrio de carga y la seguridad, servicios que caen directamente dentro del ámbito de DevOps, no de NetOps, como Memcached .
Si bien es una plataforma, un ADC preparado para la nube admite los requisitos de programabilidad, integración y formato necesarios para brindar los servicios que necesitan tanto las aplicaciones tradicionales como las emergentes, en el entorno que los necesitan.
Hay muchas similitudes entre un ADC tradicional y uno preparado para la nube. Ambos siguen siendo plataformas capaces de habilitar múltiples servicios con un modelo operativo común. Ambos son programables, se integran con otros centros de datos y sistemas en la nube y brindan flexibilidad en las capacidades de rendimiento. Pero un ADC preparado para la nube va más allá de lo tradicional, ya que admite ambos y al mismo tiempo habilita el futuro de los negocios, las aplicações y su necesidad cada vez más diversa de integrarse e interoperar con una amplia variedad de infraestructuras y entornos.