Live data from Hacker News

Ruby on Jets: Like Rails but serverless

github.com

61–70 of 92 posts

Re: Ruby on Jets: Like Rails but serverless

#61
post #41

Earlier quoted context omitted.

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?

I think it's more than you realize because it was more than I realized. It only takes getting burned by a cloud provider once to get the execs to notice, then they talk about lock-in, and the good ones try to avoid it. Plus, remember people move companies and take their knowledge with them. It's the kind of thing that gets talked about in CIO circles [0], so it's more than a tiny minority. 0. https://www.protocol.com…

In contrast to provider-native serverless solutions, cloud agnostic solutions carry a high price tag for the entire application life cycle in form of operations - those people petting your k8s. A common misconception regarding serverless applications is focusing on compute alone and in that context an agnostic solution may seem lucrative after traffic reaches certain threshold, justifying running a cluster 24/7. However many scalable application architecturs benefit from asynchronous processing and event-driven models which require reliable messaging infrastructure with considerable operational overhead. This is where serverless applications utilizing managed services shine, making it possible for small teams to deliver very impressive things by outsourcing the undifferentiated ops work to AWS. On the other hand, if the compute layer is the only lock-in-inducing component in your architecture, a properly architected application is relatively easy to migrate to a serverful model. As a crude simplification, just replace the API Gateway with Express.

Re: Ruby on Jets: Like Rails but serverless

#63

Earlier quoted context omitted.

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

I had to look up "omasake", but I admit I still don't understand its use in this context. ELI5?

It's "omakase" (in the words of Wikipedia) :

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

Re: Ruby on Jets: Like Rails but serverless

#65
post #44
post #30

"Like Rails but serverless ", I wonder what's their definition of servers? As far as I understand it relies on .. AWS servers!

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 t…

"Function Oriented Architecture" is how I think about it.

Whether this is more confusing or less presumably depends on how similarly you think to me.

Re: Ruby on Jets: Like Rails but serverless

#66
post #41
post #39

It looks like Ruby on Jets makes you 100% dependent on 1 company: AWS/Amazon; not an evolution I'd welcome.

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?

It’s not so much about actively using multiple providers, as building your application to be able to switch if you wanted.

Re: Ruby on Jets: Like Rails but serverless

#67
post #23
post #16

Earlier quoted context omitted.

Sure its a layer of abstraction but super leaky if you want to do anything meaningful.

Well for some values of "meaningful" OK, sure. 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 th…

I stopped using the Severless framework when CDK came out. For simple cases it's still fine I guess but a lot of time I found myself falling back to plain CloudFormation (ugh) or relying in plugins with questionable maintenance status. I would not recommend it for new projects and even AWS SAM makes applying some best practices like least privilege principle easier.

Re: Ruby on Jets: Like Rails but serverless

#68
maybe its just me but serverless seems ill suited for these heavy garbage collected languages. Since you're just spinning up a process shutting it down once it does its job, you're really wasting a lot of cpu cycles on building up the garbage collector. A lot of the overhead is fine when you're using a persistent instance where you can "warm the cache" so to speak. nodejs would be the edge of what I consider good for serverless. go is probably ok if you turned off the GC and rust would be ideal.

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.

Re: Ruby on Jets: Like Rails but serverless

#69
I wonder if this would help Mastodon (the project, not the generic term) since I thought the recent Twitter flight caused them scaling woes, but I don't know enough of the details to readily know if one lambda per route would help them or not

Re: Ruby on Jets: Like Rails but serverless

#70
post #69

I wonder if this would help Mastodon (the project, not the generic term) since I thought the recent Twitter flight caused them scaling woes, but I don't know enough of the details to readily know if one lambda per route would help them or not

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.

Post reply on HN