I don't really know the details of the architecture - but I bet there's heavy use of sqlite - if the sprites can be paused without consuming resources.
Code and Let Live
141–150 of 195 posts
Re: Code and Let Live
#142> They go idle and stop metering automatically, so it’s cheap to have lots of them. I use dozens.
> Despite all that, they’re fully durable. They don’t die until I tell them to.
what?
Re: Code and Let Live
#143> They go idle and stop metering automatically, so it’s cheap to have lots of them. I use dozens. > Despite all that, they’re fully durable. They don’t die until I tell them to. what?
I guess they autoresume from idle if an https request comes to a sprite
Re: Code and Let Live
#144Earlier quoted context omitted.
More complicated than that, but with respect to Sprites --- this is a totally new stack.
it seems like when you snapshot, you snapshot memory AND the filesystem (immutable ftw), that's pretty awesome i am dying to know: firecracker still? I know you have an upcoming post abt it, but i'm incredibly impatient when it comes to fool new infra
Alright nerd-snipe snooping research post happning now!
Seems like they are using JuiceFS under the hood, with an overlay root for your CoW semantics. JuiceFS gives them instant clone (because they're not cloning the whole rootfs), while the chnages to the overlay are done as an overlayfs and probably synced back to S3 via a custom block device they have mounted into firecracker.
You can also see they are using juicefs it for the "policy" directly (which I'm assuming is the network policy functionality). iirc juicefs has support for block devices too, so maybe they are using that to back the rootfs overlay.
One concerning thing is the `/var/lib/docker` mount - i ran this in an ubuntu container, did they... attach it? Maybe that's a coincidence, but docker is not installed on the sprite by default. (the terminal is also super busted when used through an ubuntu container)
https://pastebin.com/raw/kt6q9fuA (edit: moved terminal output to pastebin because it was so ugly here)
I played with a similar stack recently, my guess is they are: 1. making some base vm, snapshotting it 2. when you create a vm, they just restore a copy and push metadata to it (probably via one of the mounts) 3. any changes that you make to the rootfs are stored on the juicefs block device (the overlay), which is relatively minimal compared to the base os. JucieFS also supports snapshotting, so that's probably how they support memory + filesystem snapshot and restore so quick
interestingly, seems they provision maybe a max disk size of 100GB for total checkpoints?
```
NAME TYPE SIZE FSTYPE MOUNTPOINTS
loop0 loop 100G /.sprite/checkpoints/active
```
fuse is definitely being used within the VMM, i can see a fuse mount and id being assigned. They're probably using juicefs directly for the policy mount because that doesn't need to be local nvme-cached, just consistent. The local-nvme -> s3 write-through runs on the hypervisor through a custom block device they attach to the firecracker vmm. This might just be the --cache-dir + --writeback cache option in juicefs. Wild guess is just 1 file per block.
guessing the "s3" here is tigris, since fly.io seems to have a relatoinship with them, and that probably keeps latency down for the filesystem
Re: Code and Let Live
#145Earlier quoted context omitted.
I have found container-use to be super useful for this. https://container-use.com/quickstart BTW Simon, I was super happy when I heard on Theo's podcast that he will be encouraging you to monetise your work more. I'm super appreciative of your work and I'm pretty convinced that the more you profit from it, the better the universe will be!!!
For those of us who weren’t on that podcast, can you clarify who Theo is?
Theo Brown? T3.gg?
Re: Code and Let Live
#146Earlier quoted context omitted.
You feel wrong. I would eat a bug before I ran LLM text on our blog. This one thing --- the fact that you can't negate a clause without people claiming an LLM wrote it --- this alone do I place angrily at the feet of AI.
Peoples' writing is influenced by what they read, so such a strong objection to someone suggesting that an LLM might have been involved in the text of a blog post won't fly with me.
[deleted]
Re: Code and Let Live
#147Earlier quoted context omitted.
If it's similar to cloudflare, then it should be usage based. That is you only pay for what is active. (ie: if you are running a task that is waiting on network for 1 hour, you don't pay for cpu but your app is loaded and you are paying for memory). So if your app is dormant (not using cpu or memory), you only pay for the storage you are using.
yeah reading further into the docs it looks like that’s the model. storage is pretty cheap, $.00068/gb-hr, so a 100GB disk runs you about 1.6 cents per day.
1.6 *dollars
Re: Code and Let Live
#148i dont think i really get what this gives me over docker. everything i read is how i work for years
Re: Code and Let Live
#149i dont think i really get what this gives me over docker. everything i read is how i work for years
Docker does not and cannot offer full isolation. A sandboxed VM on someone else's computer is less likely to be problematic for running untrusted code than a container on your system.
Re: Code and Let Live
#150I really want to love this, but my experience in the first 20 seconds is unfortunately like some of my other experiences coding against Fly APIs, they're broken. https://sprites.dev/api has this command: $ curl -X POST " https://api.sprites.dev/v1/sprites " \ -H "Authorization: Bearer $SPRITES_TOKEN" \ -d '{"name": "my-sprite"}' which responds with {"error":"name is required"} if you use the request body in the full…
The documentation is correct now. I assume someone from fly is reading the comments.