Or at least that was the question today.
Those who know me know that I've been a fan of the idea of application layering for a long while. Back in 2014 I included a section on layering in my 90 minute talk at GTC on desktop virtualization basics.
Back then the layering technology and players were all independent companies mostly developing their products in cross platform manners, and regardless of who's approach you liked best it was technology you spent extra money to get. So if you spent the money, you were certainly going to use the tech. And if you hadn't spent the money you were asking if the value you'd derive was worth the dollars you were going to spend.
Fast forward to today, in late 2017. I'm revisiting a customer I'd done a deployment for earlier in the year. They've since hired a new VDI Desktop admin who's currently experiencing layering for the first time. The new guy pulled me aside and asked a question I'd honestly not given too much thought to.
"I need to turn up a group of applications using RDS quickly because I need to retire the old RDS farm. Should I just build them manually, or do I really need to go through the layering process?"
The question caused me to pause. Assuming that I own the layering technology, when would I recommend against using it? The new guy had a point, turning up new applications as layers does in fact take more time than just manually installing them into an image, which realistically takes more time than manually installing them onto a single RDS session host.
The question has stuck with me throughout the day. And I keep thinking about how to address a response. Especially in a world where layering technology is bundled into the mainstream desktop virtualization suites rather than being an extra cost item. Here's what I've come up with.
There is a point where single image management is more effort than it's worth. Let's face it, if I'm managing a pool of one VM then using a linked clone approach really doesn't buy me much. If it's a pool of 2 VMs then maybe Composer or MCS has something to offer but it might be as easy to just right click "clone." If the pool is 3 or 4 VM's then the single image starts to have more value to offset it's complexity. At some point in there the scales tip; and that exact point may vary with the complexity of the single management solution. I bet if you have more than about 5 identical VMs in play single image is going to pay off.
I think there is a similar story for app layering. A question of how many places you're going to be able to use the layer, how often it's going to be updated, and how much variance exists in your system. If you effectively only have one "gold image" then it may be simpler to just maintain that image rather than deconstructing it into multiple layers. If you have two "gold images" which overlap by say 60% then you might benefit from only having to update the 60% of the apps once rather than maintaining them twice. 3 or 4 "images" and the benefits of layering become stronger.
It's important to note here that I'm thinking more in terms of "machine assigned" or "statically assigned" layers here. Layers that are applied to a particular VM all the time and not dependent upon which users are connecting to the system. But the conclusion I've come to is that layering here makes sense when I have multiple groups of machines which have similar but different base configurations for each group. If I can do it all with only one image then layers probably don't make sense.
Speaking of layers which are not static - the idea of user assigned layers (or "elastic layers) is another topic all together. Nearly by definition this is a discussion of having multiple unique things happening since these layers only make sense if you have applications which will be used only by a subset of the users who will use a particular group of machines. This is all about ensuring that user A gets a different set of layers than user B. If that isn't the case for the solution you're building, then this approach probably isn't the right solution. User assigned layers can do nothing but slow down the login process and application execution. At best the performance hit is small, but it can't be less than zero. And generally the performance hit is greater as more apps are assigned this way (more independent layers). So use them sparingly.
So the moral of the story - should you layer or not layer? The answer is it depends. How much re-use will you get from doing it and how much increased overhead (time, effort, performance, resources) does it consume? Maybe it's better to let the free goodies in the box remain shelfware.
