Comment by pritambarhate | Hacker News Reader

Comment by pritambarhate | Hacker News Reader

This really is a new paradigm shift for relational databases. In general, on the DB side, you are not able to scale horizontally like application tier. So for the fear of degradation of service, most of us end up overprovisioning on the DB side. With Serverless, auto-scaling Aurora, I think things will change for the DB tier too.

The Serverless section in Aurora FAQ [1] is also worth reading. The main gotcha I think is:

>> Q: Why isn't my Aurora Serverless DB Cluster automatically scaling?

>> Once a scaling operation is initiated, Aurora Serverless attempts to find a scaling point, which is is a point in time at which the database can safely complete scaling. Aurora Serverless might not be able to find a scaling point if you have long-running queries or transactions in progress, or temporary tables or table locks in use.

So I think one will need to focus on quick OLTP type queries.

Still, I am quite excited to see how this shapes up.

[1]: https://aws.amazon.com/rds/aurora/faqs/

Yes, I think serverless is only possible now, because application developers are now familiar with infrastructure to a point that infrastructure provider and app developers can commonly understand the most crucial technical problems and tradeoffs involved in provisioning infrastructure.

I’ve found developers are more familiar with cloud based infrastructure than “infrastructure” people coming to AWS.

Everytime I’ve seen infrastructure people who came into AWS from an on prem type of mindset, they screw it up. One example is that they may have a Dev, UAT, and production environment instead of using separate accounts. That works okay as long as you aren’t doing anything but EC2 instances but as soon as you start doing anything else it gets complicated because most AWS resource names have to be unique across the account.

The 'main gotcha' seems like the common thing people always gloss over when using IaaS.

It solves already solvable problems (albeit with more specialised tools/people) with a 'magic' solution that works until it doesn't, and then requires even more specialised people to maybe solve it.

But that's the whole profit model for IaaS: offer 'magic' solutions that are worse than what a qualified ops team will build, for the same money, to small companies who dont actually need the bells and whistles, and hope that by the time they do need the bells and whistles they're locked into your platform too much to change when they inevitably realise they made a huge mistake.

Well, there is a general thing where small companies build a thing, and then they scale to the point where the thing doesn't work any more, and they have to make some changes.

History has taught me that accepting the inevitability of change is far better than trying to build a thing with so many features that it need never be changed.

In this particular case, I find it hard to believe that anybody will be "locked in" to a serverless SQL database in the same sense that, say, being a game company on top of iOS "locks you into the Apple Ecosystem," or writing your app in Rails "locks you into Ruby."

> I find it hard to believe that anybody will be "locked in" to a serverless SQL database

I didn't say that did I? AWS/GCP/Azure/etc as a whole, are platforms that companies become locked-in to, both technically and in terms of mindset.

I appreciate the skepticism, but "for the same money" is off base in my experience. Maintaining IaaS services costs much less when taking personnel expenses into account.

> Maintaining IaaS services costs much less when taking personnel expenses

In my experience the cost savings are because people assume that AWS means "I dont need Ops (any more)" and have developers with zero ops/sysadmin experience running their production environments.

There's a lot of us devs that have been at it long enough to have learned sysadmin and networking skills because we had to at the time. Older full stack devs. We don't need sysadmins for 99% of projects. AWS and other solutions work for us and save a lot of time. We know our way around it since we've been using it since it's infancy.

That being said, it can burn you. For an ETL platform I was developing cobbling it together with Lambda and other services was a nightmare. Things you'd expect to work didn't. And the cost was way too high for concurrency. So I went back to a single box with beanstalkd and common tools.

But I agree many go with a promised solution without the expertise and when it fails or gets hacked they're screwed. And those costs aren't factored in.

If we're not hosting and maintaining and the client doesn't have skillset in-house I'll have a client go to Rackspace or similar.

I’m a developer, but I can hold my own against most “AWS Architects”. Most of them only know netops and they don’t understand how the infrastructure decisions they make affect the other two portions of using AWS - devops and development.

It solves already solvable problems (albeit with more specialised tools/people) with a 'magic' solution that works until it doesn't, and then requires even more specialised people to maybe solve it.

Because no one ever had scaling issue before IaaS that required major architectural changes....

So I think one will need to focus on quick OLTP type queries.

True. Don’t use Aurora of any fashion for OLAP. That’s what Redshift is for.

Reply on news.ycombinator.com