Ruby on Jets: Like Rails but serverless (opens in new tab)

I've built some nice small frameworks for projects on both CloudFlare Workers and GCP Functions that do exactly this. They are so simple to build that I can't imagine needing to even open source them... but maybe should write up a blog post on the details at some point. So many people seem to miss this detail for some reason.

The main benefit is that it sure is a lot easier/faster to deploy one function than one for each route (CI/CD goes so much faster). As well as the cold starts.

Nothing prevents you from routing everything to a single function, no need to even split by controller.

The disadvantage of having a huge number of Lambdas is the ratio of cold starts. The advantage is that you can granularly tweak resource utilization on a per-operation basis.

It's typically fine - AWS bills by GB/s (in ms), not by number of functions in an account.

There are limits to the number of functions per account, and number of resources per CloudFormation stack (etc); but within those parameters it's usually a good idea to use one function for a specific controller or action. This allows you to limit IAM permissions, configure memory/CPU, and define associated resources at a per-controller level.

maybe this will eventually have an algorithm for deciding when to deploy separately and when not to, based on cost, performance, etc.

Because people don't think it's Sinatra like, but omasake like Rails.

Given how trivial it is to set up serverless Rails using something like ECS Fargate, the benefit of running specifically on Lambda is lower than migrating off a tried and tested technology.

cause we fat - got all the good stuff

Why though? what benefits does that give us?

There's a Django-ish version of this out there, and when I looked into using it briefly some time ago they had instructions on how to keep things "warm".

All that to say: I guess it's been considered, but I don't have measurements handy. It's not unknown tho.

There is some support for prewarming https://rubyonjets.com/docs/prewarming/

Having used it what are your thoughts on whether Jets replaces rails vs using alongside rails for certain types of workloads?

Yeah I'd agree, this was the instant turnoff for me, I don't like Amazon. But I totally understand people trying to build a more modern Ruby framework.

Is that like, weird? How many companies are realistically hosting their compute/data across multiple providers for the sake of diversifying that risk? Certainly some, but a tiny minority right?

> you're really wasting a lot of cpu cycles on building up the garbage collector.

Are you sure you aren't thinking of JIT compiling? The context where I think of "warmup" is (say) Java, where the runtime profiles hot paths to emit optimized machine code.

What would it even mean to "build up" a GC?

Serverless runtimes don't shut down the instance immediately after the invocation is complete but keep it up for an undetermined time depending on many factors (usually ~15 minutes) in order to process a possible new event without the start-up overhead (cold start). This means that in a system with constant traffic some instances may have a surprisingly long uptime. The instance gets destroyed when it throws an error though so a function with a disabled GC would clean the state when it runs out of memory. Slower processing done by memory-starved instances would probably eliminate any minimal performance gain you could get by disabling the GC though. (EDIT: I just realized that with no GC desperately spinning in place the starvation would not have much performance impact so this would actually be a very interesting approach if you can tolerate some invocations erroring out on out of memory errors, sorry!)

In regards to performance optimization of Lambdas, start-up time is the most important factor as cold starts happen also in cases of concurrent requests when no warm instances are available. This means that Go, Node and Python are pretty sweet for serverless. Thanks to recently released Lambda SnapStart feature that launches new instances from snapshots taken after application initialization Java (even with DI frameworks) is a plausible option if you're inclined that way. Previously you had to use a custom runtime and AOT compilation (that rules out any runtime DI stuff) to achieve tolerable performance with Java on Lambda.

Couldn't you just disable the garbage collector in those languages? I know you can select a "none" GC in the JVM, you should be able to do the same with other runtimes too.

It'll certainly help AWS to get a lot more profit :)

Mastodon is not a single service, but open source software groups/individuals/organisations run. So it's not really accurate to say Mastodon itself had issues with the huge influx of users, but rather some popular instances of Mastodon had issues.

Mastodon is supposed to be more decentralized (federated being the way of achieving that) than currently existing social media, so it'll benefit more from heavier focus on performance optimizations and more experienced gained around running it on dedicated instances, at least in the long run and considering the core idea behind Mastodon.

They started it, not there's many services providing this now. You don't have to go with AWS for a few years now if you want to go serverless. (Even if they are the most popular) For self hosted context there's https://fnproject.io/ for example.

You might be interested to check out something like wintercg which aims to make serverless environments interoperable (for JavaScript).

https://wintercg.org/

It’s really not that complex to move off of Lambda. The only lambda specific part your application needs to know about is how lambda arguments are passed. There are plenty of middleware providers out there to convert lambda function invocations to HTTP method calls in your application (mangum and others).

Lambda has supported docker images (OCI) for a while now, so you can build your application into an OCI, set the entry point to a lambda middleware and call it a day.

If you want to move off lambda you only need to change the entry-point to an ASGI server instead of the middleware and change the base image layer to be a standard one instead of the lambda specific one which has the lambda runtime installed. You can even build both images and deploy to both lambda as well as a non-serverless system such as k8s, ECS, swarm, systemd, …

I have found the Serverless framework to be great. Never really had to deal with AWS console at any point

https://www.serverless.com/

If it was only AWS.

Cloud OSes are nothing more than a return back to timesharing in new clothes.

The pendulum has swung back into thin clients, browsers and mobile OSes are the new terminals.

we're building open serverless-centered cloud-like p2p network to aolve exactly this issue. to eliminate vendor lock and make it open so anyone can both provide and consume compute resources and develop backends on top of that.

https://fluence.network

Because Ruby is OOP, Elixir is functional. Some people just get used to OOP to structure program.

It's not just ruby syntax, it's ruby. Maybe some people want the ruby ecosystem, or just don't want to leave what they are used to.

I haven't used Elixir, I couldn't say how similar it is to ruby, but my understanding is that it is a pretty different language despite some syntax similarities. Perl and C have some syntax similarities, but...

It's the same definition that the entire software industry uses and has for like a decade now. At this point crying that "serverless ackshually has servers!" is the same as pointing out that "free education isn't actually free!" as if the people using the term are unaware of this.

"Serverless" means that the developer doesn't need to think about the servers, and can interact with higher level abstractions on top of the physical servers to deploy their services.

Locking yourself into servers of one company doesn't sound like progress to me

Care to elaborate on anything you wrote?

And instead we should all use ???

Hello?