Dealing with MKL DLLs on an in-house server farm

[KKats1]

This is an MKL part of my general question, that was helpfully answered in the compiler forum but only regarding the runtime DLLs (https://software.intel.com/en-us/forums/topic/535178). How to solve the MKL part the best way I do not really know.

We are a SaaS, and I will be using a DLL build against the MKL in our server farm of Windows servers. In the farm, an application is first deployed, such that all binaries are on the network location accessible to all servers. Then a scheduler may run instances of the application on any server that currently has capacity. A mishmash of servers ranges from Gainestowns to Haswells. At any time, there may be 500 application installed in the farm. The applications are similar, but may be build by different versions of tool. Some of them are new, other have not been rebuilt for a year.

A DLL an application depends on may be deployed with the application, or may be installed as an .msi system-wide package. The latter is the case with Microsoft runtimes, required by MSVC-compiled binaries. Now I see a few options of deploying the MKL:

1. Deploy the DLLs with the application package, This is not an ideal option to me, as a typical application is less than 100MB in size, and the sum of MKL DLLs is about 150MB for ia32'. So increasing the deployment size by the factor of  2.5 increase storage, network traffic and scheduler load, and opens a whole new can of fresh worms.

2. Compile MKL statically. Well, my DLL bloats up to 10MB in size, which is pretty affordable. Still, not the best solution because the copy of read-only MKL code sections will be loaded for every instance, and not shared by the system. This is mostly the case in the previous item as well.

3. Deploy MKL as we deploy e. g. Visual C runtimes. Run an msi, and there it is for everyone to use! This would be almost ideal. What I am worrying about is what happens if there is a new code built against a newer MKL. If we, for example, upgrade this common, per-server MKL install on a server from e. g. version 10 to 11, will it kill the apps built against version 10? In other words, are MKL releases backward compatible in the DLL form?

4, Super duper ideal solution: deploy MKL into the system side-by-side facility (SxS), so each application can request its own version of DLLs.  That would be ideal. Now tell me it is possible please! : )

Any thoughts and ideas are gladly accepted.