[HN Gopher] Fly Machines: An API for Fast-Booting VMs
___________________________________________________________________
Fly Machines: An API for Fast-Booting VMs
Author : samwillis
Score : 91 points
Date : 2022-05-24 19:48 UTC (3 hours ago)
(HTM) web link (fly.io)
(TXT) w3m dump (fly.io)
| chrisweekly wrote:
| There's something about the tone and content of fly.io blog posts
| that makes it impossible for me not to root for them. (It also
| helps that the DX is so great.) I've only had a chance to deploy
| toy apps to Fly.io, nothing at scale, yet, but it checks all my
| boxes.
| punnerud wrote:
| " My M.O. with these posts: write it like it was an HN comment,
| and then edit the sentences to be shorter. I'm glad people like
| it, though."
|
| From the button of the comment:
| https://news.ycombinator.com/item?id=26747701
|
| He is often on HN, look at the karma:
| https://news.ycombinator.com/user?id=tptacek
| tptacek wrote:
| Kurt and Chris wrote this, not me. :)
| arthurcolle wrote:
| > We're not done. You need something to run, right? Firecracker
| needs a root filesystem. For this, we download Docker images from
| a repository backed by S3. This can be done in a few seconds if
| you're near S3 and the image is smol.
|
| Lmao props to the team for getting this copy out unsanitized by
| (potentially) unchill bosses.
| [deleted]
| kasey_junk wrote:
| The author of the post is the CEO
| tptacek wrote:
| He and Chris Nicoll snuck it past _me_ ; I was too tied up in
| family business to moderate the tone and add the business-
| friendly grace we're so known for. But this is just a feature
| announcement; I don't think we really hoped this would be a
| front page discussion. We have some meaty stuff to say about
| how Fly Machines work coming up.
| aarondf wrote:
| The author of the article is the CEO, which makes it at least
| 2x as cool.
| arthurcolle wrote:
| Oh wow, cue butterfly meme "is this love at first sight?"
| RcouF1uZ4gsC wrote:
| What an exciting time to be a developer!
|
| I am so excited about the future. We are seeing a bunch of
| announcements from multiple companies that make it possible for a
| single developer or small team to fairly cheaply run a global
| service without spending a whole lot of time on ops.
|
| I am excited to see what people will come up with.
| asim wrote:
| Now they've got my attention. This is incredibly difficult to
| execute on. Kudos to the team there who figured it out. If fly is
| or can become profitable then they've got a chance at being
| around for a long time. I can see them as the new cloudflare.
| gsanderson wrote:
| They are :) You might want to check this community discussion
| about their funding and longevity for more
| https://community.fly.io/t/funding-and-longevity/1957/2
| mcintyre1994 wrote:
| > Fly Machines will help us ship apps that scale to zero sometime
| this year.
|
| I think this is what will make Fly really exciting. Right now (if
| I understand right) you need to be paying for a VM 24/7 in every
| region you want your app available in, because it only scales
| down to 1. So it runs apps in regions close to users that you're
| willing to pay for 24/7. If they make scale-to-zero work in every
| region, then maybe you can just make every app global and if you
| have some occasional users in Australia then it can just spin up
| over there while you're getting requests. I think it's what will
| make many-regions feasible for every app.
| gsanderson wrote:
| Currently you can scale down to 1 in total, rather than down to
| 1 per region. But yep, scaling down to 0 will be even better.
| mcintyre1994 wrote:
| Ah my mistake, that's already really good! :)
| tag2103 wrote:
| I have to make a reference to ointment- it is obligatory.
| viraptor wrote:
| Ok... So what are the tiktok accountants? All the bad financial
| takes on tiktok or something else?
| zrail wrote:
| ...something else.
|
| Edit: the meme goes something like "no one asks follow up
| questions if you say you're an accountant"
| Havoc wrote:
| Really like the recent handful of smaller companies announcing
| more sorta serverless style building blocks.
|
| It's one of the major pluses of the big clouds yet their pricing
| isn't always awesome. Smaller player can help push that down.
|
| See also the DO announcement today. Probably won't use that but
| glad about it anyway
| bogomipz wrote:
| The post states:
|
| >"We're not done. You need something to run, right? Firecracker
| needs a root filesystem. For this, we download Docker images from
| a repository backed by S3. This can be done in a few seconds if
| you're near S3 and the image is smol."
|
| I feel like I am missing something. If an S3 bucket is a
| requirement and I was interested in the isolation provided by
| Firecracker why wouldn't I just use AWS Fargate or Lambda which
| are both powered by Firecracker? If low latency was the concern,
| I can't imagine there being any lower latency than having my
| workload and storage being colocated in the same AWS Availability
| Zone.
| tomatowurst wrote:
| How does this compare to AWS Lambda's docker support
| dilyevsky wrote:
| Does Fly implement live migration under the hood?
| ryanianian wrote:
| > turns Docker images into running VMs
|
| I honestly don't understand what's going on here. I thought we
| turned to Docker/containers because VMs were too heavy? Now we've
| got VMs that run Docker? (Not trying to be dense - what is the
| advantage?)
| wmf wrote:
| Everybody hypnotized themselves into believing that containers
| are not secure and can never be made secure so they run one
| container per VM. Instead of investing in making containers
| secure, the industry decided to invest in making VMs ligher, so
| VMs are now efficient enough that you can run one container per
| VM.
|
| Why run Docker in VMs instead of using VM images? Because
| Docker's build tools are more popular than Packer-style
| tooling.
| foobiekr wrote:
| The issue with container security is that the linux kernel
| boundary is porous and probably not possible to secure in
| depth.
| tptacek wrote:
| I don't know if hypnosis works or not, but quitting smoking
| is good whether or not you hypnotize yourself to do it, and
| so is avoiding multi-tenant Docker. The broad kernel attack
| surface is much too scary to expose directly to multi-tenant
| workloads, and there have been fairly recent kernel LPEs that
| would have avoided any sane system call filter you could come
| up with.
|
| It's a moot point, because this is a solved problem. Use
| containers for single-tenant workloads; use micro-VMs,
| whichever flavor you like best, for multi-tenant.
| viraptor wrote:
| > hypnotized themselves into believing that containers are
| not secure
|
| They provide any extra layer of indirection which helps with
| usual exploit attempts, but also introduce new scope. We've
| had exploits specifically targeting the namespaces API
| already.
| solarkraft wrote:
| > We've had exploits specifically targeting the namespaces
| API already
|
| Well, isn't that what happens when you put a shield into
| place? Someone tries to break it. Why have people concluded
| that it can never be made properly secure?
| tptacek wrote:
| Because the broad kernel attack surface is huge, and the
| shield has to reliably protect all of it, or all you've
| done is create a jungle gym for vulnerability
| researchers. The win with virtualization is that it
| drastically scopes down the amount of kernel code exposed
| to untrusted code.
| rstupek wrote:
| Isolation would be the biggest advantage so they can host
| multiple clients on the same machine. Fly uses a lightweight vm
| (someone chime in if they have better details).
| tptacek wrote:
| https://fly.io/blog/sandboxing-and-workload-isolation/
|
| https://fly.io/blog/docker-without-docker/
| zrail wrote:
| Firecracker is a thin layer on top of KVM. It essentially
| implements just a handful of devices and it boots in
| milliseconds. Fly bakes a Docker image into the format that
| Firecracker expects and then boots it, alongside a bunch of
| anycast networking magic. You get the security guarantees of
| KVM with the developer experience of docker.
| ignoramous wrote:
| > _thought we turned to Docker /containers because VMs were too
| heavy?_
|
| VMs are lightweight now, though containers are lighter still;
| ref: https://fly.io/blog/sandboxing-and-workload-isolation/
|
| Btw, Docker wasn't about security as much as it was about
| "package once, run anywhere".
|
| > _Now we 've got VMs that run Docker?_
|
| Fly.io doesn't run Docker as-is, but rather unpacks it and runs
| it in a guest through _containerd_ ; ref:
| https://fly.io/blog/docker-without-docker/
|
| > _...what is the advantage?_
|
| This has been discussed numerous times, and here's a link to
| one such discussion:
| https://news.ycombinator.com/item?id=26747701
|
| Read also: https://gruchalski.com/posts/2021-03-03-thoughts-on-
| creating...
| dilyevsky wrote:
| Containers are still more lightweight (tho not by a lot these
| days) but they are hella insecure for untrusted workloads. Plus
| people like and depend on docker workflows hence taking docker
| container (basically just a tarball+json manifest) and making a
| VM out of it
| viraptor wrote:
| Not quite mentioned in other answers, but historically, the VMs
| we used to run were heavy. A typical qemu-kvm machine needs to
| actually boot up, initialise, start a number of services, etc.
| Firecracker is not that - it essentially gives you a kernel
| that already knows the environment and can do bare minimum
| before executing the provided image. It's like a halfway point
| between unikernels and independent VMs. The VM technology
| itself is not necessarily heavy - it just depends how you use
| it.
| qbasic_forever wrote:
| IMHO with fly.io their use of containers is more for the dev
| experience. It's incredibly easy and popular to whip up a
| Dockerfile, test it locally, ship it to a registry, etc. Anyone
| can learn the Dockerfile syntax and be productive with it in an
| afternoon.
|
| The tooling for proper VM creation on the other hand is in the
| stone-age comparatively--there are just a few tools like packer
| or a frankenstein of ansible scripts and neither are as nice or
| easy as Dockerfile creation.
___________________________________________________________________
(page generated 2022-05-24 23:00 UTC)