>We should accept that most famous CTOs, engineers and other "thought leaders" are not geniuses (also, they're often corrupted by financial interests)
That goes without saying!
That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.
I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...
> That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.
Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.
Other forms of serverless might save time. However there's always edge cases where they don't and you can lose hours or even days investigating an issue that would be a quick fix if you actually managed the host and/or application.
So the short answer is: not always faster nor easier. It really depends on what you're trying to accomplish.
> I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...
Actually yes they do. But like my previous answer, it depends on what you're trying to accomplish.
This is the problem with serverless (and cloud computing in general). People try to distil it down to "this is better for x" and "that is better for y" but actually the benefits and trade offs are far more granular than that. To the extent that you could have two companies in the same sector releasing competing products and still what architecture makes sense for one company might not for the other.
This is also why nobody ever agrees about these topics online - by the time you've generalised the examples enough to describe them in a forum post, they lose the specificity that makes any accurate design possible.
> Lambda can often actually add to development time because it takes more work to test locally and remote testing adds significant time to the write/test cycle.
This has not been my experience at all. Maybe because I have a lot of experience with Lambda, but I find them to be a very fast way to get code written and running.
Granted, Lambda is a great tool for a specific category of task. Namely, when you need to programmatically respond to some event which was triggered by another AWS service and can do so in under 5 minutes. But it's poorly suited for tasks outside of that domain. In that sense, it's like Bash: you don't want to do everything with it, but there are situations where it's the best tool.
Can't agree more. One example is CI/CD through docker image, building image / deploying container may take ten to thirty minutes long. It's a hindrance for quick bugfix / tempering on test server.
The real reality: not all devs required are webdevs, especially if you want to build an infrastructure that can handle millions of people worldwide. It's not like some React and CSS will get you that.
The amount you'll pay for a single additional developer, even if it's "just" 70K, is already close (if not double) your whole Clould costs when you start...
Yes. And there’s also the issue that even if someone would choose to work for free, incremental bodies in an org tend to increase the org’s complexity.
When you start you don't need to handle millions of customers worldwide. If all you need is to handle a million customers per month digitalocean can handle that on a single server and you wouldn't hire a single let alone many developers to manage that.
If you ever reach the point where you need to handle 100s of millions of customers a month / hiring someone can save you money but perhaps serverless makes sense.
That goes without saying!
That said, serverless might be 2x slower and 8x more expensive, but all that would be irrelevant if it's e.g. 10x easier, so that e.g. 1 programmer/ops guy can do what it took 10 before.
I don't think anybody uses things like AWS or serveless services because they're faster or cheaper...