Jets: Ruby Serverless Framework
rubyonjets.com
rubyonjets.com
I really love this and I feel the JS and Go Serverless communities could pick up a few tips on developer friendliness from the Ruby community.
It would be interesting to see a direct comparison with what's actually different from Rails. I saw some a few notes in the docs but not a high-level rundown.
Also interesting, was this forked from Rails or written from scratch to mimic the API? It doesn't look like a fork from just reading the source, as the code is organized a bit differently, but the API is such an exact match I can't help but wonder :)
I sincerely hope to get to work with this stuff soon; no use case for me at present.
You can do that with containers and VMs too. Potentially with fewer worries about cold start latency (at least with Lambda).
Write a function and deploy it. Want that function exposed via an API? Easy. Want it to be fired in response to an object being uploaded to S3? You can do that too. All it’s concerned with is inputs and outputs. How you compose them is up to you. And if the there’s zero need for a function to be running it’s not running, you’d don’t have ECS containers sitting around idle waiting for work.
The trade off atm is visibility into how & where exactly a given function is being used within a codebase(s).
I'm eager to try implementing our application in Jets to compare it to the Serverless Framework implementation. It'd be nice to stand up an application on AWS as easily as we build a Rails application and deploy to Heroku. That said, maybe after figuring out how to use the Serverless Framework, there's not much reason to use Jets. I'm curious.
To get a large Rails app operational on Lambda, Jets is the way to go.
* Paying only for compute time/requests, if the API is not being accessed for a period of time, it's free - on a regular instance, you'd be paying for idle time
* Automatic scaling
* Simple deployment
The downsides include:
* Irregular response times due to cold containers
* Slower request/response cycle due to overhead in Lambda + API Gateway
It just feels like silly buzzword garbage that locks you in further to AWS.
Another point of contention in my view is the fact that either they'll lock it down like they do on those online "computing environments" where you can't do any low level stuff or any networking (like IDEone, etc), or it'll be too open and thus you can use it to spread malware, or run DDOSes.
I guess that it makes sense that such an offering is present in the modern ecosystem among many other offerings but other than the interest of completeness, I don't really see the value-add. But I'm just a random engineer on the internet, I probably am not representative of all potential use-cases
It's similar to buildpacks on Heroku. How are they all that different from containers? Well, Heroku runs buildpacks in their own container system, so they're not much different, but Heroku can more easily control updates to packages and the base OS of their containers by not allowing you to run arbitrary container images.
In the end, I think of these as higher level abstractions, often building upon containers, but not allowing as much flexibility so the "serverless runtime" can optimize more things.
- virtual machines abstracted away physical hardware administration
- containers abstracted away the operating system administration
- FaaS server-less abstracts away the container and/or container orchestration
Serverless means you don't need to think about scaling and managing a cluster
My experience with single-function lambdas in JS was very positive, because they're quick to run and don't consume too much memory. They're also quicker to write and to publish, IMO. Some apps are virtually free to run.
Bloated-but-low-traffic enterprise apps are also a good fit, because the low traffic offsets the memory/execution time. I think Microsoft is in a great position here, because of Azure.
Customer facing app using an MVC framework? No way. Even Heroku can be 100x to 1000x cheaper.
[1] Here's a calculator: http://serverlesscalc.com
The lines will always intersect at some point, but depending on your load the intersection point will often be too far away to care. The costs of devops and maintenance and scaling will also drive the AWS line higher and the intersection point further away.
I used it on a project last year, with AWS Lambda, not really impressed, specially the whole workflow.
You either use a bare bones IDE, or need to integrate AWS Shell into your CLI, with basic zip as packages build by yourself, including handling third party dependencies.
No debugger integration beyond plain old console.log().
At least there is Cloud Run, and personally I think that is a better option than FaaS.
Routing, CloudFormation deployment, running locally, IAM management, environments, auth/CORS, database packages, sharing resources, error handling – a few examples.
We don't need to keep two machines alive, one each in two different availability zones to provide the bare minimum uptime. Not if any controller action can quickly be given part of a machine on which to execute. There is no uptime or downtime, other than that of the service administering this fleet of machines.
This seems potentially useful though run through server less without Jet to under stand the knitty gritties of the server less architecture
"Ruby and Lambda splat out a baby and that child's name is Jets."