Cómo la componentización de las aplicaciones impacta el rendimiento y la seguridad
En los viejos tiempos, las empresas podían confiar en el uso de servidores proxy implementados estratégicamente para mejorar el rendimiento de las aplicações. Esto se debe a que las aplicações tradicionales (monolitos y arquitecturas de tres niveles) generalmente empleaban una única ruta de datos entre el cliente y el servidor.
En términos simples, solo se tomó una ruta para todo el contenido, ya sea estático o dinámico, basado en texto o imágenes. Eso significaba que un controlador de entrega de aplicação (proxy) podría ubicarse entre ellos y, con el correcto, optimizar el rendimiento. Esto se logró (y todavía se logra, por cierto) a menudo mediante el ajuste de varios botones y perillas de IP, TCP e incluso HTTP. Podemos ver el uso de este tipo de técnicas a través de la implementación de servicios de aplicação como almacenamiento en caché, compresión y técnicas de aceleración de contenido específico.
Pero las aplicações modernas ya no son autosuficientes. Según Sonatype , en la actualidad se componen en su mayoría (80-90%) de componentes de terceros (y cada vez más, de código abierto). Puedes ver esto en la cantidad de scripts y otros códigos inyectables que se encuentran en las aplicações 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 script en sí se carga en tiempo de ejecución y se ejecuta dentro de los límites del navegador, como jQuery.
Esto es lo que se conoce como componentización, o atomización, si lo prefieres. Es la división de aplicações en muchos fragmentos más pequeños. Los llamamos componentes del lado del cliente, porque generalmente se ejecutan en el mismo espacio. En el lado del servidor, cada vez más los llamamos microservicios y los implementamos en contenedores. En ambos casos, el impacto es similar: terminamos con una cantidad impredecible de rutas de datos que impactan directamente en el rendimiento.
Básicamente, usted tiene control sobre una ruta de datos , que comprende quizás el 20% de su aplicação. Esto significa que tienes muy poco control sobre la experiencia del usuario porque tienes muy poco control sobre el rendimiento.
Esto también es válido para la seguridad: gracias por notarlo. El problema 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 con el rendimiento porque la mayoría de las aplicaciones son móviles o web, y ninguna de ellas realmente ofrece la oportunidad o la capacidad de modificar 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 efectos secundarios de seguridad.
GANAR-GANAR: REDUCIR EL RIESGO Y MEJORAR EL RENDIMIENTO
Si sus aplicaciones tienen el hábito de cargar dinámicamente componentes desde sitios externos, deténgalo. Deténgalo ahora. Esto 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 dentro del contexto de tu aplicação. Créame, un usuario no podrá distinguir entre sus componentes y los cargados externamente en caso de una violación de seguridad. Como aprendimos a partir del reciente colapso 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 su propia infraestructura. Se beneficiará al reducir el riesgo manteniendo el control y al poder ajustar perillas y botones que mejoran el rendimiento para sus usuarios. Esto incluye DNS, que ha demostrado constantemente tener el mayor impacto (a menudo negativo) en el rendimiento de las aplicação . Cuando extraes componentes de sitios externos, confías en que su infraestructura de DNS funcione según las expectativas. Extraer componentes de sus propios sitios puede reducir drásticamente el impacto simplemente porque el caché DNS local del usuario trabaja para usted.
Alojar scripts desde su propio sitio también le permite emplear optimizaciones TCP o descarga SSL/TLS o técnicas generales de aceleración de aplicaciones para mejorar el rendimiento general. También brinda la oportunidad de realizar análisis de seguridad en esos scripts para garantizar que no haya sorpresas ocultas en lo profundo.
La componentización es excelente para el desarrollo y ciertamente ayuda a acelerar el tiempo para obtener valor. Pero puede tener un impacto negativo en el rendimiento y la seguridad. Sea consciente de los riesgos de seguridad y satisfacción del usuario y de lo que puede hacer para combatirlos.