Stately Cloud
@stately.cloud
We're building a database on top of DynamoDB that makes it easier to use. With our elastic schema, you can always change your mind and reconfigure your data model with automatic backwards compatibility.
No, for example if you have a temp volume mounted for some shared (ephemeral) state between pods, it thinks the pod isn't safe to remove ever. You have to add the 'cluster-autoscaler.kubernetes.io/safe-to-evict: "true"' annotation.
February 24, 2025 at 7:50 PM
No, for example if you have a temp volume mounted for some shared (ephemeral) state between pods, it thinks the pod isn't safe to remove ever. You have to add the 'cluster-autoscaler.kubernetes.io/safe-to-evict: "true"' annotation.
Oh, totally, but that's why it's autoscaling. Having someone turn a knob manually is a bad idea.
February 17, 2025 at 10:32 PM
Oh, totally, but that's why it's autoscaling. Having someone turn a knob manually is a bad idea.
That graph is after the 50% cost cut. Before it wasn’t even a contest.
Even in your example autoscaling helps - it will scale up during events and down when they’re not running. The only downside is you can’t scale all the way to zero, but you can scale to 1.
Even in your example autoscaling helps - it will scale up during events and down when they’re not running. The only downside is you can’t scale all the way to zero, but you can scale to 1.
February 10, 2025 at 4:45 PM
That graph is after the 50% cost cut. Before it wasn’t even a contest.
Even in your example autoscaling helps - it will scale up during events and down when they’re not running. The only downside is you can’t scale all the way to zero, but you can scale to 1.
Even in your example autoscaling helps - it will scale up during events and down when they’re not running. The only downside is you can’t scale all the way to zero, but you can scale to 1.
Don't forget to document all the reasons it *won't* evict pods even when you want it to...
February 9, 2025 at 12:29 AM
Don't forget to document all the reasons it *won't* evict pods even when you want it to...
Easy pagination is lowkey one of the best things about DynamoDB
February 6, 2025 at 6:59 PM
Easy pagination is lowkey one of the best things about DynamoDB
And that's just writes - for reads provisioned capacity is still 50% the cost of on-demand.
February 6, 2025 at 6:27 PM
And that's just writes - for reads provisioned capacity is still 50% the cost of on-demand.
That's fair, but provisioned capacity autoscaling is similarly set it and forget it.
What I'm amazed at is that even relatively "spiky" loads are cheaper with autoscaled provisioned capacity. In this graph yellow is the on-demand dollar cost, while the red is provisioned capacity cost.
What I'm amazed at is that even relatively "spiky" loads are cheaper with autoscaled provisioned capacity. In this graph yellow is the on-demand dollar cost, while the red is provisioned capacity cost.
February 6, 2025 at 6:26 PM
That's fair, but provisioned capacity autoscaling is similarly set it and forget it.
What I'm amazed at is that even relatively "spiky" loads are cheaper with autoscaled provisioned capacity. In this graph yellow is the on-demand dollar cost, while the red is provisioned capacity cost.
What I'm amazed at is that even relatively "spiky" loads are cheaper with autoscaled provisioned capacity. In this graph yellow is the on-demand dollar cost, while the red is provisioned capacity cost.
I use a slightly different version saved as `~/bin/git-delete-merged-branches` so I can run it with "git delete-merged-branches":
#!/bin/sh
git branch --merged | grep -v "\*" | grep -v "^\s*\(master\|main\)$" | xargs -n 1 git branch -d
The `git branch --merged` is the most important bit.
#!/bin/sh
git branch --merged | grep -v "\*" | grep -v "^\s*\(master\|main\)$" | xargs -n 1 git branch -d
The `git branch --merged` is the most important bit.
February 4, 2025 at 5:59 PM
I use a slightly different version saved as `~/bin/git-delete-merged-branches` so I can run it with "git delete-merged-branches":
#!/bin/sh
git branch --merged | grep -v "\*" | grep -v "^\s*\(master\|main\)$" | xargs -n 1 git branch -d
The `git branch --merged` is the most important bit.
#!/bin/sh
git branch --merged | grep -v "\*" | grep -v "^\s*\(master\|main\)$" | xargs -n 1 git branch -d
The `git branch --merged` is the most important bit.
They mention it briefly but a big gotcha is that the default hop limit for IMDSv2 is 1, but containers running in Kubernetes need it to be 2. So you must use a custom launch template in EKS to be able to use it at all.
January 26, 2025 at 9:32 PM
They mention it briefly but a big gotcha is that the default hop limit for IMDSv2 is 1, but containers running in Kubernetes need it to be 2. So you must use a custom launch template in EKS to be able to use it at all.
I’m interested in your analysis here. Even with the recent price drop, we’ve found that any system that’s getting real traffic is probably still better off (read: gonna pay less) using autoscaling provisioned capacity.
January 26, 2025 at 9:29 PM
I’m interested in your analysis here. Even with the recent price drop, we’ve found that any system that’s getting real traffic is probably still better off (read: gonna pay less) using autoscaling provisioned capacity.
Realistically I’d probably start with using tenant ID as a PK prefix rather than by itself - tenant is unlikely to be granular enough to be partitioned well.
January 26, 2025 at 9:28 PM
Realistically I’d probably start with using tenant ID as a PK prefix rather than by itself - tenant is unlikely to be granular enough to be partitioned well.
I see what you meant initially, then. I was thinking about it more like how I gather requirements - as a subject matter expert, but using it as a tool to organize my thinking and then communicate what I’m doing to customers.
January 26, 2025 at 6:14 PM
I see what you meant initially, then. I was thinking about it more like how I gather requirements - as a subject matter expert, but using it as a tool to organize my thinking and then communicate what I’m doing to customers.