Originally posted at http://www.robbeekmans.net/uncategorized/liquidware-labs-flex-apps-micro/
Liquidware labs FlexApp – Microisolation
Liquidware labs recently launched a new feature for their FlexApp product, micro isolation it is called. Micro isolation in short is away to differentiate between applications and file requests. In this article I’ll tell you a bit more on the why and how.
Quick history lesson
I’m an old guy born in the summer of ’69, so when I started in IT things were not that smoothly and applications used to have conflicts with other applications. fights about files they want to access, files with different version. Those days were called the DLL hell and boy did we have issues at that time.
To overcome the issues with the DLL hell Microsoft created the WinSxS folder. Wondering what the WinSxS folder is all about? Short answer, it is your operating system. All files you see that make up Windows and files that you install with installing applications are stored there and projected somewhere else. There is only one location where one version of the application is stored and that in the WinSxS folder also called the component store.
Installing a new version of a file resulted in the file being added to the component store but not to the deletion of the old file. This was causing another issue, the WinSxS folder was bloated. You all been there wondering why that folder was so huge.
FlexApp micro isolation
To make sure your WinSxS folder doesn’t get bloated we will handle files and applications differently. With FlexApp you have the ability to layer applications, you can layer multiple applications in one layer or create one application per layer.
Let’s focus on one application per layer.
Let’s say we have appstack1 and appstack2, both one application, both application requiring the same DLL but a different version.
However with micro isolation the filter driver sees and intercepts the starting of the application. FlexApp sees that the application is requesting access to that one DLL and will redirect the application to access the DLL within it’s own layer.
This technique will make sure the conflicts don’t occur, which is pretty neat.
What other issues is it solving?
When you have multiple applications in a layer you might have a challenge updating applications in a layer. Updating one application could break another application, you won’t know up front if a file will be replaced.
With one application per layer you won’t have that issue, you can update as you want and conflicts will be resolved by a neat filter driver.
One issue I see there is that if you have too many layers you won’t be able to connect them or things might get slow. I think it will need time to test this but it looks interesting to say the least.
Installing a set of applications in one layer and some other freaky ones in another is a scenario that would work. the filter driver will work out the conflicts and redirect where needed. Think about application suites that connect to internal application that are not standard. you don’t want those together in one layer.
I think it’s a good addition to the product, they are working hard to make the product more and more mature. Keep an eye on them, they are serious business. Like said before, need a demo