16 ms·

Let's not forget about AWS Aurora Serverless! I keep ranting about this to anyone who will listen, but hands down one of the biggest innovations in cloud infra

Let's not forget about AWS Aurora Serverless! I keep ranting about this to anyone who will listen, but hands down one of the biggest innovations in cloud infra for exactly the reasons you describe. As the API layer is generally a stateless shim around the database, serverless has limited upside if you can't scale your database sufficiently. But, Aurora Serverless unbottlenecks that concern and makes some very simple and powerful architectures possible. I wonder if there's any open source equivalent to it?

degenerate 7y ago
My very obvious question for this is... what's the latency of "spinning up" the DB? It's not discussed on the Amazon page. Their example is someone running a news site, so I imagine the wait time is something under 1 second of overhead to spin-up the DB, but what does it feel like in practice? Are we talking 50ms of wait time for the DB spin-up, or 500ms?
- shantly 7y ago
  A news site seems like a weird example for an auto-scaling database use case, since, asked to design a news site from scratch, I would aim for 0% of public requests to touch the DB.
- abhiyerra 7y ago
  You can run a minimum number of vCPUs and add the condition to scale from there. That way you have a minimum threshold for requests.
  - degenerate 7y ago
    Ah, so there is always one vCPU running. This makes more sense and was not clear on the product page, thanks.
hmschreck 7y ago
The company I work at is considering this as part of a pretty big shift in our infrastructure. Beyond the obvious upsides, what cost do they come at?
- angerbot 7y ago
  There's a few. My company has been using serverless aurora pretty much since preview and will keep doing so for some parts of infra, but are moving some services back to provisioned. - Data is replicated cross region, but your compute all lives in the same AZ, so if (when) an AZ goes down you have to wait for a new instance to be created elsewhere. AWS says the time for this is undefined, IIRC we've seen it be around 15-20 minutes before the DB is back online. - If you have lots of long running transactions or queries, serverless can have trouble finding a scaling point and won't scale up/down. You can set it to force scaling after 5 attempts, but this results in dropped connections and 1-2 minutes of downtime every time. - Scaling up actually takes 45s-1:30 for new capacity to be available. If your load is spiky enough that that's too slow, you're stuck with overprovisioning anyways. - Tools like VividCortex don't work for serverless if you rely on those. Teams here that use serverless have shifted to DataDog APM for this purpose. - Loading data from S3 doesn't work. This wasn't really a usecase we had but it's something to be aware of. That said, for gradual load or DB downtime tolerant services it's great! Also very nice for dev environments as the scaling down to 0 can result in some very real cost savings.
Dunedan 7y ago
Just to make sure: You're talking about the same Aurora Serverless which consists of a single database server instance in a single availability zone without any guarantees regarding availability in case the availability zone goes down? To quote the AWS documentation [1]: > The Aurora Serverless failover time is currently undefined […] Don't get me wrong: I really like the idea of Aurora Serverless, but with the current feature set it isn't very compelling. [1]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
- scarface74 7y ago
  How many small companies would have any failover if their colocated database server went down? Not only would they not have a warm or hot standby, they probably wouldn’t have up to date data. Because Aurora separates computation capacity and storage, the storage volume for the cluster is spread across multiple AZs. Your data remains available even if outages affect the DB instance or the associated AZ.

degenerate 7y ago

My very obvious question for this is... what's the latency of "spinning up" the DB? It's not discussed on the Amazon page. Their example is someone running a news site, so I imagine the wait time is something under 1 second of overhead to spin-up the DB, but what does it feel like in practice? Are we talking 50ms of wait time for the DB spin-up, or 500ms?

shantly 7y ago
A news site seems like a weird example for an auto-scaling database use case, since, asked to design a news site from scratch, I would aim for 0% of public requests to touch the DB.
abhiyerra 7y ago
You can run a minimum number of vCPUs and add the condition to scale from there. That way you have a minimum threshold for requests.
- degenerate 7y ago
  Ah, so there is always one vCPU running. This makes more sense and was not clear on the product page, thanks.

hmschreck 7y ago

The company I work at is considering this as part of a pretty big shift in our infrastructure. Beyond the obvious upsides, what cost do they come at?

angerbot 7y ago
There's a few. My company has been using serverless aurora pretty much since preview and will keep doing so for some parts of infra, but are moving some services back to provisioned. - Data is replicated cross region, but your compute all lives in the same AZ, so if (when) an AZ goes down you have to wait for a new instance to be created elsewhere. AWS says the time for this is undefined, IIRC we've seen it be around 15-20 minutes before the DB is back online. - If you have lots of long running transactions or queries, serverless can have trouble finding a scaling point and won't scale up/down. You can set it to force scaling after 5 attempts, but this results in dropped connections and 1-2 minutes of downtime every time. - Scaling up actually takes 45s-1:30 for new capacity to be available. If your load is spiky enough that that's too slow, you're stuck with overprovisioning anyways. - Tools like VividCortex don't work for serverless if you rely on those. Teams here that use serverless have shifted to DataDog APM for this purpose. - Loading data from S3 doesn't work. This wasn't really a usecase we had but it's something to be aware of. That said, for gradual load or DB downtime tolerant services it's great! Also very nice for dev environments as the scaling down to 0 can result in some very real cost savings.

Dunedan 7y ago

Just to make sure: You're talking about the same Aurora Serverless which consists of a single database server instance in a single availability zone without any guarantees regarding availability in case the availability zone goes down? To quote the AWS documentation [1]: > The Aurora Serverless failover time is currently undefined […] Don't get me wrong: I really like the idea of Aurora Serverless, but with the current feature set it isn't very compelling. [1]: https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

scarface74 7y ago
How many small companies would have any failover if their colocated database server went down? Not only would they not have a warm or hot standby, they probably wouldn’t have up to date data. Because Aurora separates computation capacity and storage, the storage volume for the cluster is spread across multiple AZs. Your data remains available even if outages affect the DB instance or the associated AZ.