This is a great idea and something I would love to use, but it's a lot less docker compatible and user friendly than it may seem.
For instance there is no way to automatically run the image's specified command, effectively leaving you with a dead VM: https://github.com/weaveworks/ignite/issues/874. You also simply can not share directories with the host (out of scope for Firecracker).
microVMs for running containers are definitely a great idea; another project aiming to do it (a little differently) is Kata Containers. It has a lot more industry support, can also run on Firecracker (though QEMU microVMs are just as good) and can (theoretically, I haven't gotten it to work) interact with many container runtimes that are not Docker (the focus appears to be on Kubernetes).
While more powerful, Kata Containers are also much, much more complicated (and honestly under- and misleadingly documented). Ignite could fill the role of something simpler and more easy to get started with. But please, if you aim to attract Docker users, actually make it compatible with Docker principles.
There's still a lot of unused potential in containers as VMs; Kata+Kubernetes probably currently realizes the most of it.
> Why not just make a base image and some simple setup scripts?
Two major reasons:
- Reusing the vast availability of prebuilt OCI images. I don't need to create scripts at all if I find a good image someone already created a Dockerfile for. Dockerfiles are scripts anyway, especially tailored for provisioning.
- Docker's main benefit is a friendly UI over low-level Linux primitives. In this case, Ignite offers a similarly familiar UI over Firecracker/KVM, which is also cumbersome to use directly.
> Why not just make a base image and some simple setup scripts?
That makes it possible for you to create an image (VM or container?, good start. But what Firecracker and containers solve is isolation and ease of distribution.
General advice: when smart people are investing time and energy into a solution, and your alternative solution involves the word "just", it's usually a code smell that you're not giving the people doing the work enough credit.
OTOH, smart people seem to constantly try to reinvent existing products or over-engineer tools to set themselves apart and create a new business. See the endless stream of new JS frameworks popping up every day. Or the myriad ways that people try to create clouds on top of clouds (Yo dawg! I heard you like clouds!). Or new databases (although I confess I follow these). Or reinventing static HTML page delivery. ... and it goes on and on. All of these are smart people investing time and energy into a "solution" ... where there may not actually be a problem to begin with.
> See the endless stream of new JS frameworks popping up every day
Citation needed. E.g.
2010: AngularJS, Backbone
2011: EmberJS, ReactJS
2012: MeteorJS
2013: HexoJS
2014: CycleJS, VueJS
2015: MithrilJS, PolymerJS, Serverless Framework
2016: Angular2, AureliaJS, NextJS, Svelte
Those are a lot of the most popular ones, and some not very popular. Do you really consider this an endless stream of new JS frameworks popping up every day?
Yes!! Thank you!! If anything webdev is very boring (in a good way) right now, React is a de facto standard with Angular and VueJs.
It's such an outdated stereotype. And it's especially funny considering how "greybeard oldschool" stuff like Linux distros, utils and packaging seem to have a lot more of an "endless stream of new stuff" right now.
I think I'm also a pretty smart person in certain areas, or at least I should be by now having been doing this stuff for almost 30 years.
While I definitely always want to check myself, it's also part of my job to help the newer/younger engineers remember the golden rule of business technology:
Innovate in the business domain, not in the technical one. Keep technology simple and boring.
It's great to experiment, and sometimes the results of the experiments are winners. But generally you can tell winners from losers based on whether they make everything less or more complex.
NodeJS, for example, reduced complexity because it's one language everywhere and has a very simple single threaded execution model. Now with es6 modules, commonjs fading, we simplify even more.
Rollup/vite reduce webpack's complexity, but will also be replaced as native solutions emerge.
REST reduced SOAP/xml-rpc's complexity.
HTML5 replaced flash (and most of the browsers plugins), because flash had grown too complex with a massive attack surface and was impossible to properly secure. Remember ActiveX controls that would load and run in the browser with full permissions? I do. I wrote several.
Linux as an app server reduced Windows' cost and complexity.
Anything that adds needless complexity to the stack, no matter how interesting, will end up being a fad and replaced within a few years.
So, wait. You’re saying the people who developed that squeeze juice thing or the drop of blood thing shouldn’t be criticized because it is obviously a stupid idea from the get-go? C’mon man, some of us have critical thinking skills and some of us will tell you when an idea is stupid or over-engineered.
Containers as VMs is usually peak over-engineering. It’s unnecessary most of the time. In fact, there’s only a few use-cases where it’s desired to have that isolation:
- different clock rates in the container than outside (deliberate skew)
- high security applications
- require certain kernel modules that you don’t want installed in all containers
Isolation can already be guaranteed by the kernel (excepting some bugs), so I don’t think that is a valid use-case, but I could be wrong.
"guarantees". cgroups are indeed designed for isolation, but they are a feature that's been added on over time and still exposes the entire kernel as attack surface. It's considered way less trustworthy than VMs, especially minimal-surface ones like Firecracker.
Firecracker is essentially just KVM with some extremely opinionated choices to allow it to be as fast as it is. I’m hand-waving over a lot here but to differentiate it from KVM isn’t very useful here.
For instance there is no way to automatically run the image's specified command, effectively leaving you with a dead VM: https://github.com/weaveworks/ignite/issues/874. You also simply can not share directories with the host (out of scope for Firecracker).
microVMs for running containers are definitely a great idea; another project aiming to do it (a little differently) is Kata Containers. It has a lot more industry support, can also run on Firecracker (though QEMU microVMs are just as good) and can (theoretically, I haven't gotten it to work) interact with many container runtimes that are not Docker (the focus appears to be on Kubernetes).
While more powerful, Kata Containers are also much, much more complicated (and honestly under- and misleadingly documented). Ignite could fill the role of something simpler and more easy to get started with. But please, if you aim to attract Docker users, actually make it compatible with Docker principles.
There's still a lot of unused potential in containers as VMs; Kata+Kubernetes probably currently realizes the most of it.