I work in projects which make heavy use of function-as-a-service, and I have first-hand accounts of how FaaS offerings have lead developers to waste a couple of weeks getting FaaS to do what could have been done in a couple of hours with a tried-and-true web service.
> But lambda is far from expensive.
Relatively to the cost of a VM instance? Yes, it's expensive. We're in a day and age where a vCPU with 2GB of RAM can be had for 3€/month, and the pricing examples posted on AWS Lambda's page show a scenario where slightly over a month of function run time requiring 512MB of RAM would cost around $18.
In addition, AWS lambda usage is rounded up in intervals of 0.1s and 128MB, thus inexpensive function calls are way overcharged.
> If you’re spending even $100 a month on lambda, you probably have a successful business.
This assertion is missing the fact that those $100 a month on lambdas might be handled by $10 worth of computational resources in the cloud and a software architecture that isn't convoluted or tied to a single vendor. Thus the fact is that a fad is being pushed without technical merit or sound operational reasoning.
We have a Jenkins server for builds. Most of the time, you push code and the build starts immediately. However, at times we have 10 builds in the queue and you’re sitting there waiting for your small build behind larger builds.
On the other hand, we’ve started moving to CodeBuild “Serverless builds”. When we aren’t running builds, we aren’t paying for it. However when crunch time comes, we can run up to 50 builds simultaneously (you can request a larger limit). How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle?
And if you’re worried about the difference in cost between $100 and $10, you’re not running a business.
Will that $10 a month server scale up with demand?
As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”. Don’t blame AWS for the missing skillset of your developers. There is no reason that it should take your developers any longer to build an API with lambda instead of a server.
In fact, you can host the same APIs with lambda by only adding two or three lines of code and using proxy integration.
For instance in Node:
The $100 vs $10 was not intended to argument the merit of $10 savings: it refutes the absurd claim that $100 expenditures justifies adopting a convoluted architecture, because the fact is not adopting a convoluted architecture is actually much cheaper.
Additionally, somehow you've brushed aside the fact that the main cost is developer time, and a convoluted solution based on flavor-of-the-month tech fads requires more maintenance and developer man-hours than basic tried-and-true solutions like standard run-of-the-mill web services.
> How much would it cost to have build servers that could handle peak demand and how much of a waste would it be to have that server sitting idle?
I honestly fail to see what point you're trying to make because: a) you don't need "serverless" services such as AWS lambdas to get CICD pipelines to work, and b) cluster autoscaling is a basic offering provided by pretty much all major cloud providers. Thus, what's your point?
> As far as it taking “two or three weeks” - “its a poor craftsmen who blames his tools”.
So any proof that refutes your baseless assertions is brushed aside by your "you're holding it wrong" baseless assertion? Doesn't sound like a discussion on technical merits.
You're underlining the biggest problem with buzzword-driven development: the lack of technical merit is a constant and everything boils down to petty personal politics.
If it takes your developers two weeks to host an API in a Lambda when I showed you a link on how simple it is. It says more about your developers than AWS.
My time is far from cheap and any time that we can spend letting someone else do the grunt work is valuable.
Real-world problems don't go away when you try to brush them aside. You either face the facts or remain in fantasy land.
> If it takes your developers two weeks to host an API in a Lambda
Please don't put words in other people's mouths. You have absolutely no idea about what the problems were and already made it quite clear that you don't care about facts or reality, and simply prefer to fabricate accusations to avoid discussing technical issues. That speaks volumes about your own competence and technical ability.
If your developer haven’t come up with processes to efficiently manage their development and deployment processes - it’s a process issue that others have already solved.
You did not. You fabricated accusations to fill gaps in your comprehension based on your imagination alone, and proceeded to use your made-up accusations to attack others. That's not cool, and just speaks volumes regarding your lack of arguments and your ability to contribute to a discussion.
I have first-hand accounts of how FaaS offerings have lead developers to waste a couple of weeks getting FaaS to do what could have been done in a couple of hours with a tried-and-true web service.
There is no world where a competent developer who knows his tooling should take “a couple of weeks” to set up an API on lambda that would only take “a couple of hours on a web server”.
You can treat a lambda instance just like a web server by using API Gateway, proxy integration and simple to use function provided by AWS that translates the lambda/APIGW event to a form that your framework expects.
Hosting static content on S3 (css, JS, html) is a click of a few buttons. Copying your content is a simple “aws s3 cp” command to do an “xcopy deployment”.
I refuse to work for any company at this point in my career that expects me to be on call to manage a bunch of pets.
How about getting paged at 2am because somehow a lambda called by AWS step functions workflow is failing due to hitting a timeout while uploading a 20MB file to a S3 bucket? Because this is an actual real world case that happened in the real world.
And everything is “complex” if you don’t know how to do it optimally.