La atracción gravitacional de las aplicaciones está bifurcando la red.

La red se está bifurcando. Bifurcando. Dispersando. Le invitamos a utilizar cualquier término que desee para describir el fenómeno de los servicios de red que se trasladan desde el tranquilo suburbio que es la red corporativa a los agitados y ruidosos barrios urbanos en el lado de la aplicação de la red del centro de datos. La terminología no es el objetivo de la discusión de hoy, más bien hoy vamos a reflexionar sobre la razón por la que esto sucede.

Algunos podrían decir: "Bueno, Lori, es obvio que la red corporativa está muy basada en hardware, y el hardware simplemente no tiene la flexibilidad ni la agilidad necesarias para adaptarse al entorno más moderno y ágil que existe en desarrollo y operaciones".

Bueno, no. No se trata tanto de hardware ni de software, porque, en realidad, necesitas hardware independientemente de lo que hagas (recursos como la RAM, el cómputo y el acceso a la red no surgen de la nada, ¿sabes?). Se trata más de la cultura operativa y de las realidades que rigen cada una de las dos redes que impulsan algunos servicios de un lado al otro.

De hecho, yo diría que lo que realmente está sucediendo es que las aplicações son ahora el centro de gravedad y están atrayendo todos los servicios afines a las aplicaciones de la misma manera que la Luna es atraída por la Tierra.

El problema es que los servicios afines a la aplicación (como el equilibrio de carga, el almacenamiento en caché, la aceleración y la seguridad de las aplicaciones web) son muy peculiares de una aplicação determinada. Estos no son servicios que se adapten a todos. Por el contrario, se trata de servicios altamente enfocados y centrados en aplicaciones cuyas políticas están destinadas a entregar, proteger y optimizar UNA aplicação.

No todos ellos. Ni siquiera todos son del mismo tipo. Sólo uno. Ese de allí.

Esto es muy diferente de, por ejemplo, un firewall de red o IPS/IDS cuyo funcionamiento en realidad no es tan específico de una aplicação. Las aplicaciones web se ejecutan en el puerto 80, así que ábralo y permita el acceso a través del firewall. Hay muy poca especificidad de “aplicação” en esto, salvo que, bueno, utilizan el mismo protocolo (HTTP) y se ejecutan en el mismo puerto.

Por el contrario, establecer una política de seguridad que determine qué tipo de datos (¿cadena? ¿entero? ¿alfanumérico?) y cuántos datos (¿15 caracteres? 12? 100?) se puede asociar con un solo campo de entrada (¿nombre de usuario? ¿correo electrónico? ¿comentario?) que está asociado con un solo URI (/login.x) es bastante específico de la aplicação . También lo son las políticas que rigen la minimización y la concatenación de hojas de estilo, y el monitoreo de la salud asociado con una aplicação en el servicio de equilibrio de carga.

Por qué es importante la afinidad

En la actualidad, se dice que una empresa promedio administra alrededor de 508 aplicações. Según nuestra investigación, el 31% de las organizaciones en realidad tienen 500 o más, pero ese tampoco es el punto, es solo una línea de base. Y es una base porque muchas organizaciones están planeando construir muchas más aplicações. Y luego están aquellas organizaciones que están adoptando una arquitectura de microservicios que no necesariamente están cambiando la cantidad de aplicações , pero sí están cambiando la cantidad de “sistemas”, por así decirlo, que van a necesitar los servicios afines a las aplicação mencionados anteriormente.

Entonces. Imagínese que una organización está pensando en duplicar el número de aplicações bajo gestión. Digamos que empezaron con 500 y ahora de repente van a tener 1000. Necesitan aprovisionar, configurar y gestionar todas y cada una de las políticas. Digamos que cada aplicación solo necesita 2 (uno para escala y otro para seguridad) para que los cálculos sean sencillos. Esas son 2.000 políticas que debes abordar. ¿Listo? Ir.

Sí. El problema no es que el “hardware” de la red corporativa no pueda manejar eso. Por el contrario, puede serlo precisamente porque se trata de un hardware especialmente diseñado y, por tanto, tiene una capacidad que va mucho más allá de la de un servidor de propósito general. El problema son los procesos y la mano de obra necesarios para hacerlo todo. No se trata solo de la cantidad de dispositivos que se necesitan, sino de la cantidad de políticas únicas (afines a la aplicación) que se deben implementar.

Y no sólo implementado, sino actualizado. Debido a que las políticas afines a la aplicación se configuran específicamente para una aplicação, existe una mayor probabilidad de que cuando se actualiza una aplicación o se introduce una solución, sus políticas de servicio de aplicación asociadas también deban actualizarse. Y con organizaciones queriendo implementar con mayor frecuencia, bueno... puedes imaginar que la gente de la red corporativa estaría completamente abrumada.

Del otro lado de la valla, en la red de aplicaciones, los equipos de desarrollo y operaciones están hambrientos. Hambriento de que se entreguen e implementen aplicaciones. Están listos para usar sus nuevas habilidades en automatización y orquestación para acelerar ese proceso.

Y así lo hacen, asumiendo la responsabilidad de cada vez más servicios afines a las aplicaciones e incorporándolos a sus arquitecturas y procesos de implementación. Con una mayor conciencia de DevOps y cierto estímulo de la industria por parte de SDN, los servicios de red están casi todos habilitados con API. Muchos otros están habilitados con plantillas que se adaptan como un guante a la mano de los operadores que emplean un enfoque de “infraestructura como código” para administrar e implementar la infraestructura necesaria para respaldar las aplicações.

Es por eso que cada vez aparecen más “servicios de aplicação ” en la red de aplicação y desplazan el centro de gravedad de la TI empresarial hacia las aplicação.

Es una estrategia de escalamiento empresarial y operativo. Es una forma de lidiar con el rápido crecimiento de la cartera de aplicação sin infringir la ley de Brooks al destinar más personal de red o de aplicação al problema.  Es una forma de permitir que TI entregue aplicaciones al mercado con mayor rapidez y frecuencia, sin la interrupción que causaría requerir repentinamente que los operadores de red gestionen dos, tres o más veces la cantidad de políticas que gestionan actualmente.