Costs are not apples-to-apples
Most folks who point out that Serverless is expensive are often failing to adequately consider the alternatives.
Sure, processing a workload on Serverless might cost more than processing the equivalent workload on dedicated hardware... but if you wish to make an effective comparison you must consider what indirect costs are eliminated by Serverless...
In order to build, code, deploy, and run a typical server-side commercial workload on dedicated hardware, involving file and data, you will need the following people (or skills):
- Linux system administrator
- networking engineer
- security specialist
- database administrator
- software developer
Most systems of any size need these people around continuously. If you provide a mission critical service, then that's a minimum of 3 of each, operating across timezones to cover the clock, 24/7/365. And that's the bare minimum! An expensive exercise.
On top of those people costs, you also need additional hardware (hot-swap, cold-swap, etc), boxes of brand new spare parts for every piece that could fail, firewalls, network redundancy, etc.
If you want to then SCALE this workload, you need a similar list of people, but usually with decades more experience, and you generally have to re-write the system from scratch to be stateless anyway. If you don't, you can't scale past one big box. To scale you'd also need to add load balancers, external storage devices, external databases, etc, along with all the specialised skills needed to keep them up to date and running. Also 24/7/365.
The traditional model starts with all those massive costs from day one, and you need to maintain them regardless of the popularity of the product. Your costs in the first year for all those people and resources are probably going to be about the same for 10 users as they are for 100,000. You can also expect a fair bit of downtime: failures are more common in systems grown over time that are built on increasing dependence on a fragile combination of settings highly specific to one particular hardware and OS configuration.
By contrast, a Serverless commercial back-end with similar workload, only needs a software developer, or maybe also database administrator. And you don't need them 24/7 - you only need them when you want to add new features. A well-architected Serverless project already scales as part of its basic nature. You pay per execution of your code, so you know that costs will scale together with the popularity of your product. Management generally like this predictable model. Your workload runs completely statelessly, so you know that when it runs tomorrow it will be working the same as it does today. If something suddenly behaves differently, there is no need to send engineers to troubleshoot the problem, because it is probably something your software developer needs to solve.
The Serverless model starts with minimal infrastructure and people costs. When you have 10 users for your first 6 months pre-launch, infrastructure will probably be free, or perhaps a couple of dollars per month.
Additionally, sensible Serverless architecture lends itself to support good design patterns from the outset. Individually scalable microservices, for example, can be a huge reducer of running costs, but can take a lot of time, people, and energy to get right in a traditional environment.
And as for vendor lock-in: a sensible Serverless system should be built with a wrapper that makes it portable, so if you think AWS's latest price drop didn't quite go far enough, just flick a switch and run your workload on Azure.
Bottom line is that Serverless done right can save millions.