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

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

La red se está dividiendo. Bifurcando. Dispersando. Puede utilizar el término que prefiera para describir el fenómeno por el que los servicios de red se trasladan desde el tranquilo barrio residencial que representa la red corporativa hasta los ajetreados y ruidosos distritos urbanos del lado de las aplicaciones de la red del centro de datos. La terminología no es el tema del debate de hoy; más bien, vamos a reflexionar sobre por qué está ocurriendo.

Algunos podrían decir: «Bueno, Lori, es evidente que la red corporativa se basa en gran medida en el hardware, y el hardware sencillamente no tiene la flexibilidad ni la agilidad necesarias para encajar en el entorno más moderno y ágil de desarrollo y operaciones».

Pues no. No se trata tanto del hardware o del software porque, en realidad, hagas lo que hagas, necesitas hardware (los recursos como la RAM, la capacidad de procesamiento y el acceso a la red no aparecen de la nada). Tiene más que ver con la cultura operativa y las realidades que rigen cada una de las dos redes, que están impulsando el traslado de algunos servicios de un lado al otro.

De hecho, diría que lo que realmente está ocurriendo es que las aplicaciones son ahora el centro de gravedad y atraen hacia sí todos los servicios afines a ellas, de forma muy similar a como la Luna es atraída por la Tierra.

La cuestión es que los servicios vinculados a las aplicaciones —como el equilibrio de carga, el almacenamiento en caché, la aceleración y la seguridad de las aplicaciones web— son muy específicos de cada aplicación. No son servicios universales. Al contrario, son servicios altamente especializados y centrados en la aplicación, cuyas políticas están diseñadas para proporcionar, proteger y optimizar UNA aplicación.

No todas. Ni siquiera todas las del mismo tipo. Solo una. Esa de ahí.

Esto es muy distinto de, por ejemplo, un cortafuegos de red o un IPS/IDS, cuyo funcionamiento no es realmente específico de una aplicación. Las aplicaciones web se ejecutan a través del puerto 80, así que basta con abrirlo y permitir el acceso a través del cortafuegos. Hay muy poca especificidad en cuanto a la «aplicación», aparte de 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 de texto? ¿entero? ¿alfanumérico?) y qué cantidad de datos (¿15 caracteres? ¿12? ¿100?) pueden asociarse a un único campo de entrada (¿nombre de usuario? ¿correo electrónico? ¿comentario?) vinculado a un URI concreto (/login.x) es algo sumamente específico de la aplicación. Lo mismo ocurre con las políticas que regulan la minificación y la concatenación de hojas de estilo, así como con la supervisión del estado de una aplicación en el servicio de balanceo de carga.

Por qué es importante la afinidad

Actualmente, se estima que una empresa media gestiona unas 508 aplicaciones. Según nuestra investigación El 31 % de las organizaciones tiene en realidad 500 o más, pero esa tampoco es la cuestión; es solo un punto de referencia. Y lo es porque muchas organizaciones tienen previsto crear muchas más aplicaciones. Por otro lado, están las organizaciones que están adoptando una arquitectura de microservicios y que no necesariamente están cambiando el número de aplicaciones, sino el número de «sistemas», por así decirlo, que necesitarán los servicios afines a las aplicaciones antes mencionados.

Bien. Imagine que una organización se plantea duplicar el número de aplicaciones que gestiona. Supongamos que empezó con 500 y que, de repente, va a tener 1000. Tendrá que aprovisionar, configurar y gestionar todas y cada una de las políticas. Para simplificar los cálculos, supongamos que cada aplicación solo necesita 2: una para el escalado y otra para la seguridad. Eso supone 2000 políticas de las que ocuparse. ¿Todo listo? Adelante.

Sí. El problema no es que el «hardware» de la red corporativa no pueda con ello. Al contrario, puede hacerlo precisamente porque es hardware diseñado específicamente para ese fin y, por tanto, tiene una capacidad muy superior a la de un servidor de propósito general. El problema radica en los procesos y el personal necesarios para llevarlo todo a cabo. No se trata solo del número de dispositivos necesarios, sino del número de políticas únicas (específicas de cada aplicación) que deben implementarse.

Y no solo hay que implementarlas, sino también actualizarlas. Dado que las políticas vinculadas a una aplicación se configuran específicamente para ella, es más probable que, cuando se actualice la aplicación o se introduzca una corrección, también sea necesario actualizar las políticas de los servicios asociados a dicha aplicación. Y como las organizaciones quieren realizar implementaciones con mayor frecuencia, bueno... es fácil imaginar que los responsables de la red corporativa se verían completamente desbordados.

Al otro lado de la barrera, en la red de aplicaciones, los equipos de desarrollo y operaciones están ansiosos. Ansiosos por entregar e implementar aplicaciones. Están preparados para utilizar sus nuevas competencias en automatización y orquestación para acelerar ese proceso.

Y así es, pues asumen la responsabilidad de cada vez más servicios vinculados a las aplicaciones y los incorporan a sus arquitecturas y procesos de despliegue. Gracias al creciente conocimiento de DevOps y a cierto impulso del sector propiciado por las SDN, casi todos los servicios de red disponen de API. Muchos otros cuentan con plantillas que se adaptan como un guante a las necesidades de los operadores que emplean un enfoque de «infraestructura como código» para gestionar y desplegar la infraestructura necesaria para dar soporte a las aplicaciones.

Por eso, cada vez aparecen más «servicios de aplicaciones» en la red de aplicaciones, desplazando hacia la aplicación el centro de gravedad de las TI empresariales.

Es una estrategia de escalabilidad empresarial y operativa. Es una forma de afrontar el rápido crecimiento de la cartera de aplicaciones sin contravenir la ley de Brooks al intentar resolver el problema aumentando la plantilla de los equipos de redes o aplicaciones. Es una forma de permitir que TI lance aplicaciones al mercado con mayor rapidez y frecuencia, sin los trastornos que supondría exigir de repente a los operadores de red que gestionen dos, tres o más veces el número de políticas que gestionan actualmente.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie