Firecracker is hardware-based virtualization. gVisor is not virtualization at all but more like advanced sandboxing - it intercepts syscalls and proxies them on processeses behalf. That means gVisor is slower on i/o (which this new feature is trying to solve) but it also means it’s easier to implement and operate and you can run it in more environments (for examples in VMs where nested virtualization is not supported).
If you want to join us in the peanut gallery, AWS originally "adapted" Google's crosvm for firecracker.
gVisor, if not using hw-backed virtualization, has absolutely horrendous performance because of, amongst other things, ptrace, which is one reason why this blogpost exists.
Note that ptrace is only one platform and it’s no longer even the default. It’s been replaced by systrap. When running on bare metal, the KVM platform provides the best performance: https://gvisor.dev/docs/architecture_guide/platforms/
This sort of feels like seeing someone riding a bike and saying: why don’t they just get a car? The simple fact is that containers and VMs are quite different.
I’m responding to what I believe is the intent of the comment, but I will also point out that on a literal level it doesn’t make sense. Whether something uses VMX and friends or not is a red herring, as gVisor also “rolls it own” VMM [1] and certainly makes use of VMX and friends.
Firecracker may be better but it's irrelevant if I cannot use it in my environment.
In particular firecracker runs on bare metal or VMs that support nested virtualization, which unfortunately is not widely available in the clouds (and bare metal is expensive)
Firescracker is good and all but if one wants to use it, one has to change its ecosystem, it’s communication with other servers, why change your entire ecosystem for one tool or just build a tool to fit your ecosystem, and really like the concept of firecracker-containerd but still need some modifications and also I wouldn’t expect Google to put their entire Cloud Run, App engine under the hands of aws (even tho it’s FOSS)
What is your definition of long running processes?
AWS Fargate (containers as a service for ECS/EKS) uses Firecracker under the hood, and you can easily have the container up for weeks, and probably even for months.
Similarly, Fly.io also uses Firecracker, and again, you can have weeks/months long uptime on containers.