I’m a reformed Linux hippy. Back in my college days, I flirted with the open source life. This was spurred by a combination principal and economics. “Free as in speech” is an evocative message to an impressionable twenty-something. And “free as in beer” is a sentiment that definitely resonated with me, as I was mostly using cobbled together PCs and didn’t want to worry about Windows licenses.
But since we perpetually live in the year before the year of Linux on the Desktop, it was always an experience defined by compromise. Even running relatively refined experiences like Ubuntu or Mint, getting things done often required punting back the a CLI (and my 6-month sojourn with Arch Linux left me very comfortable reading man files and documentation). To be honest, I ended up missing the software ecosystem that comes with Windows. I’ve never been a fan of the Windows experience as an OS, but there’s no denying it offers a wealth of software experiences
Enter Droplet Computing
This is where I have to say “there’s got to be a better way!” Well, Droplet Computing recently came out of stealth with a pretty ambitious solution for this issue. Consider what your options are for running a Windows app on another OS. You run a virtual machine, which would still require a license and come with performance and efficiency penalties. You could try to get WINE to work, which has made remarkable strides in usability, but is still far from easy.
Droplet’s solution is the Universal Droplet Container. In concept this isn’t any different from other containers; it bundles up an application with just the dependencies it needs to run, instead of the whole OS stack. This is all run in any modern web browser, and is built using WebAssembly to optimize performance. Droplet claims about a 10% performance drop-off from a native app in C versus one running in their containerized browser environment. Droplet actually prefers to operate this container with a Linux kernel, using WINE running in another container to run Windows apps. I’m still curious if this will cause any compatibility issues, WINE is far from a comprehensive runtime. But if I have to use WINE, I’d rather have a company like Droplet be responsible for it than myself or my IT team.
This of course isn’t limited to just running Windows apps on Linux. Where this could really come into its own is running legacy, but still production capable apps, that require an older version of Windows on virtually any OS. In their Cloud Field Day launch presentation, they specifically highlighted a MRI machine that communicates through a legacy Windows app. But one doesn’t need much imagination to think of a spate of old medical, industrial, and financial applications that businesses depend on, and require ancient hardware to operate.
Droplet Computing Company Introduction with Steve Horne from Stephen Foskett on Vimeo.
By using a containerized approach, Droplet opens the door to architectural independence for applications as well. They’re able to run x86 apps on ARM systems, provided it can run a browser supporting Web Assembly. Unfortunately right now you can’t go in the other direction, but I have to image that’s in development.
The Devil’s In The Details
There still a lot from Droplet’s launch that I need clarification on. For one, I’m not sure how application deployment or packaging is handled. Droplet showed a demo running a Windows text editor and an old version of Excel in a browser (pre-ribbon, those were the days). This is fine, but what interests me is how an organization gets to that point. We do know that these applications can be run off of a server, or locally on a given machine. But Droplet has to be involved in packaging these apps within their Universal Container. So does the .EXE get sent to Droplet, who then delivers the containerized app? Is there any way to get a license from Droplet to do this locally? How is their pricing for this handled?
The other item that came up in their launch is security. If you’re running older production apps, odds are they’ve gone years, if not decades, without a patch. These are potential security vulnerabilities an organization will have to account for. If they were going to be running this software on a Windows NT install anyway, Droplet isn’t making the security posture any worse. And there is the argument that modern browsers do a good job of sandboxing applications.
To be clear, organizations still need to have difficult discussions about these older production applications. They need to weigh the utility of these mission critical apps against unpatched security issues and need for legacy infrastructure. Droplet’s browser based containers allow organizations to largely mitigate the latter concern, and doesn’t exacerbate the former. But Droplet doesn’t solve the underlying issue.
This is Cool
I still need to play with an application using Droplet’s technology before I can pass any kind of definitive judgement. But there’s something undeniably fun about this entire conceit. Conceptually, this is a remarkably easy concept to wrap your head around, and I’m surprised that there isn’t much immediate competition for Droplet to worry about. Then again, Droplet has been working getting this tech ready for launch for several years, so while an easy concept to grasp, there seems to be a lot going on under the hood.
I’m excited to get some hands on time and see how it performs in the real world. Selfishly I wonder if this has any applications for old PC games. I could see a company like Good Old Games doing some interesting streaming options with Droplet’s containers.
I’m honestly not sure what Droplet’s business model will be going forward. But I have to admit that the tech is cool.
