Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design and Implementation of Sprites

fly.io

Post reply on HN
Print view View original

91–100 of 111 posts

Re: Design and Implementation of Sprites

#91

Post by macNchz »

tptacek wrote: post #7
MrOrelliOReilly wrote: post #5

I appreciate the Fly.io team’s enthusiasm and am optimistic this will mature into a product I’d pay for, but my initial impression was of a lack of polish. Documentation is sparse, or not even available? The API docs don’t tell you much about the service itself, and a Google search for docs returns an inaccessible website as the first result ( https://docs.sprites.dev ). Blog posts and forum threads and Claude skills…

You're not wrong. The documentation actually had a hallucinated link to an Anthropic dependency in it when we shipped. Right now the attitude is mostly "if we have to document it extensively, we're doing something wrong". It's been in the works for awhile , with a small team, and we're just getting it out there right now. I've been needling Kurt for several months now that if we wait until it's polished enough that w…

For what it's worth, I evaluated Fly.io during a divorce from Heroku some time in mid 2022 (I think), found the platform was... way too rough around the edges at the time to want to migrate any real workloads. I kept it on my radar and shipped an MVP with it in 2024, found it was a lot more polished, and now have multiple production apps running there. I'm genuinely pumped about Sprites and have started building against the API—I did notice the weirdness with the docs, but you guys have been doing well on the "this thing that {was broken|I didn't like|was missing} now works the way I'd hoped it would" front.

Re: Design and Implementation of Sprites

#92

Post by Imustaskforhelp »

mrkurt wrote: post #48
panarky wrote: post #25

Earlier quoted context omitted.

There's no way to stop sprites from the CLI. Supposedly they auto-stop when inactive. But I've tried multiple times and they don't stop, and it's not just Docker that prevents them from stopping. I created a new sprite and installed ffmpeg. Then exited. Next day I run `sprite ls` and it's been running continuously for 23 hours. No way to tell if I'm being billed for it or not. And the per-hour pricing is extremely ex…

For what it's worth, CPU pricing is based on CPU util. A sprite sitting idle CPU costs almost nothing, even when "active".

So is it similar to railway in this context?

Re: Design and Implementation of Sprites

#93

Post by Imustaskforhelp »

tptacek wrote: post #37
boundlessdreamz wrote: post #31

Is there a way to copy files to/from the sprite? Couldn't see an option for that in the CLI

There's an FS API that shipped yesterday: /fs/read?path=X | GET | Read file (supports Range headers) /fs/write?path=X | PUT | Write file (body = raw bytes) /fs/list?path=X | GET | List directory /fs/delete?path=X | DELETE/POST | Delete files/dirs /fs/rename | POST | Rename/move /fs/copy | POST | Copy files/dirs /fs/chmod | POST | Change permissions /fs/chown | POST | Change ownership /fs/watch | GET (WebSock) | Watch…

Piping server is another interesting idea for ephemeral transfers They are pretty cool!

https://github.com/nwtgck/piping-server

Re: Design and Implementation of Sprites

#94

Post by agosta »

Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on? Do these horizontally scale a long lived, high trafficked application?

Re: Design and Implementation of Sprites

#95

Post by mrkurt »

agosta wrote: post #94

Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on…

> Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?..

Yes.

They won't horizontally scale. They're pretty good for hosting my side projects! Not good for, eg, hosting the API that orchestrates Sprites.

Re: Design and Implementation of Sprites

#96

Post by adriand »

blackqueeriroh wrote: post #84
adriand wrote: post #11

Earlier quoted context omitted.

What's the option for iOS? I've tried installing ish and a-shell and can't get the sprites CLI installed on either of them.

Yeah, i’ve been looking at this. The easier this is to attach to your tailnet and ssh in from inside, I don’t think you’re dealing with the proxy then. I tried several things and this is going to be the next one.

Let me know when you figure it out!

Re: Design and Implementation of Sprites

#97

Post by threecheese »

agosta wrote: post #94

Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on…

TFA links to a post by Kurt M at Fly which speaks to this, from a personal perspective. They are using sprites for a “production” workload - a tool for their family - and it’s persistent and accessible enough that they don’t have plans to move it.

https://fly.io/blog/code-and-let-live/

Thomas characterizes this as “believ[ing] that the future belongs to malleable, personalized apps”, which I think describes the use case perfectly. As a “barefoot developer” (to borrow another localfirst term, thanks Maggie Appleton), does every app really need more than a persistent home and an URL?

And so to your question “is the idea that these things can also/should run production workloads”, I believe “can” is right - but suspect that supporting “should” is on Fly’s roadmap.

Re: Design and Implementation of Sprites

#98

Post by tptacek »

agosta wrote: post #94

Guess I'm confused - is the ideal use case for Sprites for suspendable, iterative, sandboxed compute sessions (with disk)?.. Or is the idea that these things can also/should run production workloads in place of a traditional webserver setup? If the latter, can every sprite boot up with what's needed to instantly serve web traffic? Or would they need to build/install things internally every time a new sprite turned on…

They're an interesting middle ground between pure ephemeral dev environment and production environment. If your audience is the whole Internet, a Sprite won't scale today to serve it. But for most of the apps I'm building, the Sprite is actually fine for the foreseeable future. There's a ton of security automation stuff we're doing that a Sprite keeps up just fine with; the sandwich bracket I'm running downthread is also indefinitely fine on a Sprite.

On the other hand, if I took the sandwich bracket app and made it a generic "run a bracket" app and that app (inexplicably) got popular, I'd need to move it to a Fly Machine setup.

Re: Design and Implementation of Sprites

#99

Post by randito »

chrismccord wrote: post #9
tptacek wrote: post #2

I wish I'd had more space to write about the global orchestrator design, because it's fun. The Fly Machines orchestrator goes through some trouble to keep the source of truth for each VM decentralized, owned by the physical it runs on. But there's still global state --- apps, organizations, services. That stuff is all on Postgres. Postgres keeps up with it just fine but I'd be lying if I didn't say we're always looki…

I've been working on the orchestrator side with Elixir and Phoenix, so happy to continue the discussion for curious minds. One of the coolest things we can do is things like this in Elixir - from any node we can reach out to a sqlite db across the planet: OrgTracker.with_repo(org_id, fn -> repo.all(from sprite in "sprites", select: ...) end) That will find or place an Elixir process on the cluster and rpc the target…

(Disclaimer: Newbie checking but still curious).

Are you using libluster or Distributed Erlang to reach the clusters? Or just simple networking over the Fly network.

> That will find or place an Elixir process on the cluster and rpc the target node with our code.

Is this similar to what you did with Flame? Or just a refinement of that idea.

Re: Design and Implementation of Sprites

#100

Post by threecheese »

panarky wrote: post #36
tptacek wrote: post #29

Earlier quoted context omitted.

Sprites are active when: * They're servicing an incoming HTTP request. * You're interacting with a console. They're hair-trigger inactive otherwise. They don't bill CPU unless they're active. The idea is that there isn't really any uncertainty about when it's running; when you stop interacting with it it stops metering. This is a new shape for a cloud computing thingy and there'll be snags this week with it, but we d…

No console activity, no HTTP requests, but it doesn't stop. Can't find any place in CLI or web UI to see how many minutes are charged for CPU, memory, storage. $ sprite ls Sprites in organization : ┌────┬───────┬────────┐ │NAME│STATUS │CREATED │ ├────┼───────┼────────┤ │duh │running│ 23h ago│ └────┴───────┴────────┘ Total: 1 sprite(s)

My read of his response is that, even though the sprite is in a running state, that doesn’t mean it’s in a billable state given you aren’t connected; that’s not said explicitly, and I’m making an inference, and so it would be helpful if you let us know if you are billed for these hours.
Post reply on HN