3 ms·

I was recently talking with some folks at an incubator about a website I was building, and one of the technical guys suggested I consider switching to serverles

I was recently talking with some folks at an incubator about a website I was building, and one of the technical guys suggested I consider switching to serverless before launching (and I thought it was a good suggestion). Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. This is purely anecdotal, but the majority of startups I've seen - including my own work - do not have the time or expertise to build out robust auto-scaling systems. They also don't have the money to dump onto a bunch of servers they can fall back to when needed. But auto-scaling is arguably more important for startups than for well-established companies. Thanks to the unpredictablity of some random high-visibility influencer or journalist sharing your product without notifying you, it's easy for smaller startups to suddenly get hit with traffic that they can't handle with whatever infrastructure they have in place. Sometimes you only get one shot, and if a hundred thousand people hit an empty 503 page on their first visit, they may not come back for another try. Serverless design greatly mitigates that problem.

BrentOzar 8y ago
> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. Only as long as you (like Amazon's post) don't have a relational database in that architecture graph. Serverless makes it way easier to scale your application server logic, but not necessarily your persistence layer. If you choose a relational database, you can run into peak load problems where you can't scale the database fast enough to meet huge spikes of load. It's completely up to you to either set a processing limit somewhere, or avoid persistence layers with peak scale problems. I look forward to the day when AWS Aurora Serverless Postgres is in GA, but until then, if you want to deal with really bursty loads (like suddenly going from zero to thousands of simultaneous requests scaled out across Lambda when an ad runs), you either have to manually scale things up ahead of time, or be prepared to deal with Aurora Postgres cluster failovers and outages. You can't go from zero to huge on the relational database side without minutes/hours of infrastructure changes (or huge ongoing bills for capacity you're not using.)
noink-com 8y ago
> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. But is that kind of scaling really the hard part? If you're already using AWS for example, it is trivial to set up an autoscaling group that will add more EC2 instances the keep up with the rate of traffic. IME, scaling data stores is the hard part of scalability. I'm not saying serverless doesn't make it a little easier, but it is a different tradeoff. AWS Lambda for example has a lot of limitations too. Maybe I'm interpreting your comment wrong, but I don't think it's fair to imply that serverless is the obvious choice for startups just because it helps overcome scalability.
- vazamb 8y ago
  I think the better scalability does not come from lambda itself but because you have to design for share-nothing concurrent executions from the start.

BrentOzar 8y ago

> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. Only as long as you (like Amazon's post) don't have a relational database in that architecture graph. Serverless makes it way easier to scale your application server logic, but not necessarily your persistence layer. If you choose a relational database, you can run into peak load problems where you can't scale the database fast enough to meet huge spikes of load. It's completely up to you to either set a processing limit somewhere, or avoid persistence layers with peak scale problems. I look forward to the day when AWS Aurora Serverless Postgres is in GA, but until then, if you want to deal with really bursty loads (like suddenly going from zero to thousands of simultaneous requests scaled out across Lambda when an ad runs), you either have to manually scale things up ahead of time, or be prepared to deal with Aurora Postgres cluster failovers and outages. You can't go from zero to huge on the relational database side without minutes/hours of infrastructure changes (or huge ongoing bills for capacity you're not using.)

noink-com 8y ago

> Serverless is an easy way for startups to overcome one of the harder technical challenges: scalability. But is that kind of scaling really the hard part? If you're already using AWS for example, it is trivial to set up an autoscaling group that will add more EC2 instances the keep up with the rate of traffic. IME, scaling data stores is the hard part of scalability. I'm not saying serverless doesn't make it a little easier, but it is a different tradeoff. AWS Lambda for example has a lot of limitations too. Maybe I'm interpreting your comment wrong, but I don't think it's fair to imply that serverless is the obvious choice for startups just because it helps overcome scalability.

vazamb 8y ago
I think the better scalability does not come from lambda itself but because you have to design for share-nothing concurrent executions from the start.