This is one of the big deal-breakers for me. I find it much easier to build an application locally where I can test that things work. Next.js has somewhat alleviated that concern, wherein you can run the application locally on a server and then deploy it to the Vercel backend in “serverless” mode. But this still doesn’t solve the other big deal-breaker, which is vendor lock-in. Since there’s no real standard, each FaaS vendor tends to do things a little differently, and (as explained in the blog post) you tend to have to think about the domain in which the application is hosted rather than the domain in which the application provides value.
That said, these are similar problems to the ones we faced when cloud computing became popular. Perhaps the future holds a solution that all hosting providers can participate in, so it’s easy to not only stand up your application on any cloud provider, but also stand it up locally for development and testing. Kubernetes makes this really easy for traditional applications (well, easier than it was before at least), I wonder if it can be leveraged for FaaS as well…
Kubernetes makes this really easy for traditional applications (well, easier than it was before at least), I wonder if it can be leveraged for FaaS as well…
I was thinking along these lines a few days ago and fell over https://www.openfaas.com. Haven’t used it in anger, but it’s definitely interesting to see other people are skating in that direction already.
This isn’t really true though. If you use an intermediary like (serverless.com) you can usually spin up a local “offline” environment.
Also if you connect it up to a CI pipeline (like seed.run, or again serverless.com have something here) you can deploy a “development version” and run end to end tests there.
This article could be better described as: “I knew what I was doing in rails, I didn’t really know what I was doing in serverless” (I don’t mean that in a pejorative way, more just there is really good tooling for serverless stuff once you’re in that world, just like there is really good tooling for rails. I don’t see the drawbacks at all the same way that was expressing the article.
Caveat:
Yes there are problems when dealing with microservices (which even if you don’t intend to, you’ll end up factoring functions to be like microservices anyway).
Rails does have a bunch of “blessed defaults” which don’t exist in “Serverless” but you are comparing different levels of abstraction, level 3 isn’t as high as level 4.
What you described as a solution for this is way more complicated and clearly the author gave it an honest shot. It’s non-obvious and has poor penetration if it wasn’t apparent how to pull this off. I appreciate that there’s an elaborate dance you MAY be able to do to help, but like… it’s obviously more work.
I guess I don’t know Serverless, but was basing it on what you described. I don’t have to deploy a rails app at all to run it locally (a “development version”), so that’s worth something, but if you feel it’s roughly equivalent I’ll have to take your word on that. A “development version to run end to end tests” is not something I do in rails.
I actually really appreciate you sharing that workflow/tooling, though, that was a TIL for me and I like to learn new stuff. Cheers!
Serverless stuff kind of inherently wants to be deployed, because you are making use of features inside the cloud ecosystem (in AWS: SQS, S3, EventBridge, etc). So the work goes into replicating that stuff locally.
Rails stuff kind of inherently wants to be run locally with a rails s style command, because it brings its own ecosystem with it. So the work goes into replicating that stuff in a cloud/server environment.
But I wouldn’t call either amount more work that the other, but definitely a different skillset.
This is one of the big deal-breakers for me. I find it much easier to build an application locally where I can test that things work. Next.js has somewhat alleviated that concern, wherein you can run the application locally on a server and then deploy it to the Vercel backend in “serverless” mode. But this still doesn’t solve the other big deal-breaker, which is vendor lock-in. Since there’s no real standard, each FaaS vendor tends to do things a little differently, and (as explained in the blog post) you tend to have to think about the domain in which the application is hosted rather than the domain in which the application provides value.
That said, these are similar problems to the ones we faced when cloud computing became popular. Perhaps the future holds a solution that all hosting providers can participate in, so it’s easy to not only stand up your application on any cloud provider, but also stand it up locally for development and testing. Kubernetes makes this really easy for traditional applications (well, easier than it was before at least), I wonder if it can be leveraged for FaaS as well…
I was thinking along these lines a few days ago and fell over https://www.openfaas.com. Haven’t used it in anger, but it’s definitely interesting to see other people are skating in that direction already.
This isn’t really true though. If you use an intermediary like (serverless.com) you can usually spin up a local “offline” environment.
Also if you connect it up to a CI pipeline (like seed.run, or again serverless.com have something here) you can deploy a “development version” and run end to end tests there.
This article could be better described as: “I knew what I was doing in rails, I didn’t really know what I was doing in serverless” (I don’t mean that in a pejorative way, more just there is really good tooling for serverless stuff once you’re in that world, just like there is really good tooling for rails. I don’t see the drawbacks at all the same way that was expressing the article.
Caveat:
Also, if you want serverless AND rails: Ruby on Jets is a thing. (https://rubyonjets.com/)
What you described as a solution for this is way more complicated and clearly the author gave it an honest shot. It’s non-obvious and has poor penetration if it wasn’t apparent how to pull this off. I appreciate that there’s an elaborate dance you MAY be able to do to help, but like… it’s obviously more work.
Which part of it was “obviously more work”?
sls offlineandsls deployis hardly an “elaborate dance”. In fact, what’s the shortcut to deploy a rails app? (hint: there isn’t one).I guess I don’t know Serverless, but was basing it on what you described. I don’t have to deploy a rails app at all to run it locally (a “development version”), so that’s worth something, but if you feel it’s roughly equivalent I’ll have to take your word on that. A “development version to run end to end tests” is not something I do in rails.
I actually really appreciate you sharing that workflow/tooling, though, that was a TIL for me and I like to learn new stuff. Cheers!
I think there is an important perspective here:
Serverless stuff kind of inherently wants to be deployed, because you are making use of features inside the cloud ecosystem (in AWS: SQS, S3, EventBridge, etc). So the work goes into replicating that stuff locally.
Rails stuff kind of inherently wants to be run locally with a
rails sstyle command, because it brings its own ecosystem with it. So the work goes into replicating that stuff in a cloud/server environment.But I wouldn’t call either amount more work that the other, but definitely a different skillset.
In a previous, long-gone era, there were ancient people that meant two different things when they used the two terms “Rails” and “Ruby”.
That was back when Ruby got used for things other than Rails. :-(