Cómo afecta la componentización de las aplicaciones al rendimiento y la seguridad

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

En los viejos tiempos, las empresas podían recurrir al uso de proxies desplegados estratégicamente para mejorar el rendimiento de las aplicaciones. Esto se debía a que las aplicaciones tradicionales —monolitos y arquitecturas de tres niveles— solían utilizar una única ruta de datos entre el cliente y el servidor.

En pocas palabras, todo el contenido seguía una única ruta, ya fuera estático o dinámico, texto o imágenes. Esto permitía colocar entre ambos un controlador de entrega de aplicaciones (proxy) que, si era el adecuado, podía optimizar el rendimiento. Esto se conseguía —y, por cierto, se sigue consiguiendo— a menudo ajustando diversos parámetros de IP, TCP e incluso HTTP. Podemos observar el uso de este tipo de técnicas en la implementación de servicios de aplicaciones como el almacenamiento en caché, la compresión y las técnicas de aceleración específicas para cada tipo de contenido.

Pero las aplicaciones modernas ya no son autosuficientes. Ahora, según Sonatype, están compuestas en su mayoría (entre un 80 % y un 90 %) por componentes de terceros (y, cada vez más, de código abierto). Esto se refleja en la cantidad de scripts y otro código inyectable presente en las aplicaciones web. A veces, ese script se ejecuta de forma remota y devuelve una imagen, un anuncio u otro contenido, como fuentes web y sprites. Otras veces, el propio script se carga en tiempo de ejecución y se ejecuta dentro del navegador, como jQuery.

Esto es lo que se conoce como componentización —o atomización, si se prefiere—. Consiste en dividir las aplicaciones en muchas piezas más pequeñas. En el lado del cliente las llamamos componentes, porque generalmente se ejecutan en el mismo espacio. En el lado del servidor, cada vez es más habitual llamarlas microservicios y desplegarlas en contenedores. En ambos casos, el efecto es similar: acabamos teniendo un número impredecible de rutas de datos que afectan directamente al rendimiento.

Básicamente, solo tienes control sobre una ruta de datos, que quizá represente el 20 % de tu aplicación. Eso significa que tienes muy poco control sobre la experiencia de usuario, porque apenas puedes controlar el rendimiento.

Lo mismo ocurre con la seguridad; gracias por señalarlo. La cuestión es que estamos aprendiendo rápidamente a aprovechar las técnicas de código del lado del cliente para mejorar la seguridad. Esto no funciona tan bien en lo que respecta al rendimiento, porque la mayoría de las aplicaciones son móviles o web, y ninguna de las dos ofrece realmente la posibilidad ni la capacidad de trastear con la pila de red.

Una de las formas de combatir este problema es recuperar el control. Lo bueno de recuperar el control es que también puedes beneficiarte de las ventajas adicionales en materia de seguridad.

TODOS GANAN: REDUZCA EL RIESGO Y MEJORE EL RENDIMIENTO

Si tus aplicaciones suelen cargar dinámicamente componentes desde sitios externos, deja de hacerlo. Déjalo ya. Es tanto un problema de seguridad como de rendimiento. Implícitamente, estás dando carta blanca a un script de origen externo para que se ejecute en el contexto de tu aplicación. Créeme: en caso de una brecha de seguridad, un usuario no podrá distinguir entre tus componentes y los cargados externamente. Como aprendimos de la reciente crisis provocada por la vulnerabilidad del contenedor runc, la inyección de código malicioso en recursos cargados desde registros o sitios de terceros conlleva un riesgo de seguridad.

Si se trata de un script, es mejor clonarlo y servirlo desde tu propia infraestructura. Mantener el control te permitirá reducir los riesgos y ajustar distintos parámetros para mejorar el rendimiento de cara a tus usuarios. Esto incluye el DNS, que ha demostrado sistemáticamente ser el factor con mayor impacto —a menudo negativo— en el rendimiento de las aplicaciones. Cuando obtienes componentes de sitios externos, dependes de que su infraestructura DNS rinda según lo esperado. Obtener los componentes de tus propios sitios puede reducir drásticamente ese impacto, simplemente porque la caché DNS local del usuario juega a tu favor.

Alojar los scripts en su propio sitio también le permite aplicar optimizaciones de TCP, descargar el procesamiento de SSL/TLS o utilizar técnicas generales de aceleración de aplicaciones para mejorar el rendimiento global. Asimismo, le brinda la oportunidad de realizar análisis de seguridad de esos scripts para asegurarse de que no haya sorpresas ocultas en su interior.

La componentización es excelente para el desarrollo y, sin duda, ayuda a acelerar la obtención de valor. Sin embargo, puede afectar negativamente al rendimiento y a la seguridad. Tenga presentes los riesgos para la seguridad y la satisfacción de los usuarios, así como las medidas que puede adoptar para mitigarlos.

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