I have seen a lot of discussion on the subject of layering of software images to deliver virtualized client computing. There are some interesting opportunities here but also a number of serious potential issues. This is too big an area for a single blog post so I am going to look at this over a number of post in the coming weeks.
There are number of different ways the word ‘layers’ is used in client computing. Firstly, when we think of our software stack we unsurprisingly think of the layers that make up that stack. Those layers are typically operating system, applications and user environment. We then think about how we manage those layers, either as the complete unwieldy stack or individually. As such we are thinking about layers as a handy shortcut for what we want to manage individually.
Another way that the word ‘layers’ is being used is as a way of splitting the stack into a large number of separate layers. A number of small vendors are launching early stage products to try and deliver solutions based on a layer per application with those layers being delivered selectively depending on the user. The problem here is that each of the layers then needs to be managed separately including the impact of every combination of layers. Many of the organizations I talk to have thousands of applications in use across the business, that means thousands of layers and a huge combinatorial problem.
The change between the two uses of the word ‘layers’ is dramatic: In one case we are referring to three layers that we want to manage individually in the other case attempting to manage thousands of layers in a way that may well prove to be impossible. As I think of managing all those layers I am reminded of the mess that usually results from my attempts at eating a Napoleon, also known to the French as a ‘Mille Feuille’ – thousand layers.