..so is it more to support directly deploying functions to the cloud? Like, what AWS Lambda and CloudFront Functions might be built on?

I'm pretty sure firecracker was literally created to underlie AWS Lambda.

That being said, firecracker also runs long-running tasks on AWS in the form of Fargate

As does the paper [1] with details in section 4.1.

[1]: https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

yes, it was created originally for AWS Lambda

mainly it's optimized to run code only shortly (init time max 10s, max usage is 15min, and default max request time 130s AFIK)

also it's focused on thin server less functions, like e.g. deserialize some request, run some thin simple business logic and then delegate to other lambdas based on it. This kind of functions often have similar memory usage per-call and if a call is an outlier it can just discard the VM instance soon after (i.e. at most after starting up a new instance, i.e. at most 10s later)

it's not that simple many other companies running longer running jobs, including their competition, use Firecracker

so while Firecracker was designed for thing running just a few seconds there are many places running it with jobs running way longer then that

the problem is if you want to make it work with long running general purpose images you don't control you have to put a ton of work into making it work nicely on all levels of you infrastructure and code ... which is costly ... which a startup competing on a online dev environment compared to e.g. a vm hosting service probably shouldn't wast time on

So AFIK the decision in the article make sense the reasons but listed for the decision are oversimplified to a point you could say they aren't quite right. Idk. why, could be anything from the engineer believing that to them avoiding issues with some shareholder/project lead which is obsessed with "we need to do Firecracker because competition does so too".