14 ms·

Jets: Ruby Serverless Framework

159 points by alfonsodev 7y ago

burlesona 7y ago
This is interesting. It's obviously designed to look and feel just like Rails, and with "afterburner" can deploy Rails apps to lambda. 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 :)
- nateberkopec 7y ago
  Rails is a dependency: https://github.com/tongueroo/jets/blob/master/jets.gemspec#L30 https://github.com/tongueroo/jets/blob/master/jets.gemspec#L...
  - burlesona 7y ago
    Splitting hairs, but from the gemfile it looks more like bits of rails are dependencies.
  - intertextuality 7y ago
    That's not rails, that's a few of rails' core components.
- PopeDotNinja 7y ago
  I haven't played w/ Lambda, or serverless, much yet. I've always imagined it being used for quick & dirty functions that too trivial to warrant a full blown application. Is there a compelling case for deploying a full-blown Rails app in a lambda, especially when something when deploying a Rails app in a container on ECS is fairly straight forward? That sounds like a lot of code for something that sounds a lot like a simpler function call.
  - jackfraser 7y ago
    It's all about scalability. With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can scale from minimal to maximal without any intervention whatsoever, and only for the hot parts of your code. Deployment is even more refined than with containers. I sincerely hope to get to work with this stuff soon; no use case for me at present.
    - inferiorhuman 7y ago
      With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can do that with containers and VMs too. Potentially with fewer worries about cold start latency (at least with Lambda).
      - davidjnelson 7y ago
        Fargate is an interesting sort of middle ground.
  - glenngillen 7y ago
    The biggest benefit to me has been about flexibility and the shift to a more event-driven way of writing and scaling apps. Which together seem to evolve into a more functional programming like approach to services communicating. 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).
xrd 7y ago
I'm not sure of this tagline but: "Ruby and Lambda splat out a baby and that child's name is Jets."
rohindaswani 7y ago
I lol'd so much after reading the name. I was just building a test server less app in Ruby with Aws to figure out how it works. This seems potentially useful though run through server less without Jet to under stand the knitty gritties of the server less architecture
drewcoo 7y ago
Is this a slant reference to the Frank Zappa album? https://en.wikipedia.org/wiki/Cruising_with_Ruben_%26_the_Jets https://en.wikipedia.org/wiki/Cruising_with_Ruben_%26_the_Je...
- 22c 7y ago
  If it is, I like the other Zappa tie in: https://www.zappa.io https://www.zappa.io
stretchwithme 7y ago
Been thinking about such possibilities. With the advent of serverless, what executes a controller action does not need to be a server executing every other controller action in an application. 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.
arthurcolle 7y ago
Anyone using serverless frameworks: is it actually any cheaper, practically speaking?
- djsumdog 7y ago
  I still don't understand the difference between serverless vs just a Docker container. You still have to define your dependencies and entrypoints. Most serverless stuff runs in some type of abstraction behind the scenes (a container or some other chroot/namespace). It just feels like silly buzzword garbage that locks you in further to AWS.
  - akvadrako 7y ago
    Serverless and Docker containers are orthogonal. On some clouds, like IBM and I think Azure, you can even run Docker containers on the serverless infra. Serverless means you don't need to think about scaling and managing a cluster
  - arthurcolle 7y ago
    Pretty much my evaluation as well. Maybe it could be useful for arbitrary compute operations that you aren't entirely sure how long will take to run? Like computing an implied vol surface "all at once" when you don't own your own data center or something and aren't doing it all the time. 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
  - jonthepirate 7y ago
    We used serverless/lambda to run our flask app for flaptastic.com. Since the site doesn't see a lot of web traffic, our web costs are roughly $0 per month whereas running any kind of long running web server platform (docker or otherwise) has fixed costs.
ryanmarsh 7y ago
I’ve been using Serverless for a while. Having almost 10 years of familiarity with Ruby on Rails I knew the Ruby community would do something great in this space. AWS Lambda took, what feels like, forever to get official Ruby support. 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.
bigtunacan 7y ago
What's the advantage of this over just using the existing AWS SAM with Ruby and your current favorite framework like Rails or Sinatra?
- pjmlp 7y ago
  Pimping up the CV.
- thomasedwards 7y ago
  You don’t have to write boilerplate code that you use in every project. Routing, CloudFormation deployment, running locally, IAM management, environments, auth/CORS, database packages, sharing resources, error handling – a few examples.
faizshah 7y ago
I wish GCP would bring ruby support for cloud functions. Their ruby client libs are the best out of the languages I have tried for GCP (JS, python, PHP).
- akvadrako 7y ago
  They should just support Docker and be done with it. I mean you can already hack any runtime you want to run on cloud functions by just including the required binaries in your package – why should it be so difficult to support it officially?
  - gizzlon 7y ago
    Maybe Cloud Run can fill the gap? https://news.ycombinator.com/item?id=19616265 https://news.ycombinator.com/item?id=19616265 ?
- ksec 7y ago
  For some reason both Google and Amazon folks dislike Ruby. So I guess it will never be a top priority. At least there is Cloud Run, and personally I think that is a better option than FaaS.
logandk 7y ago
For things like simple Sinatra APIs, a light-weight alternative is https://github.com/logandk/serverless-rack https://github.com/logandk/serverless-rack (a plugin for https://serverless.com https://serverless.com, I'm the maintainer.) To get a large Rails app operational on Lambda, Jets is the way to go.
- celticninja 7y ago
  What are the benefits of it being operational on Lambda?
  - logandk 7y ago
    The merits of deploying a complex Rails app on Lambda are debatable, mainly due to the fact that larger code bases will result in slower cold request times for Lambda functions. For HTTP APIs in general, however, the three main benefits of being operational on Lambda are: * 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
- bigtunacan 7y ago
  What is the advantage of serverless-rack over using AWS SAM? A quick glance at your project seems like it has a similar general intent, but without the official backing/support of Amazon.
  - logandk 7y ago
    Indeed, SAM and serverless framework serve the same overall purpose. It's mostly a matter of whether you prefer CloudFormation (SAM) or serverless' configuration format. I have mostly used serverless, but there are some posts out there comparing the two in detail, such as: https://sanderknape.com/2018/02/comparing-aws-sam-with-serverless-framework/ https://sanderknape.com/2018/02/comparing-aws-sam-with-serve...
DanielKehoe 7y ago
I just built a tiny application in Ruby for AWS Lambda using the Serverless Framework. It's a fallback application that only needs to catch SMS messages from Twilio when our main application falls down. So a perfect fit for always available but seldom running and cold starts shouldn't matter. I implemented services such as a cron job and sending email (for a daily administrative report) in just a line of two of code. Compared to Rails, there's hardly any code. But compared to Rails, there's a lot of configuration of infrastructure (in one serverless.yml file) and it wasn't easy to find blog posts or examples. Implementing logging? Shouldn't be difficult but it was because of the AWS permissions structure. Ruby gems? Complicated especially for any that have native extensions. And yes, Amazon and Serverless have documentation but the wonderful Rails community has created much richer resources for solving every little problem. 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.

159 points by alfonsodev 7y ago

This is interesting. It's obviously designed to look and feel just like Rails, and with "afterburner" can deploy Rails apps to lambda. 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 :)

nateberkopec 7y ago
Rails is a dependency: https://github.com/tongueroo/jets/blob/master/jets.gemspec#L30 https://github.com/tongueroo/jets/blob/master/jets.gemspec#L...
- burlesona 7y ago
  Splitting hairs, but from the gemfile it looks more like bits of rails are dependencies.
- intertextuality 7y ago
  That's not rails, that's a few of rails' core components.
PopeDotNinja 7y ago
I haven't played w/ Lambda, or serverless, much yet. I've always imagined it being used for quick & dirty functions that too trivial to warrant a full blown application. Is there a compelling case for deploying a full-blown Rails app in a lambda, especially when something when deploying a Rails app in a container on ECS is fairly straight forward? That sounds like a lot of code for something that sounds a lot like a simpler function call.
- jackfraser 7y ago
  It's all about scalability. With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can scale from minimal to maximal without any intervention whatsoever, and only for the hot parts of your code. Deployment is even more refined than with containers. I sincerely hope to get to work with this stuff soon; no use case for me at present.
  - inferiorhuman 7y ago
    With serverless, you can have your functions running on machines all over the world, at the network edge closest to your end user. You can do that with containers and VMs too. Potentially with fewer worries about cold start latency (at least with Lambda).
    - davidjnelson 7y ago
      Fargate is an interesting sort of middle ground.
- glenngillen 7y ago
  The biggest benefit to me has been about flexibility and the shift to a more event-driven way of writing and scaling apps. Which together seem to evolve into a more functional programming like approach to services communicating. 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).

xrd 7y ago

I'm not sure of this tagline but: "Ruby and Lambda splat out a baby and that child's name is Jets."

rohindaswani 7y ago

I lol'd so much after reading the name. I was just building a test server less app in Ruby with Aws to figure out how it works. This seems potentially useful though run through server less without Jet to under stand the knitty gritties of the server less architecture

drewcoo 7y ago

Is this a slant reference to the Frank Zappa album? https://en.wikipedia.org/wiki/Cruising_with_Ruben_%26_the_Jets https://en.wikipedia.org/wiki/Cruising_with_Ruben_%26_the_Je...

22c 7y ago
If it is, I like the other Zappa tie in: https://www.zappa.io https://www.zappa.io

stretchwithme 7y ago

Been thinking about such possibilities. With the advent of serverless, what executes a controller action does not need to be a server executing every other controller action in an application. 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.

arthurcolle 7y ago

Anyone using serverless frameworks: is it actually any cheaper, practically speaking?

djsumdog 7y ago
I still don't understand the difference between serverless vs just a Docker container. You still have to define your dependencies and entrypoints. Most serverless stuff runs in some type of abstraction behind the scenes (a container or some other chroot/namespace). It just feels like silly buzzword garbage that locks you in further to AWS.
- akvadrako 7y ago
  Serverless and Docker containers are orthogonal. On some clouds, like IBM and I think Azure, you can even run Docker containers on the serverless infra. Serverless means you don't need to think about scaling and managing a cluster
- arthurcolle 7y ago
  Pretty much my evaluation as well. Maybe it could be useful for arbitrary compute operations that you aren't entirely sure how long will take to run? Like computing an implied vol surface "all at once" when you don't own your own data center or something and aren't doing it all the time. 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
- jonthepirate 7y ago
  We used serverless/lambda to run our flask app for flaptastic.com. Since the site doesn't see a lot of web traffic, our web costs are roughly $0 per month whereas running any kind of long running web server platform (docker or otherwise) has fixed costs.

ryanmarsh 7y ago

I’ve been using Serverless for a while. Having almost 10 years of familiarity with Ruby on Rails I knew the Ruby community would do something great in this space. AWS Lambda took, what feels like, forever to get official Ruby support. 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.

bigtunacan 7y ago

What's the advantage of this over just using the existing AWS SAM with Ruby and your current favorite framework like Rails or Sinatra?

pjmlp 7y ago
Pimping up the CV.
thomasedwards 7y ago
You don’t have to write boilerplate code that you use in every project. Routing, CloudFormation deployment, running locally, IAM management, environments, auth/CORS, database packages, sharing resources, error handling – a few examples.

faizshah 7y ago

I wish GCP would bring ruby support for cloud functions. Their ruby client libs are the best out of the languages I have tried for GCP (JS, python, PHP).

akvadrako 7y ago
They should just support Docker and be done with it. I mean you can already hack any runtime you want to run on cloud functions by just including the required binaries in your package – why should it be so difficult to support it officially?
- gizzlon 7y ago
  Maybe Cloud Run can fill the gap? https://news.ycombinator.com/item?id=19616265 https://news.ycombinator.com/item?id=19616265 ?
ksec 7y ago
For some reason both Google and Amazon folks dislike Ruby. So I guess it will never be a top priority. At least there is Cloud Run, and personally I think that is a better option than FaaS.

logandk 7y ago

For things like simple Sinatra APIs, a light-weight alternative is https://github.com/logandk/serverless-rack https://github.com/logandk/serverless-rack (a plugin for https://serverless.com https://serverless.com, I'm the maintainer.) To get a large Rails app operational on Lambda, Jets is the way to go.

celticninja 7y ago
What are the benefits of it being operational on Lambda?
- logandk 7y ago
  The merits of deploying a complex Rails app on Lambda are debatable, mainly due to the fact that larger code bases will result in slower cold request times for Lambda functions. For HTTP APIs in general, however, the three main benefits of being operational on Lambda are: * 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
bigtunacan 7y ago
What is the advantage of serverless-rack over using AWS SAM? A quick glance at your project seems like it has a similar general intent, but without the official backing/support of Amazon.
- logandk 7y ago
  Indeed, SAM and serverless framework serve the same overall purpose. It's mostly a matter of whether you prefer CloudFormation (SAM) or serverless' configuration format. I have mostly used serverless, but there are some posts out there comparing the two in detail, such as: https://sanderknape.com/2018/02/comparing-aws-sam-with-serverless-framework/ https://sanderknape.com/2018/02/comparing-aws-sam-with-serve...

DanielKehoe 7y ago

I just built a tiny application in Ruby for AWS Lambda using the Serverless Framework. It's a fallback application that only needs to catch SMS messages from Twilio when our main application falls down. So a perfect fit for always available but seldom running and cold starts shouldn't matter. I implemented services such as a cron job and sending email (for a daily administrative report) in just a line of two of code. Compared to Rails, there's hardly any code. But compared to Rails, there's a lot of configuration of infrastructure (in one serverless.yml file) and it wasn't easy to find blog posts or examples. Implementing logging? Shouldn't be difficult but it was because of the AWS permissions structure. Ruby gems? Complicated especially for any that have native extensions. And yes, Amazon and Serverless have documentation but the wonderful Rails community has created much richer resources for solving every little problem. 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.