Serverless is a bad idea, it was designed to serve big infrastructure providers as a way to increase their lock-in factor but the benefits to software developers is negative.<p>Serverless is simple but opaque; it's great for making demo apps but not ideal for real production systems. It narrows down integration possibilities, complicates large-scale development and deployment, and often, it makes it more difficult to keep track of backend errors... In addition to this, it makes you fully dependent on a single infrastructure provider; it takes away all your leverage when negotiating hosting costs.<p>The control panels of some of these services have become so complex and elaborate that you'll be wishing that you could just SSH into the server directly.
This was also the biggest news of re:Invent for me. Total game changer. No need to provision large R instance types to support the batch processing that happens a 3AM and sits idle most of the time. All environmental tiers can have 100% the same configuration.<p>I know of some projects burning millions a month in database costs because they like to replicate environments for testing branches. Switching to serverless Aurora would reduce that cost to probably low thousands.<p>Of course it all depends on how quickly it can scale up to meet the load and I reserve full judgement till I can try it out, but am very interested in this.
The idea is exciting, but the pricing looks too high for side projects. The docs state "Aurora Serverless can scale from a minimum of 1 ACU to a maximum of 256 ACUs." Unless I'm reading this incorrectly, you are paying for 1 ACU 24 hours a day.<p>$0.06 * 24 * 365 = $525.60 per year.<p>This is more expensive than a low-end RDS instance. It's a shame, I immediately thought this would be the perfect solution for side projects and prototypes, but the pricing killed it.
I wish Amazon or Google would just make a simple key/value store to give minimal persistence for their serverless offerings. DynamoDB comes closest but it still overcomplicates things.
Am struggling to understand the concept of Serverless Aurora and AWS Lambda integration - they highlight that AWS Lambda would scale on traffic and there by Serverless Aurora kicks into support this scale - but there is a limitation on AWS Lambda inside a VPC[1].
So in order to really utilize the Serverless Aurora fully - the Proxy fleet would have special permission to access Aurora?<p>Also, has anyone solved the issue of AWS Lambda (in VPC) scaling beyond the limited IP space ?<p>[1]<a href="http://docs.aws.amazon.com/lambda/latest/dg/vpc.html" rel="nofollow">http://docs.aws.amazon.com/lambda/latest/dg/vpc.html</a><p>ENIs = Projected peak concurrent executions * (Memory in GB / 3GB)
This is super interesting to me on applications where I'm using Heroku's $50/month Postgres plan. Almost inevitably I find that the only reason I've upgraded past hobby level is for performance, not scaling. That it would auto-scale under load is just the icing on the cake.
It looks really great. The only concern I have (relative to other serverless features) is that it does have a top-end architectural limit (256 ACUs).<p>It's probably not worth fretting over, but it is worth mentioning when comparing to DynamoDB. That means in building a serverless web app, you might look at starting with Serverless Aurora, graduating to regular Aurora (as usage increases due to pricing), and then perhaps moving off workloads better suited to DynamoDB as you discover them.