Will address a few points here and work my way down the comment thread. Unfortunately a lot of misinformation/misunderstanding in the thread.
> - Docker provides full namespace isolation between apps, another app on the same system won't affect your app. In Thinapp and others, this isn't 100% the case
Spoon provides full namespace isolation, including named kernel object segregation. When running in the containerization system, it is enabled by default and allows most applications to run independently of software installed on the host device.
> - Docker provides network isolation. Each app gets it's own private network stack this eliminates port collisions, etc. This is not the case for Thinapp, etc.
Spoon containers provide network isolation, and each container has its own configurable network stack. TCP and UDP packets can be rerouted between containers, ports, and/or the host device. Spoon also provides a built-in virtual DNS service to simplify name resolution within containers.
Sample (from the Tour off the home page):
# Launch a WordPress server, block external network connectivity
> spoon run -d --name=web --route-block=tcp,udp wordpress
# Connect a Firefox browser instance to the WordPress server and
# map the domain awesome.com to the server container's port 8080
> spoon run --link=web:awesome.com firefox http://awesome.com:8080
> - OS comparability is not assured, you still need to test your app on various OS's to make sure it works compared to Docker.
Still true to some extent, though Spoon has come a long way in solving this. Internally we have an inter-platform mediation layer that solves many of these issues without special work from the user. And the comparison to Docker isn't totally valid -- will Docker images work when moved between different variants of Linux? Between different hardware platforms? I'm not a Linux expert, but I'd guess you'll encounter many of the same kinds of problems (worse?) that Windows users have when moving between different flavors of Windows.
> If you are running your app inside of a clean VM on amazon, you don't care as much about isolation of namespaces, filesystem, and network - so these solutions might be viable.
Not necessarily. This is true for server applications, but untrue for cloud-hosted desktops (Azure RemoteApp, Amazon WorkSpaces, etc). In fact, it is especially problematic in the latter case since many desktop applications don't handle multi-tenancy properly at all. We called out this use case in the announcement.
> Some other comments state this is the same as VMs, it's not.
Thank you! I think there are actually a couple points of confusion:
First, there are many types of "virtualization", essentially depending on where on the execution stack the "real" vs "virtual" resource lives -- hardware (ICE), OS (what most people here are calling "VMs"), application (Spoon, App-V, ThinApp), abstract (Java VM, .NET). As Jonathan observes, Spoon VM is an application virtualization engine. It lives on top of a base OS and has very low startup times and performance overhead -- of the same order of magnitude as LXC.
Second, while Spoon's container system is built on top of Spoon VM, it is not the same thing as Spoon VM. The Windows kernel does not have an analog to LXC, so we have to provide one. This is the role played by Spoon VM. Put another way, Spoon VM fills the same role on Windows as LXC does on Linux. And in fact, LXC is in a sense a "built-in" app virtualization engine. The Spoon container implementation is analogous to Docker, providing a command-line management interface, storage system, commit points, network virtualization, scripting, hub, and so on. (In fact, there is even more to this since Spoon VM is more expressive than LXC and has to be configured to behave in specific ways to implement containerization. But this is a long and separate topic.)
So for absolute clarity, when you run a Spoon container, it is (i) running on top of the host device base OS, not running a distinct copy of an OS; (ii) has the same magnitude performance overhead as Docker+LXC, e.g. very rapid start/restart times, low incremental memory/CPU consumption, can run dozens of containers on a single box, etc.
> Anyway - Spoon's announcement doesn't go into any detail on what is new relating to what they are providing,
Untrue. The announcement specifically calls out the ability to run isolated container sessions, the container hub, network virtualization, state capture and reversion, new command-line and scripting interfaces, continuation, and -- very notably for current App-V and ThinApp users -- the ability to run installs within containers, eliminating the need for "sequencintg" (App-V), "setup capture" (ThinApp), or "snapshotting" (Spoon Studio). You better than anyone would immediately appreciate the significance of that capability.
Specific examples of all of the above are readily available in the Tour link on the home page (https://spoon.net/docs/getting-started/spoon-tour).
Better yet, stop reading this and go try it yourself. We have a little demo setup on the spoon.net home page -- click a few base images, press Run, and a container console with those images will pop-up (you will need to install the Spoon browser plugin and download the images the first time). Those on the thread "concerned" about whether Spoon is a legitimate container implementation should launch a dozen container instances and note the performance.. or just walk through the Tour samples.
I know those of you who use Windows will love the new Spoon containers.
-k
PS As I write, a user just submitted a Minecraft Server container to the Spoon Hub. Going to go check it out (https://spoon.net/hub/mwrockx/minecraft-server) and have some fun!
The simplest test I can think of (`docker run busybox true`) takes 0.38s wall clock, pretty far out from your statement even when allowing for it stopping as well.
I've not seen millisecond startup times since pre-1.0 on any of my machines (there was a post on the mailing list about the mailing list about this slowdown a while back). When/where have you seen this advertised?
Edit: unless we're excluding the time for the implicit `create` from this, which doesn't seem like a very helpful metric.
Good to know. The milliseconds claim is on their website, I took it for granted and never timed it. I guess they consider anything under 1 second as "milliseconds" :) But actually the stopping time could be a factor.
When the process executable path is located on a networked filesystem - cached data for that file must be thrown away by the OS once the file lock is released (which happens when the process exits). So you will actually speed up subsequent launches of the process if you delay your shutdown a little bit such that the file lock is held and thus the system cache for that file is not thrown away. They probably aren't doing this though...
Docker isn't actually a containerisation engine, it's simply an orchestration layer for Linux kernel components that implement the containerisation.
You shouldn't be comparing something that attempts to implement containerisation itself and something that simply calls OS APIs to do said containerisation.
In terms of cross version compatibility I don't think Microsoft intends to fix this. There isn't really any reason to. They could extend the SxS system to support multiple versions of core DLLs in different namespaces but I doubt that will actually happen.
The reason I doubt it will happen is that the hype around containers has nothing to do with lift and shift of legacy applications, but rather what new applications and platforms are possible with more efficient isolation and portability of runtime + application.
I would expect their efforts to be directed towards .NET, making it easy to package and application, the Global Assembly Cache and any native libraries it needs. Sure you could run any arbitrary application and there would but support for that but it's clear where their priorities lie.
PS: It's worth mentioning that Windows already has network namepaces support. It was implemented to support the virtual network gateways for VMM's NVGRE. I think it's safe to assume they will go the Linux route and implement separate support for process, permissions and filesystem namespacing too. The real show will be wether filesystem namespacing is done at VFS layer of if they implement it directly in NTFS or ReFS.
You can clone ThinApp behavior relatively in short time using hooking libraries.
Similarities: - You can package your application into a single file and then run that on a clean Windows OS without installing. Startup times will vary - mostly based on the app. Docker advertises millisecond startup times, Thinapp is probably in the 10s of milliseconds to startup - but if the app comes packaged with a lot of fonts these may need to be extracted from the package first (not a problem for server apps). - There are command line tools you can use to build your package using something like a makefile. - You can package runtimes and support applications into your packages (.net, SQL server, etc). - In Thinapp & others most filesystem and registry writes by the application are redirect to a sandboxed location. The sandbox directory can be located on another storage mechanism, so the VM can be treated as stateless.
Differences: - Docker provides full namespace isolation between apps, another app on the same system won't affect your app. In Thinapp and others, this isn't 100% the case - for example names of shared memory objects, window titles, and most of the filesystem/registry will share a namespace with other processes. Thinapp has the ability to apply namespace isolation in specific cases, but doesn't do it by default because this can cause comparability issues. - Docker provides network isolation. Each app gets it's own private network stack this eliminates port collisions, etc. This is not the case for Thinapp, etc. - OS comparability is not assured, you still need to test your app on various OS's to make sure it works compared to Docker. For example, if your app uses a new API from Windows 7 - it will not run on Windows XP. In some cases this isn't true, you can use Thinapp/spoon to package an app with some DLLs from earlier or later versions of windows so it will run on older/newer versions - but that is not the case for things that use core system DLLs like ntdll or kernel32. I'm curious how Microsoft will address this when they introduce containers.
If you are running your app inside of a clean VM on amazon, you don't care as much about isolation of namespaces, filesystem, and network - so these solutions might be viable.
Microsoft had an old research project that died that is very close to Docker: http://research.microsoft.com/pubs/141071/asplos2011-drawbri...
Some other comments state this is the same as VMs, it's not. Application virtualization is a bit closer to Wine - it emulates parts of the Windows loader to load applications and it places hooks in all the application's API calls to access the filesystem, register, services, etc. It hooks all API calls that might need to access something from the system so those calls can be redirected to access data inside the package.
Anyway - Spoon's announcement doesn't go into any detail on what is new relating to what they are providing, it seems a bit of marketing repositioning to capture some of Docker's popularity. But - it could be a good place for them to be if/when Microsoft completes it's work on isolated containers, if they can provide a solution in that space that competes with Docker (and "free") they might find a market.