31–40 of 44 posts
> Spoon is the first and only containerization service available on the Windows platform 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.
Spoon is very similar to VMware Thinapp, which I started 10+ years ago. Both have a lot of similarities to Docker, but there are important areas that cannot be addressed without Microsoft's support (see recent announcement between Microsoft and Docker). There are also other similar solutions in the industry like Microsoft AppV and VMware recently acquired a product called "Cloud Volumes". Similarities: - You can pack…
> Startup times will vary - mostly based on the app. Docker advertises millisecond startup times, Thinapp is probably in the 10s of milliseconds to startup [...] 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…
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...
Spoon is very similar to VMware Thinapp, which I started 10+ years ago. Both have a lot of similarities to Docker, but there are important areas that cannot be addressed without Microsoft's support (see recent announcement between Microsoft and Docker). There are also other similar solutions in the industry like Microsoft AppV and VMware recently acquired a product called "Cloud Volumes". Similarities: - You can pack…
I think it is easier to explain saying that ThinApp and Spoon use hooks while Docker uses kernel support isolation. App-V and Symantec Workspace Virtualization have also filtering drivers but they don't go as far in the kernel as LXC. You can clone ThinApp behavior relatively in short time using hooking libraries.
As someone who has had a hell of a time setting up and consistently getting running certain programming language environments, this appeals to me greatly. It was countless headaches getting Clojure to work, and I still can't update cabal for Haskell without breaking everything.
> spoon run clojure
and Haskell/Cabal sounds like a great idea as well.
Sort of off topic, but how does Spoon relate too services like TestingBot for Selenium testing in the cloud?
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.)
> Spoon is the first and only containerization service available on the Windows platform Sandboxie was the first one: http://www.sandboxie.com , http://en.wikipedia.org/wiki/Sandboxie
As someone who has had a hell of a time setting up and consistently getting running certain programming language environments, this appeals to me greatly. It was countless headaches getting Clojure to work, and I still can't update cabal for Haskell without breaking everything.
I don't understand what's so hard to get clojure to work. You only need Java and lein, and that's about it. 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 is very similar to VMware Thinapp, which I started 10+ years ago. Both have a lot of similarities to Docker, but there are important areas that cannot be addressed without Microsoft's support (see recent announcement between Microsoft and Docker). There are also other similar solutions in the industry like Microsoft AppV and VMware recently acquired a product called "Cloud Volumes". Similarities: - You can pack…
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!
All the people who diss this are nitpicking over details way too much. Yep, it's virtualization and not containers in the LXC sense, and yep, it's commercial-as-fuck and closed source. 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. Still, Spoon is pretty cool, it allows you to do many of the things people use Docke…
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!
> Because containers are built on the Spoon virtualization engine, rather than simply providing an interface to container support in an underlying operating system, Spoon can containerize applications across multiple operating systems and provide advanced virtualization primitives. That means it's not containerization, but virtualization. This hardly compares to the Docker world which offers a intermediate build syst…
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.