How Componentization of Applications Impacts Performance and Security
Back in the good old days, business could rely on the use of strategically deployed proxies to improve performance of applications. That's because traditional applications - monoliths and three-tier architectures - generally employed a single data path between the client and the server.
In simple terms, there was only one route taken for all content - whether static or dynamic, text-based or images. That meant an application delivery controller (proxy) could sit between them and, with the right one, optimize performance. This was - and still is, by the way - often achieved through the adjustment of various IP, TCP, and even HTTP buttons and knobs. We can see the use of these kinds of techniques through the deployment of application services like caching, compression, and content-specific acceleration techniques.
But modern applications are no longer self-reliant. They are now, according to Sonatype, mostly comprised (80-90%) of third-party (and increasingly open-source) components. You see this in the number of scripts and other injectable code found in web applications. Sometimes that script executes remotely and returns an image or an ad or other content such as web fonts and sprites. Other times the script itself is loaded at run-time and executes in the confines of the browser, like jQuery.
This is what is known as componentization - or atomization, if you prefer. It's the breaking down of applications into many smaller pieces. We call them components on the client-side, because they generally execute in the same space. On the server-side we increasingly call them microservices and deploy them in containers. In both cases, the impact is similar - we wind up with an unpredictable number of data paths that directly impact performance.
Basically, you have control over one data path - that comprises maybe 20% of your application. That means you have very little control over the user experience because you have very little control over performance.
That's also true for security - thanks for noticing. The thing is, we're rapidly learning to take advantage of client-side code techniques to improve security. That doesn't work as well with performance because most apps are either mobile or web, and neither really afford the opportunity or ability to muck with the network stack.
One of the ways to combat this problem is to reclaim control. The cool thing about reclaiming control is that you can also benefit from security side-effects.
WIN-WIN: REDUCE RISK and IMPROVE PERFORMANCE
If your apps are in the habit of dynamically loading components from external sites, stop it. Stop it now. This is just as much a security issue as it is performance. You are implicitly giving carte blanche to an externally sourced script to run within the context of your application. Trust me, a user isn't going to be able to distinguish between your components and the ones loaded externally in the event of a security breach. As we learned from the recent meltdown over the runc container vulnerability, the injection of malicious code into resources loaded from third-party registries or sites carries with it a security risk.
If it's a script, you are better off cloning and serving from your own infrastructure. You'll benefit from reducing risk by maintaining control and from being able to tweak knobs and buttons that improve performance for your users. That includes DNS, which has consistently been shown to have the biggest (often negative) impact on application performance. When you pull components from external sites, you're relying on their DNS infrastructure to perform up to expectations. Pulling components from your own sites can dramatically reduce the impact simply because the user's local DNS cache works for you.
Hosting scripts from your own site also empowers you to employ TCP optimizations or SSL/TLS offload or general app acceleration techniques to improve performance overall. It also affords the opportunity to perform security scans on those scripts to ensure there are no surprises hidden down deep.
Componentization is great for development and certainly aids in speeding up time to value. But it can have a negative impact on performance - and security. Be aware of the security and user satisfaction risks and what you can do to combat them.