I've gotten a few questions about Aurora Serverless v2 preview, so here's what I've learnt so far. Please feel free to chime in if I've missed anything important or got any of the facts wrong.
Alright, here goes the 🧵...
Q: does it replace the existing Aurora Serverless offering?
A: no, it lives side-by-side with the existing Aurora Serverless, which will still be available to you as "v1".
Q: Aurora Serverless v1 takes a few seconds to scale up, that's too much for our use case where we get a lot of spikes. Is that the same with v2?
A: no, v2 scales up in milliseconds, during preview the max ACU is only 32 though
Q: is the cold start for Aurora Serverless v2 still a few seconds?
A: yes, unfortunately...
Q: so if you want to avoid cold starts, what's the minimum ACU you have to run?
A: minimum ACU with v2 is 0.5
Q: does v2 still scale up in double increments, e.g. 4 ACU -> 8 ACU?
A: no, it scales up in increments of 0.5 ACUs, so it's a much tighter fit for your workload, so you'll waste less money on over-provisioned ACUs
Q: is there anything I can do with v2 that I can't do with v1?
A: yes, v2 supports all the Aurora features, including those that v1 is missing, such as global database, IAM auth and Lambda triggers
Q: wait, but it's twice as much per ACU!
A: yes, but v1 requires a lot of over-provisioning because it doubles ACU each time and takes 15 mins to scale down. v2 scales in 0.5 ACU increments and scales down in < 1 min. AND you get all the Aurora features!
Q: can you use "provisioned" and "serverless" instances in the same Aurora cluster?
A: yes you can! cool, right!?
Q: is data API supported on v2?
A: not in the preview, I'm guessing it'll be there in GA
Q: if using from Lambda, do I need to use RDS Proxy to manage the connections to the cluster? Data API kinda mitigated that for v1..
A: yes, you probably should, until data API is enabled on v2, otherwise, more connections = more ACUs, it can run you into trouble
did I miss anything? plz feel free to chimp in
@jeremy_daly has written a nice summary post on this too, with a nice experiment on the scaling behaviour of v2, so check it out if you haven't already jeremydaly.com/aurora-serverl…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
I have written over 800 technical articles in the last 14 years and they have been read millions of times.
I see a lot of folks making the same mistakes I did early on in my journey.
So here are some principles to help you get better at writing.
🧵
1. 𝗦𝗲𝗹𝗹 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻
Like that scene in The Wolf of Wall Street where Di Caprio asked Jon Bernthal to sell him a pen.
First, create the demand, then supply the solution.
Sell the problem to the reader. Help them understand why it’s a problem worth solving.
If the readers are not interested in the problem you're solving, they won't care about whatever solution you propose, no matter how good the solution is.
Payload-based filtering was one of the key reasons to choose EventBridge over SNS. This makes SNS a much more viable option in Event-Driven Architecture.
This is a very interesting thread and the surrounding discussions. I've had similar discussions in the past, but I don't want to make too many assumptions here because I wasn't part of the conversation with the client.
First of all, serverless has been successfully adopted at a much bigger scale in other companies. LEGO for example have 26 squads working mostly with serverless, and PostNL has been all in on serverless since 2018.
So technology is probably not the problem.
From the clues I'm able to pick up, the team has given it a go but they faced tooling gaps when you have both serverful (RDS) and serverless components, and maybe needed help to navigate those hard edges and adapt their practices to work better with serverless
The "serviceful" mindset means you'll need to learn and use many services in your architecture. Having the right tool to help you along can make a world of difference. And here are 7 of my favourites.
Serverless IDE is a VSCode extension that will save you countless hours when you work with CloudFormation, AWS SAM or the Serverless Framework.
Auto-completion, schema validation, CF docs on hover, and many more.
I have written ~800 technical articles/whitepapers in the last 10 years and they have been viewed millions of times.
I see a lot of folks making the same mistakes I did early on in my journey.
So here are some principles to help you get better at writing.
🧵
1. 𝗦𝗲𝗹𝗹 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺, 𝗻𝗼𝘁 𝘁𝗵𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻
Like that scene in wolf of wall street where Di Caprio asked Jon Bernthal to sell him a pen.
Create the demand, then supply the solution.
Sell the problem to the reader. Help them understand why it’s a problem worth solving.
If the readers are not interested in the problem you're solving, they won't care about whatever solution you propose, no matter how good the solution is.