[yoran]

I think the example you give is more because there's a mismatch between technologies, rather than the "fault" of serverless. In serverless, your endpoints become infinitely scalable. This doesn't go well when they're backed by technologies where there is a hard limit on the number of connections, for instance SQL servers or a Redis server. I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless "because it brings so many other issues". I think AWS has already started that with Amazon Aurora.

That aside, I agree that there are a lot of secondary concerns that are important when running things in production but that aren't available out-of-the-box when you run something on AWS Lambda. I'm thinking about error monitoring, performance monitoring, logging,... All those things need to be set up and that's quite time-consuming.

However, I think that's more due to serverless being relatively new and not as mature as the traditional way of doing. I don't think it will take long before we'll have the equivalent for serverless of adding `gem 'newrelic_rpm'` to your Gemfile and magically having performance and error monitoring across your app.

[rantanplan]

> I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless

Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises.

> I think AWS has already started that with Amazon Aurora.

Just in time when we were talking about fanfare. Spend 10-20 minutes searching on the Internets to see what actual experiences people have with it.

Its 3X write increase? Bollocks. Usually the performance is worse than when you administer your own DB(Postgresql/MySQL). You might(or not) see some read-performance increase, which... well everyone can scale on reads so I don't see the point.

I suspect it has other goodies pertaining to administration/provisioning, but performance/scaling is not one of them.

[athenot]

>> I think therefore that SQL database technologies have to adapt to the serverless paradigm rather than dismissing serverless

> Empty statement that means nothing. SQL/RDBMS is backed by computer science and robust engineering examples that make the world spin. Alternatives are usually full of fanfare and false promises.

Traditional relational databaases have indeed solved many issues that some newer datastores struggle with. But the flip side is that it is non-trivial to design traditional databases that are not Single Points Of Failure.

Storing data is surprizingly hard in a cloud environment, and involves trade-offs. Reaching a comprehensive solution (fast, HA, consistent, easily recoverable, scalable volum, evolvable schemas...) is hard no matter what technology you pick.

[justincormack]

Not being able to handle more than a few connections without connection pooling is nothing to do the using SQL. It is just a different bit of optimization that is needed to support fast transient connections without pooling.

[rawrmaan]

It just seems to me like the "infinite scalability" promise of serverless is only realistic if you have no database. Because inevitably, you'll hit database scaling issues due to query patterns and suboptimal indexes LONG before you'll have a hard time scaling up your fleet of servers because you're getting too many requests.

[zaarn]

I'd also like to see the AWS bill once you hit infinite scale. AWS is already pretty expensive on their own...