Containers for Windows
blog.spoon.net
blog.spoon.net
What I found was marketing looking to treat containerization as nothing more than a buzz word. The article is tone deaf. It talks about running foreign OSes and legacy support proud in itself because docker cannot. Yet blind to the reason docker cannot: Docker is containers!
Any VM can do what this is doing. This is boring and I feel taken advantage of. They promised Containers can gave fast deployment VMs. On their own that is cool, but not when wrapped in a lie.
That means it's not containerization, but virtualization. This hardly compares to the Docker world which offers a intermediate build system (edit: Spoon has a build system however), rich command line tools (edit: it does provide some command line tools) to work with images and containers, fast spin up times, and an ecosystem of container management tools.
Oh, and also this:
> Spoon.net is free to use with public repositories. Private repositories, automated testing, legacy OS and browser emulation, and other advanced features are available in paid subscriptions starting at $19 per month.
And.... that it isn't open source.
-- It does however supporting composing of build images, which is kind of nice. I've learned to like mounting volumes as a form of composing though within Docker.
See above response.
> This hardly compares to the Docker world which offers a intermediate build system (edit: Spoon has a build system however), rich command line tools (edit: it does provide some command line tools) to work with images and containers, fast spin up times, and an ecosystem of container management tools.
The Spoon build system and command line tools superset Docker functionality. And Spoon does have fast spin up times and very low overhead. And Spoon does provide container management tools (Spoon Studio and Spoon Enterprise Server), although these are currently more oriented towards desktop applications vs server applications as with the Docker.
Still, Spoon is pretty cool, it allows you to do many of the things people use Docker for, on Windows: package an application, together with all of its dependencies, into a single image, and allow the user to run that single image and have it "just work" and start fast. Spoon virtualized executables start super fast, completely incomparable to starting a VM and then running a program in it, which is what everybody in this thread seems to be comparing this with.
Spoon also does this in a way that's much more accessible than Docker: A Spoon "image" is just a Windows executable, you can hand it to any user who's able to double-click an icon. That's really quite cool, especially for distributing desktop apps.
Reality is that Spoon does something that is about halfway between running an OS in a VM and LXC containers. If I were the marketing guy, I'd also call this containers, because so many of the benefits (including startup speed) are comparable. Calling it "virtualization" will make many readers think "slow, 10GB downloads, long startup times, little windows in a big window", none of which apply here.
Finally, all the ranting about how this isn't Docker at all distracts from something that IMHO is very interesting: Spoon is really decent technology, which has worked very great for very many years now (well before Docker even existed), even though it's been pretty niche among geeks.
It should also be interesting to HN how Spoon, the company, has managed to pivot its way through a changing landscape and different hypes. Not that long ago, Spoon's major product was a desktop program, Spoon Studio, that allowed you to package software with its dependencies for easy distribution. If you now look on https://spoon.net you're going to have a hard time finding that at all.
It's an interesting business! With cool technology! GitHub is closed source too, why all the hate?
Sounds a bit like static-linking plus sandbox.
Appreciate the corrections you made to the other posts and the kind words about our business.
A few comments:
> Yep, the linked blog post is mostly marketing blarp, announcing already-existing technology as if it's new by calling it different. That's pretty sad.
Actually, if you read the announcement or any of the home page materials -- much less look at the tour or demo -- you would immediately notice many major substantive new technologies. See my response to Jonathan above.
> A Spoon "image" is just a Windows executable,
While Spoon Studio does support deployment as a standalone Windows EXE, in Spoon containers, images are stored in a local container database. This supports deduplication, delta storage, journaling / commit / rollback, continuation, and other container-specific functionality. In addition, Spoon containers implement a differential synchronization protocol that allows efficient migration of container state between endpoints and the hub and back again over high-latency networks.
> Spoon is really decent technology, which has worked very great for very many years now (well before Docker even existed), even though it's been pretty niche among geeks.
Thank you! Yes, the underlying VM engine has been around quite a while and is a proven system. And yes, we've been doing this long before Docker existed. To their credit, Docker did popularize the term "containers", which is a much better term than "app virtualization" in my view. And building on LXC provided Docker a dynamic packaging model ("go through install steps on this clean virtual machine") rather than the "static" packaging model previously used by App-V, ThinApp, and Spoon Studio ("install on a machine and take snapshots" or "tell us what files/config you want"). Now, as it happens, we've had dynamic configuration on our roadmap for some time, and it just so happened that our efforts there reached fruition around the same time Docker came on the scene. In any event, Spoon containers are here now and we expect it will make Spoon technology accessible to a much larger audience.
I don't think however that a product with a multi-million desktop install base over 10,000+ organizations quite qualifies as "niche" (https://spoon.net/customers). Over 280,000 paid enterprise seats migrated from ThinApp to Spoon last year. And with the new Spoon containers, I feel the next year holds significant promise.
> It should also be interesting to HN how Spoon, the company, has managed to pivot its way through a changing landscape and different hypes.
Backstory on this: Spoon has actually moved sequentially pursuing a single vision for most of its existence, stopping to release specific products addressing specific problems along the way -- a time-consuming yet ultimately helpful constraint allowing us to avoid the use of any venture capital. (I will admit to a brief tangential flirtation with the game industry and some other poor decisions.) Along the way, the industry has independently pivoted around our project trajectory through the various hype cycles. We were building "app virtualization" before the term existed, and now "containers" before that term existed. I'm legitimately curious whether it will keep up with our next technology cycle!
[1] https://spoon.net/docs/getting-started/transitioning-from-do...
Sandboxie was the first one: http://www.sandboxie.com , http://en.wikipedia.org/wiki/Sandboxie
Thinstall worked well on Windows Vista, but battled to work properly on Windows 7.
The problem with working with Microsoft is that you're one Windows Update away from having it cause issues with your product.
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.
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.
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!
Is "containerization" a real word ?
Af for Haskel cabal hell, just use "cabal sandbox" and be happy.
- Some people (myself included) do not want to install Java on their desktop. Among other reasons, Java is a frequent source of security vulnerabilities. This allows you to use Java-based applications without installing the JVM on your desktop.
- Some applications require specific versions of Java to work correctly. I may want to do Clojure with the latest JVM while another application might require Java 6. With Spoon, you can handle this easily:
> spoon run jre:8.0,modern-project
> spoon run jre:6.45,legacy-project
- Spoon containers in particular support a concept called "continuation" that stores transient container state between commits. If you mess up your dev environment, you can restart execution at a specific state ID. This is also extremely powerful for testing. And continuation points migrate between machines -- if you want to continue your work on a different box, just execute the same "spoon continue" instruction and your container restarts.
And for clarity, these are built on lightweight VMs, not whole OS VMs. Spin up time is very rapid (excluding of course any time to download images) and you can run dozens of containers on your box with minimal overhead. (Will address this point in more detail in response to a separate thread.)
> spoon run clojure
and Haskell/Cabal sounds like a great idea as well.
Small as in 24.8 MB. That's not small.
Here's my call on this https://news.ycombinator.com/item?id=8245682
looking forward to clearer documentation if that's the case
The difference relative to other cloud testing services is that the Selenium Grid and clients are all instantiated on the local dev box. The tests generally execute much faster than cloud-hosted VMs and you can access local network resources without establish a tunnel.
(The service does interact with the Spoon.net cloud to do things like capture screenshots, store test transcripts, publish results, team collaboration, and so forth.)