Two videos – one using a Microsoft RDSH host running on VMware vSphere… and the other demoing the “Switch User” feature for kiosks in environments like health care.
Note: In the video, I’m running our software in vSphere VM because it made it super easy to show the “Switch User” feature – it’s also a great illustration of how Droplet containers run on physical or virtual environments in equal measure.
Okay, I’d admit that was a complete tease as a title, design purely to grab your attention and suck you in. Please forgive me. It should really be Droplet-as-a-Windows-Service (DaaWS)
One new thing about the 2.0 release is to “modes” of operation. You can run the Droplet container as our standard per-user application or as a Windows computer service. If the per-user application the user starts the Droplet container manually or else the administrator sets the software to run using the flags droplet.exe launch –minimised.
(Yes, that’s minimised with s, not a z! Just like virtualisation is spelt with is S not a Z :p)
This per-user mode of operation works best for containerised (with S!) apps that the user only needs occasionally such as once a day, or every other day or once a week/month – and where you want to maintain the “each user gets their personal container” model. From a resource perspective, the droplet.exe only consumes memory and CPU allocations when needed, and when the user is finished, they can shut down both the application and container. This model is commonly used by customers who want to deliver a containerized (okay with a zed this time just to keep the Yanks happy :p) app on an as-needed basis for a subset of users. The start-up time of the container is very good (around 30-the 40s mark) and so for many users, that’s acceptable.
Alternatively, our software can be configured to run a Windows computer service – which means the container is started when the Windows PC is started and is always running silently in the background. In the is case one Droplet container file services the needs of many end-users. It means the container is ready and waiting to serve up containerized apps as soon as the user logins to the Windows PC. In this model, our “client” application becomes just that – an “agent” that sits in the System Tray waiting for the user to run the Droplet Seamless App.
This was the first model I developed for Droplet Seamless Apps back when it wasn’t a product, but an in-house skunkworks. So, it’s been around in our labs for more than a year as we tested and validated the approach with our core customers.
So, there are a couple of core use cases.
Firstly, for customers who want to run their containerized app most of the time. In this case, whether the app is legacy or modern, it’s a key line-of-business app that is used by the vast majority of users, the vast majority of the time.
Secondly, we have many customers who are using the “Switch User” feature in Windows 10 PCs. A good example of that is health care (or own heroic NHS for example) wherein a given shift 4-6 different members of staff use the same physical machine and want to quickly toggle between different uses in the same kind of kiosk-style mode. Our container in this model allows for multiple users to access the same Droplet container on the same Windows PC.
Finally, the service-mode is ideal for Microsoft Remote Desktop Session Hosts (RDSH) on its own, or augmented by VMware Application Pools or Citrix Virtual Apps. This means one container can service many contexts on the server. For this model, we leverage our 64-bit container which allows 1-4 CPU cores to be allocated. It also supports allocating as little as 2GB memory up to a maximum of 192GB. This means the System Administrator can allocate a subset of resources to the container based on resources need to support the concurrency needed. This is a much more efficient model for running the container – it’s more efficient from a storage, CPU, and memory allocation perspective – than multiple users running multiple containers in the context of their remote user-session