by Jeff Pitsch

During my webinar on Layering, a question came up that I did not have time to delve into, mainly because it can become a ‘holy war’ amongst us all. The question, (or statement?): Why use layering (notice I say ‘layering’ and not ‘app layering’) if I have automated my image creation?

I want to address the phrasing of the question first because we need to make an important distinction here. As I address the question in this blog, I will be using the term ‘layering’ which means any layering product and ‘App Layering’ referring to Citrix App Layering. Why? As I discussed during the webinar, App Layering is, first and foremost, an image management product. It can do dynamic delivery of applications through Elastic Layering, but to get that you must use the image management side of it. Without an image built by App Layering, there is no Elastic Layering. This separates App Layering from the other products out there because they do not necessarily rely on a specific image (in other words, they do not, in any way, manage images) and are purposely built for the specific use case of dynamic delivery.

So, with that out of the way, I do want to address App Layering first. When asked the above question, this is the one product that, in my opinion, causes the confusion for the other layering products out there. This is because it does image management and that piece is required for elastic layers. I believe many people link this process in their minds to the other products, so they see it as black and white which, again my opinion, it is not.

If you already have an automated process, then yes, moving to App Layering may not be the best course of action for you. As with all technology though, it all depends on what you are looking for and want to do with it. If you want dynamic delivery of applications and cannot spend money on a third-party product, then it may make sense to move to App Layering. Unfortunately, there really is no formula or process to figure out which is best for you. Every environment is unique and just because one way makes sense in one place, does not mean it makes sense in another. At its simplest though, if you want Elastic Layers, you must move to App Layering.

With that out of the way, let us discuss the other products and why you may want to use them in conjunction with automated image builds.

Automated builds are a great way, if not the best way, to maintain images when it gets set up and configured correctly. Most arguments for using only automated builds revolve around ‘I can hit the go button and create 12 different new, fresh images with all the applications needed.’ You could even automate the deployment the images and then you simply must verify the deployment success. That is great, but is there anything more disruptive than an image update for end users? What if a problem occurs in an application that forces you to revert to the old image? Again, disruption. I understand there are ways of softening the disruption but in the end, if you have built a new image, you have also updated maybe the operating system and multiple other applications. That is all lost now and how does that affect the users that needed the updates in the other applications? You could do a new image build and just revert the one application, but that takes time and it may not be time you have.

Dynamic delivery would make reverting an application much simpler and easier and it does help cut down on the number of images maintained. I have seen companies, using automated builds, have upwards of 50 images that are maintained. Even with automating it all, that is a lot of images and that is not even the highest I have seen. Many of these images are needed for applications that are, for lack of better words, one offs either within a department or are cross department but are critical for the business. How many image builds could you eliminate if you took those applications completely out of the image and were delivered at login, machine boot, on demand or even certain triggers like time of day or month? Some products can even be set up to only allow access to an application if the user is on the company’s network versus coming in from outside or from a certain end point. Now, if one of these applications has an issue, it is extremely easy to revert to the previous version with minimal impact to the user and the other users who are sharing the image. 

There are also scenarios like a new application or application update needs to be deployed right away or removed right away. Again, all much less intrusive and much less time consuming than a new image build and deployment.

My belief is that automated images and layering, used together, deliver the best user and admin experience. I always like to keep my options open and many times I see advocates for automated builds dismiss technologies like layering without even testing or experiencing what they have to offer. Automated builds, while great, are not the end all, be all. No technology or process ever is, and if you aren’t continuously looking to improve the process or looking to see what other options are out there, you are doing yourself and your company a disservice.

Thanks all!

Jeff Pitsch
@JeffPitsch
https://www.JeffPitsch.com