Serverless Aurora
serverless.com
serverless.com
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.
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.
As an example, for a tiny side-project, I don't care about the markup or lock-in, I just want my code to run an unknown, small number of times per day for a cost-effective total price and a low cognitive and support overhead on me.
For example, I used Amazon Elastic Transcoder to do video compression/transcoding at a previous company thinking that we would save a lot of time but the API wasn't great; a lot of the default settings weren't right for our use case and the API and notification flow was way more complicated than it needed to be and prone to errors (due the the sheer complexity of input parameters it could handle).
At one point, we had a problem receiving SNS notifications from the transcoder and we didn't know what was causing it because we couldn't effectively access/browse the error log and was was exposed to us wasn't detailed enough. Basically the visibility in Amazon-land wasn't great.
We had to pay Amazon for special support so that they would tell us what the error was (after weeks of back-and-forth).
Now that it's all running, it's fine; so long as we don't need to change anything and don't need to start scaling up/sharding the pipelines; no sure how to do this through their UI.
If anyone thinks that is wrong or has an argument supporting it or against it, just point it out. I don't think this is worthy of replyless downvotes.
If I JDBC into this sort of infrastructure, how does that make me dependent on AWS? It's just a different pricing model and management style. Nothing more, nothing less.
(I'm not underestimating this service, quite the contrary, I think it's very neat for people without DevOps and/or frequent load.)
Except you'll probably have different performance constraints and have to architecture your code accordingly. True decoupling is pretty hard to achieve.
While the application is still very profitable, the cost is ~10x its implementation on traditional servers. I'm not going to argue the pro's and con's, just providing some numbers. At this point, we're working to optimize the original stack in order to reduce costs.
I will say though...honestly, working with Serverless and the AWS stack is a very pleasant experience.
Can you talk about the cost of your development time (one of the premises of serverless is increased developer productivity)?
Again, thanks for the real world numbers--always nice to see them.
Development time was roughly the same: frontend work was identical to a standard enterprise-grade SPA app and backend is all Lambda functions, which would've been implemented similarly on, for example, NodeJS and Express (which is what as done anyway for testing).
The primary cost (~60%) is due to the high volume of API Gateway requests. (Edit: see below comment for reason and plans to optimize)
Edit:
A HUGE time saving comes from being able to orchestrate AWS infrastructure easily via API and is well worth the premium in most cases. Our frontend application performs many automated management tasks of AWS resources such as S3, CloudFront, Lambda, Route53, etc... This of course does not directly relate to "Serverless," as it may be done by any application able to make API calls to AWS, however just the fact that it's possible for these resources is very appealing to a multi-hat developer with limited time on a side project.
The GraphQL API is backed by DynamoDB and is served via API Gateway. The frontend was built using ReactJS and Relay. I am currently seeing anywhere from 200-450ms per GraphQL request on the frontend, which is more than acceptable as it's just a management frontend application...and of course it may be optimized using techniques such as prerendering, caching, etc...but these applications being super optimized is not a requirement.
I can confirm a couple things. It seems like we spend a bit more time getting things to work as expected.
Troubleshooting can get expensive given the system disappears.
Telemetry on the lambdas needs to improve. Finding what’s eating time gets tough when you are looking to optimize. (A lot baked in to this statement but getting 800ms of compute to 400ms is sometimes important whilst staying on lambda)
We're currently working on migrating the event collectors to a pure CloudFront based solution (inspired by SnowPlow) where the events will be submitted to CloudFront via signed GET requests and the CF logs will be streamed to the same Lambda-based processing pipeline. Doing this will eliminate almost all of the overhead of API Gateway (still required for certain events that cannot be collected via HTTP GET).
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.
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.
$0.06 * 24 * 365 = $525.60 per year.
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.
https://github.com/Miserlou/NoDB
https://github.com/Miserlou/zappa-django-utils#using-an-s3-b...
The whole serverless stuff only pays if you have highly varying loads OR want to save of Ops staff.
I think the value is in that you can build something quickly with no static instance cost that scales. You can (presumably) switch to normal instance-based RDS when your usage favors its pricing.
So just a question of pricing your service on your end...
Case in point, I have one service that doesn't usually need a lot of DB grunt, but has occasionally spiky and unpredictable read-heavy data extractions. It runs happily on a multi-AZ pair of db.t2.small instances, for which we currently pay $0.104/hr (ap-southeast-2). Frankly it could mostly run on a db.t2.micro but we occasionally need the headroom of the bigger instance and the availability of multi-AZ. So when Serverless Aurora comes here it'd be a shoo-in, being both cheaper and more scaleable, and with more replicas to boot.
Here they write pay per second.
Maybe I'm misremembering or that has changed?
Ultimately, we moved to an S3 only solution since we have such a low throughput environment and the simplicity is addictive.
(I work for GCP)
Also, has anyone solved the issue of AWS Lambda (in VPC) scaling beyond the limited IP space ?
[1]http://docs.aws.amazon.com/lambda/latest/dg/vpc.html
ENIs = Projected peak concurrent executions * (Memory in GB / 3GB)
On top of that, I believe you can do a /2 CIDR which gives you over a million IPs to use. Not sure why you think that wouldn't be enough.
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.