4 ms·

Unrelated, but could you please expand on how firecracker fits within your stack?

tptacek 6y ago
You could describe our job as "taking Dockerfiles from customers and running them globally"; the way we actually "run" Docker images is to convert them to root filesystems and run them inside Firecracker. Firecracker is the core of our stack.
- riyakhanna1983 6y ago
  Why not just run Docker containers natively?
  - mrkurt 6y ago
    We have a whole post about workload isolation that answers this: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/ The tldr is: Docker containers don't offer enough isolation for multi tenant systems. They're also very slow to boot, compared to a Firecracker VM.
    - riyakhanna1983 6y ago
      But does FC not incur high I/O overhead at runtime?
      - mrkurt 6y ago
        The flippant answer is "it doesn't really matter, safety usually wins over performance". But also, we run Firecrackers on our own physical servers and performance is quite good (even network + disk performance).
- k__ 6y ago
  I find it rather curious that the cloud-native crowd tries to sell us containers, but cloud providers themselves use VMs. Like, if not even AWS, Cloudflare, and fly.io use containers, how can K8s be native in any way? I mean, that makes even Lambda, which runs on Firecracker VMs, more native than K8s.
  - mrkurt 6y ago
    Most organizations don't have the multi tenant problem we do, and end up just using Docker when they do containers. But I also think it's fair to call "Firecracker VMs" containers. Most of what those people are talking about is application packaging and deployment, not necessarily what actually runs. For what it's worth, I am also cynical about "cloud native".
  - michaeldwan 6y ago
    Fwiw we run as many services as we can on our own platform. Mission critical systems like our registry, api, redis servers, and much more are all running as fly apps in firecracker.

You could describe our job as "taking Dockerfiles from customers and running them globally"; the way we actually "run" Docker images is to convert them to root filesystems and run them inside Firecracker. Firecracker is the core of our stack.

riyakhanna1983 6y ago
Why not just run Docker containers natively?
- mrkurt 6y ago
  We have a whole post about workload isolation that answers this: https://fly.io/blog/sandboxing-and-workload-isolation/ https://fly.io/blog/sandboxing-and-workload-isolation/ The tldr is: Docker containers don't offer enough isolation for multi tenant systems. They're also very slow to boot, compared to a Firecracker VM.
  - riyakhanna1983 6y ago
    But does FC not incur high I/O overhead at runtime?
    - mrkurt 6y ago
      The flippant answer is "it doesn't really matter, safety usually wins over performance". But also, we run Firecrackers on our own physical servers and performance is quite good (even network + disk performance).
k__ 6y ago
I find it rather curious that the cloud-native crowd tries to sell us containers, but cloud providers themselves use VMs. Like, if not even AWS, Cloudflare, and fly.io use containers, how can K8s be native in any way? I mean, that makes even Lambda, which runs on Firecracker VMs, more native than K8s.
- mrkurt 6y ago
  Most organizations don't have the multi tenant problem we do, and end up just using Docker when they do containers. But I also think it's fair to call "Firecracker VMs" containers. Most of what those people are talking about is application packaging and deployment, not necessarily what actually runs. For what it's worth, I am also cynical about "cloud native".
- michaeldwan 6y ago
  Fwiw we run as many services as we can on our own platform. Mission critical systems like our registry, api, redis servers, and much more are all running as fly apps in firecracker.