Ruby on Jets: Like Rails but serverless(github.com) |
Ruby on Jets: Like Rails but serverless(github.com) |
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.
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.
This is a really good point. Either I took a thorny path learning Lambda or they don't make it terribly obvious that when you pre-allocate larger amounts of RAM (thus more $$$ in GB/s cost) you also gain substantially better CPU performance.
So when you have a compute intensive task with a low memory footprint and want to improve latency, you may actually want to allocate lots of unused RAM.
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.
edit Yea the github activity is still pretty concerning. But Rails seems to be having a little bit of a renaissance so maybe it will pick up here also.
With ECS Fargate it costs money even without any traffic and you are responsible for correctly implementing auto scaling.
I'm coming from 10y rails dev background and now full stack typescript. Thinking in pure lambda functions is a breath of fresh air for me.
Ultimately though I don't think I'd use it beyond a proof of concept or without some sort of clear idea for how it will sustain itself.
All that to say: I guess it's been considered, but I don't have measurements handy. It's not unknown tho.
I like digital ocean, and I’d consider Hetzner, but AWS is pretty top notch outside of cost and their parent’s general biz practices.
It's an unhealthy situation to be fully dependent on 1 single provider. It creates monopolies (instead of diversity and choice) which means less freedom, and/or more corruption and unhealthy conditions for all involved.
I also think it’s generally a good business practice to keep the number of companies you depend upon as small as possible. Only being able to deploy to one cloud provider is like only having one customer. It can work, but it is risky.
0. https://www.protocol.com/enterprise/target-cio-mike-mcnamara... (Disclaimer: I work for Target but not currently on cloud stuff, though did previously)
Then again, I've managed to completely avoid serverless as I find it to be a pita when you want to do anything more complex than a trivial crud app.
Jets: Ruby Serverless Framework - https://news.ycombinator.com/item?id=19893796 - May 2019 (39 comments)
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.
Yes, as I tried to specify by qualifying "the project, not the noun" but I was on my phone so linking to github.com/mastodon/mastodon was more trouble than I thought necessary. Evidently not
> 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.
Understood, and the rails server running on some person's droplet is one trending link away from becoming a "popular instance." I believe Kris Nova's situation fell into that category. I'm not saying the mastodon/mastodon should change their deployment model to require Jets, but if Jets is mostly compatible with Rails, and mastodon/mastodon could write their Rails in a way that allows either deployment model, that seems like a win
I really don't want to be an AWS engineer. I like being able to host my own tools when I want.
Sorry for the rant, serverless stuff in general is cool.
As a followup... I'm curious if anyone can recommend solid opensource serverless runtime projects with decent management interfaces (CLIs are nice)? It would be neat if projects like Ruby on Jets could become "lambda-agnostic" for lack of a better tagline, if they're not already.
I’ve played with Ruby, but not enough to get invested. It wasn’t OOP at the level I was used to.
I do Elixir, and it’s the first time I’ve had those “this is so elementarily cool” feelings since my 10 year hiatus from Smalltalk. The thing I like least about Elixir is it’s use ruby-esque do/end and it’s quasi inclusion of new lines as a sometimes relevant syntactic element.
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...
As far as I understand it relies on .. AWS servers!
"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.
Whether this is more confusing or less presumably depends on how similarly you think to me.
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?
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.
Easy enough to restart the processes every once in a while
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, …
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.
Wouldn’t it be more cost effective to have one big address space than a lot of fine tuned ones? Even if you’re stateless, you could benefit from the fact that utilization spikes can be handled with less overall redundancy. Assuming the dollar cost is proportional per allocation.
> Omakase is a Japanese phrase, used when ordering food in restaurants, that means 'I'll leave it up to you' (from Japanese 'to entrust' (任せる, makaseru))
See the article:
"Rails is Omakase" by David Heinemeier Hansson on Dec 27, 2012
https://dhh.dk/2012/rails-is-omakase.html
> Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework.
Conversely, if you’re doing something like processing message queues and you don’t care about latency at all, serverless is perfect.
But lots of times a plastic bucket, even with a leak, is a better tool for the job than an extruder, mold, and warehouse full of polymer.
I had to build a parallel CI pipeline once that was like: when this, run a FaaS function, then when this that or whipesnicket, run one of these other functions, then run this thing that moves some things from here to there and posts the results to zulip chat.
I literally spent 2 hours in AWS docs, got to "ugh, don't wanna know this, unlikely to use again" and then spent one hour in the serverless docs building it that way, and then it ran for 4 years. (Last year, I finally replaced it with GitHub Actions.)
Admittedly this wasn't a profound and moving tale of heroic ops or anything, but the Serverless framework proved to be pretty nifty for my use case. (Haven't used it since, but would again in a similar circumstance.)
Like everything, no? This is akin to saying "All tautologies are tautological."
Your sentence preceding this one laid out some issues; you probably could have left it at that <shrug>.