If cloud providers want to be seen like utility providers, they need to provide a simple pricing model analogous to Watt and kWh in electricity for users to be able to estimate costs easily.
I'm thinking about working on a solution to better understand and limit costs in AWS. Could I contact you to understand a bit more about what would be an ideal setup for you?
I have several mobile apps that I run literaly free because the Lambda usage is under the free tier and those I don't cost dollars a month. I am very happy with it in general.
There is of course the problem with any instant scaling metered service that if you are actively attacked you can rack up a large bill but there are monitoring systems that can be used to prevent that if you want (at the cost of taking down the service) or allow it to scale (at the cost of $$ but your customers stay happy).
Edit: It is worth noting (based on discussion below) that other posters are right. It is not for everyone. It has some major tradeoffs that you need to be aware of and plan around. But if the tradeoffs are OK (and I personally found they are for many of my projects) it is a great service.
Use DynamoDB if you are absolutely sure your database structure is perfectly optimized from the get go for the traffic you're going to receive. Your indexes and structure have to be absolutely perfect starting, because there's no good way to fix them later.
1. I agree. First few attempts at DynamoDB tables were a disaster. But once you get used to them you don't have to change schemas and then it is not an issue. Note, you can add and indexes, just not the primary one.
2. Not so. It's not easy but it's far from impossible or painful. I've had my fair share of pain migrating SQL databases too.
... Export to S3
... Grab the S3 backup and write an ETL to format and load it
... Put in place a stream hook to keep your newly loaded database up to date
... Switch over your data abstraction / model layer (you did use one of those right?)
3. You can also choose your indexes wisely. How is this different than a normal database?
Most of my DynamoDB using apps I run for 100% free and I've scaled to hundreds of thousands of users for less than the cost of a small Postgres server.
Just keep a model layer between you and Dynamo to avoid vendor lockin and you'll be fine.
You can also use Amazon RDS with Lambda which, while still a database "server" does not require you to manage the server yourself.
As a compromise I'd look to using MySQL or Postgres as a backend, and that being the only server I'm running, so that it's easier to move later (and so I still have access to a relational database). Except Lambda cold starts in a VPC are horrid, with no sign of change.
If you haven't looked into Lambda cold start problems, you're in for a treat. The main pitch for Lambda is for little utilized services, or services that need to scale fast, right? And in this example, you're using it to power an API? Imagine if the service is lightly used, whenever a user goes to hit the API for the first time, it takes 15 seconds to respond. Or worse, imagine if the service is getting popular, users get subjected to 15+ second response times every time Lambda has to start a new instance.
Although I did try to address some of your concerns in a reply to your other post.
What the heck are you doing for 15 second cold starts? I haven't seen more than a 1s overhead for cold starts with Node.js apps packed with webpack (more like 2 or 3s without webpack)
But yes, if the cold start time is unacceptable to you. Lambda is a terrible fit. But you have to ask yourself what is and is not acceptable. Especially in a mobile or single page app where you can eager load or do background requests.
It is not for everyone.
Another trick is to group similar functions together in the same code and have different API gateway endpoints go to the same Lambda. Using that method most apps I've made have less than 1% of requests hit a cold start situation.
Edit: for many apps 1% sold starts is unacceptable. And that's OK. Lambda isn't for you.