Back when I started with Droplet (it will be two years in Sept 2021!)  we had quite a simple product. Back then we just had two container types and a limited number of places where we supported them. Since then we have had many different container types running both in physical, virtual, and cloud environments. Additionally, there’s been an explosion of features and possible configuration options. I’m pleased to say that 100% of this development has been customer and demand-led. That’s how I feel it should be, and how it should remain. I’ve seen software companies go adrift chasing featurism. The endless development of new features simply to have something “new” to bring to customers, which lacks a strong, compelling use case driven by customer need.

Most software companies address this increased “flexibility” (what they mean is complexity!) by series of tables or matrix. I find these a turn-off mainly because they are not focused on the organization and reduces a product to series to “tick boxes”. I think they are difficult to navigate, often confusing in their own right – and don’t simplify the story in the way they intend. I prefer to have series of scenarios that are firmly rooted in a real-world scenario which makes it much easier for organizations, partners, and our staff to ask the right questions, and save in the process customers bags of time and energy – especially now we have 4 core types of container – with two sub-types within each category. Of course, even a scenario approach has its limitations – in that few organizations fit into a “one size fits all” – so multiple scenarios can and do exist – which lends itself to a more “blended” solution. The other thing I don’t like about matrices is they lead to drag-race comparisons between vendors based on a feature list – how often is it the case that a missing X or present X is latched onto as a deal-breaker – only to find that feature never gets enabled once in production!

So let’s look at some common scenarios and outline what my recommendations would be for the customer…

Scenario 1: Legacy Apps on Physical Hardware

This is probably our most common scenario – although I would say a significant minority of customers are using our technology to deliver a modern application stack.

Whether you’re running on Microsoft Windows 10, Apple macOS, or Google Chromebook I would recommend our DCI-M7x32 container leveraging the native hardware acceleration provided by the local OS. In the case of Microsoft Windows 10 that would be WHPX, Apple macOS that would be HVF, or on Google Chromebook those would be the KVM extensions. The DCI-M7x32 container is a good all-rounder for both legacy, and some modern applications too – and is probably our most popular container type.

Scenario 2: Legacy Apps On-premises VDI environments

We support hardware acceleration in VDI environments where Windows 10 is the primary OS running inside the VM. For on-premises environments like VMware vSphere, the Intel-VT or AMD-V attributes need to be exposed to the VM. For on-premises environments, we would recommend using Windows 10 Version 1909 or higher. Assuming you have all your ducks-in-a-row, then we would recommend our DCI-M7x32. In short, physical and virtual environments are treated equally. In case you don’t know hardware acceleration to the VM is very easy to enable on the properties of the CPU in VMware vSphere:

 

Scenario 3: Legacy Apps on Multi-Session environments

In this case, a server OS is enabled Microsoft Remote Desktop Session Host (aka Terminal Services) and multiple users connect either to a shared desktop or shared application infrastructure. In this scenario, we would recommend our multi-session container which is 64-bit enabled – the DCI-M7x64. Although this container type doesn’t currently support hardware acceleration it does provide up to 4-core and 192GB of memory. So that offers fantastic scalability – where one container image is accessible to multiple users – offering the same concurrency model as the RDSH host within it runs.

In Microsoft WVD Whilst E-series-v4 and D-series-v4 instances do pass hardware acceleration the benefits are limited to a power-user style environment where there is a 1-2-1 relationship between the user and desktop. In our literature, we refer to the model offering as the “Flexible Model”. As each user gets their own personal container accelerated by Intel-VT. In this case, the DCI-M7x32 container is the best type to go with.

In environments like Microsoft WVD we recommend the same configuration as we would with a RDSH – essentially Windows 10 Multi-session offers the same multi-user functionality RDS enabled Windows 2016/2019 server. The DCI-M7x64 container which multi-session enabled offers greater consolidation and concurrency ratios.  Laying the technical issues aside for a moment, economically, the utility model seems to allow wins as a multi-session environment is always going to offer consolidation and concurrency benefits. In our literature, we refer to this as the “Scalable Model” as this most cost-effective method of serving up containerized apps to multiple users. There’s an implicit lack of scalability for a multi-session container on a 32-bit kernel. Since that kernel is limited to using 4GB of memory – it means once you have around 9-10 users connected into the container – you run the risk of ‘out of memory’ conditions and swap activity. On an x64 container that isn’t a problem as the maximum amount of configurable RAM is 192GB.

Scenario 4: Modern Apps on Physical or Virtual Hardware

Frequently we have organizations wanting to run modern apps of Windows 10 rather than installing those apps directly to the OS. The reason for this can be multiple – but often it’s about wanting to decouple the apps from the OS to allow for portability, security and able ingest Windows 10 updates without fearing they will clobber the delicate blend applications. Another motivation can be trying to support applications across other platforms like Apple macOS or Google Chromebook. As the Droplet image is portable across all three platforms without modification it’s often the best approach.

In a pure Windows 10 environment – whether that was physical or virtual we would recommend the DCI-M8x32 or DCI-M8x64 container with hardware acceleration – the same container type would be used on the Google Chromebook. The Apple macOS on the other hand would benefit from the use of our DCI-M8x32 which we have been running for some time – which gives excellent performance. We do have a DCI-10×64 container type but you do need that with physical hardware (currently it’s simply too resource-intensive for a virtual/cloud environment – although that will change with improvements in software and hardware). We tend to reserve the DCI-M10x64 container for high-end devices (8-16GB, SSD/Nvme) as this offsets the payload associated with this generation of the kernel.

Scenario 5: Really Jurassic Apps on Physical or Virtual

Occasionally, we come across an organization with really old applications. For these organizations I recommend, they give the DCI-M7 container type a try, as often we find even really old applications will install and run inside our container runtime. If that’s not the case then I would recommend the DCI-X container type (hint: X refers to cross-compatibility). It offers the same “Droplet Seamless App” experience but contains an old set of application binaries and frameworks, often missing or depreciated in the DCI-M7 generation.