4 ms·

I've been using most of these services since they launched and I can say that as a whole they are significantly cheaper to both run and develop until you get to

by throwaway2016a 9y ago

I've been using most of these services since they launched and I can say that as a whole they are significantly cheaper to both run and develop until you get to very large scale at which point the code transfers to real servers pretty easily. 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.

polskibus 9y ago
I'm curious, what do those apps do? Surely they need a database behind the severless layer? If so, is the database also on some kind of free tier? I'm mostly interested in TCO kind of calculators for cloud computing, not calculators on a per service-type basis.
- joecot 9y ago
  DynamoDB, which is Amazon's serverless NoSQL database offering. If your service takes off, it's also the guaranteed source of a serious amount of cash for the company. If you get big while on DynamoDB, 1) it's near impossible to restructure to optimize your tables, 2) it's near impossible to migrate off of without serious pain, 3) your only method of controlling performance is sliding read/write throughput meters for your tables (ie, paying them more money). DynamoDB is not a service I'd be comfortable locking into. 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.
  - throwaway2016a 9y ago
    I value your opinion but I have had a very different experience. 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.
- throwaway2016a 9y ago
  They are mobile apps with logins, account management, social network functionality. DynamoDB as a key/value store with Elasticsearch for anything that requires, well, search. You can also use Amazon RDS with Lambda which, while still a database "server" does not require you to manage the server yourself.
joecot 9y ago
The code for Lambda and API Gateway can be moved to servers easily enough, yes. Switching away from using DynamoDB as a backend store, though, not so much. That would be quite a migration. 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.
- throwaway2016a 9y ago
  DynamoDB does have its drawbacks and I agree it is far from perfect. But you also don't have to use Dynamo. Lambda can connect to other databases too. Although I did try to address some of your concerns in a reply to your other post.
- throwaway2016a 9y ago
  > If you haven't looked into Lambda cold start problems, you're in for a treat. 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.
  - joecot 9y ago
    If you're cold starting in the public cloud, Lambda can start in 1s. If you're cold starting Lambda functions with a VPC NIC (which you would need to do if you're trying to connect to a MySQL server), it can take 10-15+ seconds. The issue is provisioning the network interface, not any manner of packing the code.

polskibus 9y ago

I'm curious, what do those apps do? Surely they need a database behind the severless layer? If so, is the database also on some kind of free tier? I'm mostly interested in TCO kind of calculators for cloud computing, not calculators on a per service-type basis.

joecot 9y ago
DynamoDB, which is Amazon's serverless NoSQL database offering. If your service takes off, it's also the guaranteed source of a serious amount of cash for the company. If you get big while on DynamoDB, 1) it's near impossible to restructure to optimize your tables, 2) it's near impossible to migrate off of without serious pain, 3) your only method of controlling performance is sliding read/write throughput meters for your tables (ie, paying them more money). DynamoDB is not a service I'd be comfortable locking into. 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.
- throwaway2016a 9y ago
  I value your opinion but I have had a very different experience. 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.
throwaway2016a 9y ago
They are mobile apps with logins, account management, social network functionality. DynamoDB as a key/value store with Elasticsearch for anything that requires, well, search. You can also use Amazon RDS with Lambda which, while still a database "server" does not require you to manage the server yourself.

joecot 9y ago

The code for Lambda and API Gateway can be moved to servers easily enough, yes. Switching away from using DynamoDB as a backend store, though, not so much. That would be quite a migration. 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.

throwaway2016a 9y ago
DynamoDB does have its drawbacks and I agree it is far from perfect. But you also don't have to use Dynamo. Lambda can connect to other databases too. Although I did try to address some of your concerns in a reply to your other post.
throwaway2016a 9y ago
> If you haven't looked into Lambda cold start problems, you're in for a treat. 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.
- joecot 9y ago
  If you're cold starting in the public cloud, Lambda can start in 1s. If you're cold starting Lambda functions with a VPC NIC (which you would need to do if you're trying to connect to a MySQL server), it can take 10-15+ seconds. The issue is provisioning the network interface, not any manner of packing the code.