[davidgf]

For the large majority of CRUD apps the least cost you should be concerned about is hosting, but development time. This kind of architecture adds an extra layer of complexity that is trivially solved with most of the web frameworks out there. I love Serverless, which I chose to design and build a couple of applications, but for some use cases it might not be the best solution.

[nzoschke]

I’m starting to find a FaaS architecture can remove complexity for the developer.

The CRUD functions themselves are easy to write and test.

Then everything else is handled by the infrastructure layer. Auth, security policies, rate limiting, request timeouts, autoscaling, logs, tracing, etc.

With Rails the developer has to build a lot of this into the application layer. And the dev has to do more operations over time to maintain the app and database.

I am working on a boilerplate app that demonstrates all the functionality you get from “serverless” and documents all of the things we no longer have to worry about:

https://github.com/nzoschke/gofaas

[davidgf]

Rails is a great framework that prevents you from dealing with a lot of boilerplate when it comes to web applications and to focus only on the business logic. There are some great platforms out there (Heroku, for example) that deal with most of the stuff you mentioned (logs, tracing, autoscaling, etc.), and no one prevents you from using a third party service for auth in Rails as well (Auth0, for example). FaaS is awesome, but you've got to code a lot of stuff that Rails gives you for free. Besides, pushing some logic down to infrastructure locks you in the provider you chose. I'm not saying that's bad, because as I've mentioned before I run some apps fully Serverless in AWS, but there's some stuff you've got to take into consideration.

[mseebach]

In my (limited) experience with Lambda, there's nothing inherently complex about it. Yes, there's a learning curve, as with anything, but that's a one-off cost. Once you know how, you write the function in a very similar environment you would in any non-serverless setup, and you call it like you would any API endpoint, serverless or not.

Once you have made this investment, you get scale (almost) for free (at least as concerns development/sys admin time). No need to worry about your $5 DO conking out in the middle of the night because you got Slashdotted or whatever the kids call it these days.

[davidgf]

Yes, once you get used to the development environment, coding Serverless is pretty smooth. However, when you need something a bit more convoluted than executing a single function, but rather orchestrating a bunch of them across different services, you have to think about stuff like service discovery. Making the right decisions and designing an event driven architecture is going to take time, which is worth money that could pay a lot of servers. With Serverless you get scalability almost for free, but there are trade-offs, so the first you should ask yourself if you're really going to need that scalability or would rather getting to market quicker. In some cases it makes more sense going for Serverless straight away, in some others just using the web framework you're experienced with and in some others a combination of both.