71–80 of 104 posts
Earlier quoted context omitted.
I don’t follow the logic in this argument. The same patterns work in other cloud platforms.
Serverless applications are attached to a single cloud platform they were built on top of. You can't switch between the platforms without changing the code. At its current stage, serverless is more like a hack.
Earlier quoted context omitted.
How does Aurora Serverless help with the issue of having to reconnect for every lambda? (I am unfamiliar with the Aurora Serverless offering) Also, can you elaborate/ point me to info on 2?
Really quickly then - Background info: A lambda that spins up stays live for a while, and can continue to handle requests. The function handler is called again, so anything scoped to it, will disappear with the function, but anything scoped outside of the function will persist. Ergo, move your connection creation outside of your handler. Realistically you may need some abstraction to properly close and reopen the con…
Earlier quoted context omitted.
I don't understand what you're looking for here. A network file system? Every database decouples storage from "compute."
Yeah, but not all of them allow you to scale them independently without a downtime. For example in traditional MySQL setups to scale up the compute capacity your server has to be unavailable for some time.
Earlier quoted context omitted.
So why is rdbms and serverless seemingly mutually exclusive? Are rdbms queries really that slow compared to something like dynamodb?
As far as I know, most RDBMS are connection based, which brings an overhead. When you got your connection they're quite fast.
These are all outdated already. Serverless is a meaningless term. The real name is platform-as-a-service, which is decades old. Running individual functions was just taking that to an extreme but any complex app will have multiple functions working together so it's right back to the same thing. Many "serverless" environments are in fact converting to running an arbitrary docker container for as long as it needs to ru…
I'm mystified by the word 'serverless'. Why are we using this word? There are clearly, _quite clearly_ servers involved. The wacky bugs involved in these 'server-less' services... are going to come down to what's happening on the servers involved.
EDIT: my question seems to have offended. Unfortunate, and unintentional!
Earlier quoted context omitted.
Really quickly then - Background info: A lambda that spins up stays live for a while, and can continue to handle requests. The function handler is called again, so anything scoped to it, will disappear with the function, but anything scoped outside of the function will persist. Ergo, move your connection creation outside of your handler. Realistically you may need some abstraction to properly close and reopen the con…
Keeping connections open on a lambda isn’t a good thing. If you have a lot of Lambdas and a lot of load you can end up hitting max connection limits. Better to open late and close early and take a hit rather than risk taking your db offline.
If you absolutely must hit an RDBMS, be quick about it to free up the connection, and definitely consider if the latency matters that much; a few dozen ms more to initialize and close the connection is going to be a LOT cleaner.
But that said, how badly it penalizes you for scaling connections up depends on the DB.
Earlier quoted context omitted.
Part of it is legacy but also, interactions with an RDBMS are often stateful so it's useful to have a session (in which such things as transactions can live, etc). I'd guess there isn't much reason to change this because there are standard and effective workarounds that just haven't yet made their way to things like lambda.
Can you elaborate on what “standard and effective workarounds” you are referring to here?
Earlier quoted context omitted.
Yeah, but not all of them allow you to scale them independently without a downtime. For example in traditional MySQL setups to scale up the compute capacity your server has to be unavailable for some time.
I think people way overestimate the business effects of maintenance windows.
But I’ve seen so many people get themselves into trouble by using dynamodb as a silver bullet and not thinking heavily about the design of their data. If you try and use RDBMS patterns (PK and FK relationships) there’s a whole heap of pain due to atomicity only being on one record in one table. Some times you can’t escape these patterns as well as it is the best fit for data or you require strong consistency of your model (e.g. financial).
They released dynamodb transactions (for Java only) but from what I’ve seen that just increases the complexity of solutions, you end up with more reads/writes per call and a heap of other stuff surrounding your data. Serverless story currently for stuff like this really has drawbacks
Earlier quoted context omitted.
Serverless applications are attached to a single cloud platform they were built on top of. You can't switch between the platforms without changing the code. At its current stage, serverless is more like a hack.
So is every managed service then; in AWS almost everything uses IAM and that's not portable. I can't use ECS; that's not portable. I can use EC2s, those are just VMs...except how the heck do I build those? I can't do it by hand, that's not portable, I can't use Cloudformations, that's not portable...I can't even use Terraform, as despite their marketing speak I still have to change out my configs, because they're sti…
[1] https://maas.io/