The whole point of Firecracker over normal VM solutions is that "booting an OS" takes milliseconds.
Still, I don't think Docker is at risk of being replaced just yet because of the resource management benefits you get from sharing a kernel.
There's definitely a tradeoff, but IME it's not as drastic as you first think.
Define "OS". A barebones OS will indeed start in microseconds. But then your app/service won't. Because it will likely need a gazillion things that a barebones OS doesn't provide. Suddenly the startup time isn't microseconds or even milliseconds.
Sadly, we never got the promise of unikernels, and everything requires the full-blown OS to run anything
I don't have any recent measurements myself, but the startup time for a full Linux kernel using Firecracker's snapshotting feature seems to be around 30ms if you optimise calls for latency: https://dev.to/adwitiya/how-i-built-sandboxes-that-boot-in-2...
The measurements in that blog post place Firecracker above Docker in terms of startup performance. Most of that delay is probably the Docker daemon rather than Linux namespace APIs, but that's beside the point.
Huggingface places Firecracker startup time between 100-300ms while Docker is at 50-200ms, based on Kata: https://huggingface.co/blog/agentbox-master/firecracker-vs-d...
Either way, latency is in the same ballpark of "low enough that it only matters in edge cases".
The gazillion things that the OS doesn't provide is taken care by language runtimes, which can perfectly run directly on top of type 1 hypervisors.
In similar way how some of those languages have bare metal implementations for embedded development, where the runtime takes the OS role.
Naturally on languages with thin runtimes and heavy reliance on POSIX like C and C++, this isn't as straightforward.
These days I'm looking at microvms (esp. smolvm from smolmachines.com) by default, for anything where I'd previously have reached for docker (via colima or more recently orbstack).