Ignite – Use Firecracker VMs with Docker images
61–70 of 84 posts
Re: Ignite – Use Firecracker VMs with Docker images
#62can someone help me understand why VMs are necessary here?
By making that boundary, you get "slightly safer" code execution in a multi-tenant environment.
Re: Ignite – Use Firecracker VMs with Docker images
#63Earlier quoted context omitted.
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 u…
Multi-tenant systems are also a use-case (and a pretty major one).
Re: Ignite – Use Firecracker VMs with Docker images
#64Earlier quoted context omitted.
Multi-tenant systems are also a use-case (and a pretty major one).
The kernel already guarantees isolation. Unless I missed the point of cgroups.
Re: Ignite – Use Firecracker VMs with Docker images
#65Earlier quoted context omitted.
I'm not trying to be argumentative, but rather just to clear things up for you: All serverside cloud-style VMs get tap devices. That's not a Firecracker thing. IPSEC works just fine from within a VM. Firecracker doesn't care; it's just a hypervisor. I'm not sure what you're trying to say about the CPU thing; Firecracker is a hypervisor, not an emulator. Linux QEMU VMs are KVM, too. SANs work fine from within VMs. The…
> All serverside cloud-style VMs get tap devices Unless you want to PCI pass-through an SRIOV VF into a guest? If you're paying out the ass for Cisco cloud gear you probably want the guest to have direct access to a card... Again, I don't remember the specifics, but depending on the underlying networking (on the host etc), there may be some issues with IPSec (but I could be wrong). From some random searching: https:/…
Re: Ignite – Use Firecracker VMs with Docker images
#66Earlier quoted context omitted.
The kernel already guarantees isolation. Unless I missed the point of cgroups.
"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.
Cgroups and kvm are basically the same age (kernel support in 2.6) so saying “cgroups is newer so it must be more insecure” is fairly false.
Firecracker is, in fact, quite new, and may or may not be more vulnerable as it is a completely new implementation of a kernel.
Re: Ignite – Use Firecracker VMs with Docker images
#67Earlier quoted context omitted.
"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.
So, marketing hype to sell your clients, not a real technical use-case. Cgroups and kvm are basically the same age (kernel support in 2.6) so saying “cgroups is newer so it must be more insecure” is fairly false. Firecracker is, in fact, quite new, and may or may not be more vulnerable as it is a completely new implementation of a kernel.
I did not say that.
> as it is a completely new implementation of a kernel.
Firecracker is not a "completely new implementation of a kernel", whatever that means.
Re: Ignite – Use Firecracker VMs with Docker images
#68Earlier quoted context omitted.
> microVMs for running containers are definitely a great idea I think my greybeard must be getting too long... This sounds like insanity to me. Why not just make a base image and some simple setup scripts? If you need to get super fancy, these guys have it figured out [1]. They can clone a running vm in under two seconds. [1] https://codesandbox.io/post/how-we-clone-a-running-vm-in-2-s...
> 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.
Re: Ignite – Use Firecracker VMs with Docker images
#69Earlier quoted context omitted.
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. ... an…
> 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 poppin…
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.
Re: Ignite – Use Firecracker VMs with Docker images
#70Earlier quoted context omitted.
> microVMs for running containers are definitely a great idea I think my greybeard must be getting too long... This sounds like insanity to me. Why not just make a base image and some simple setup scripts? If you need to get super fancy, these guys have it figured out [1]. They can clone a running vm in under two seconds. [1] https://codesandbox.io/post/how-we-clone-a-running-vm-in-2-s...
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.
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.