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?
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.
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.
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.
