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.
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 :)
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.
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).
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.
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.
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.
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-serve...
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
IME: It really depends. It's not a silver bullet, you HAVE to measure and calculate [1]. The pricing is transparent, so it's more predictable.
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.
If you plot cost vs usage on a graph, you’ll find the Lambda cost line starting at zero with a certain slope, and your AWS line starting at much higher than zero but with a slightly lower slope.
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 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.
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.
I mostly think of serverless as abstracting the actual way things run more and having a more specific contract than "exposes a port". I imagine this allows for deeper integrations and features like handling cold starts. It is difficult to mitigate a lot of these problems without a good contract/interface that allows it, and an arbitrary container doesn't really let you do that.
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.
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
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
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().
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).
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?
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.
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.