Amazon AppStream works by streaming (what’s in a name) applications from the AWS Cloud down to a user’s device – never mind the type. The concept is simple and according to Amazon it simplifies application management, improves security, and reduces costs by moving company’s applications from their users’ physical devices to the AWS Cloud. I would agree, except for the management part.
Remoting applications, never mind if they are ‘streamed’ or ‘published’ isn’t a new concept. In fact, it’s very similar to what we know from Citrix, for example. Applications are installed onto a base-image, which runs on a virtual (or physical) machine. The VM (I’ll us a virtual machine in this example) has a certain amount of RAM, CPU power and so on. If we want to support graphic accelerated workloads we add a GPU to mix etc. I’m not telling you anything new here.
The pain of image and application management
Managing and maintaining a, or multiple images with dozens of applications installed has never been an easy task. Of course, while I’m using Citrix Virtual Apps and Desktops as an example, this applies to Microsoft, VMware and all others you can think of.
This is mainly why we are interested in using technologies like application layering and/or application virtualization. These technologies create an abstraction layer of the application, which can be ‘attached’ to the Operating System on-demand. Applications can then be updated or altered in any way you like without interrupting your users. Again, business as usual for the past 5+ years or so.
By the way, offering applications in a published/streaming manner will also be one of the main use-cases of WVD, once it’s available world-wide. At least that’s my expectation. Read here how Liquidware has partnered with Microsoft to further enhance the WVD user experience.
How AWS AppStream works
AppStream works in sort of the same way. Though, it is (natively) build on AWS Cloud services which offer multiple advantages, like auto scaling, for example and various other ‘policies’ for you to configure. Something that would be hard to achieve on-premises. However, the way AppStream works when it comes to installing and configuring applications to stream to your users isn’t that different from what I described above.
AppStream work with so-called ‘Fleets’. A Fleet consists out of an ‘image’, built with the AppStream ‘image builder’, and one or multiple ‘instance(s)’ (VM’s, basically), where your image(s) will be launched from, eventually streaming applications to your users. One or more applications get installed onto an image. Images can be custom build, or you can choose from a variety of pre-defined ones, optimized for compute, memory, graphics etc.
After configuring your network, user session settings (on-demand, always on, max session duration and timeout), you set the minimum and maximum capacity of streaming instances (VM’s), configure your scale-out, and scale-in policies and you are good to go. All fairly easy and straightforward to set up. Of course, assigning users, taking care of authentication and things like that is also a piece of the puzzle, but beyond the scope of this article.
New technology, same (management) challenges
What happens when an application needs to be updated? Right, you go into the image builder mentioned above, open up the image, make your changes, save, publish, inform your users etc. This will need to done outside of office hours because all applications will be installed directly into your AppStream images – meaning, no abstraction or separation between the two.
Depending on the amount of applications and images you have, and the number of applications per image this can become a very labor-intensive task. So, while we take advantage of the Cloud native part, from an application management perspective not much has changed. That’s why AWS and Liquidware joined forces, as they have done multiple times in the past and created AppStream 2.0 with FlexApp application layering integration.
How Liquidware (FlexApp) helps
AppStream 2.0 now has a new feature called “Dynamic Apps” that allows 3rd party tools to integrate with the platform. This means that instead of installing applications directly into an image, as explained above, we can now integrate FlexApp application layers into an AppStream image. When applications are installed this way, again using the image builder, all bits and bytes will be redirected to a virtual disk (VHD), making them portable.
This is pure Liquidware FlexApp as we’ve come to know the product over the past few years, but now directly integrated within AWS AppStream.
When a user logs into his of her AppStream environment all application types will be displayed, the ‘standard’ AppStream applications together with any FlexApp application layers they might have. From now on, Administrators can (again) manage their applications, or at least the ones they want in a more flexible manner. One of the main advantages of using Liquidware’s FlexApp.
Other related news
Here I’d like to quote Ray Dusseault (Director of Application Strategy, Product Manager, Product Marketing Manager, at Liquidware) “Liquidware is excited to announce that we have created a new FlexApp Packaging Console shared image, available within AppStream 2.0. This new feature will provide an efficient, scalable, repeatable FlexApp packaging environment that contains all run times, Liquidware customizations and overall best practices guidance for enterprise use right out of the gate.”
If it’s documentation you are looking for, they’ve got you covered, see the list below:
- FlexApp and AppStream Landing page
- FlexApp and AppStream Working Together video
- Implementation Best Practices for FlexApp and AppStream video
- ProfileUnity and FlexApp 6.8 version release overview video
- AppStream 2.0 and FlexApp QuickStart Guide
- Amazon AppStream Info
If you would like to know more about any of the above, contact Liquidware at: [email protected] or [email protected]
Later this month they will be at Citrix Synergy as well, you’ll find them at booth #401
