I have a preempt-able workload for which I could use Spot instances or Savings Plans.
Does anyone have experience running Spot in 2025? If you were to start over, would you keep using Spot?
- I observe with pricing that Spot is cheaper
- I am running on three different architectures, which should limit Spot unavailability
- I've been running about 50 Spot EC2 instances for a month without issue. I'm debating turning it on for many more instances
In terms of cost, from cheapest to most expensive:
1. Spot with autoscaling to adjust to demand and a savings plan that covers the ~75th percentile scale
2. On-demand with RIs (RIs will definitely die some day)
3. On-demand with savings-plans (More flexible but more expensive than RIs)
3. Spot
4. On-demand
I definitely recommend spot instances. If you're greenfielding a new service and you're not tied to AWS, some other providers have hilariously cheap spot markets - see http://spot.rackspace.com/. If you're using AWS, definitely auto-scaling spot with savings plans are the way to go. If you're using Kubernetes, the AWS Karpenter project (https://karpenter.sh/) has mechanisms for determining the cheapest spot price among a set of requirements.
Overall tho, in my experience, ec2 is always pretty far down the list of AWS costs. S3, RDS, Redshift, etc wind up being a bigger bill in almost all past-early-stage startups.
To "me, too" this, it's not like that AWS spot instance just go "poof," they do actually warn you (my recollection is 60s in advance of the TerminateInstance call), and so a resiliency plane on top of the workloads (such as the cited Kubernetes) can make that a decided "non-event". Shout out to the reverse uptime crew, a subset of Chaos Engineering
Also https://audioread.com/. I love that you can forward emails to audioread and they'll be transcribed into podcasts. Thank you AI-voiced Matt Levine!
Thanks for sharing those. We're currently testing out the release of personalised podcasts, as the combination of LLMs and the realistic text-to-speech can lead to a solution of a quality level that has not been available until now.
I occasionally ponder on how frustrating it is that the deceased don't get to hear their eulogies. It would have been amazing for Bram to have been able to experience all the outpouring of support and love from people he is interacted with during his life. Especially in a context where the speakers aren't considering him as an audience -- they're sharing their deep and true feelings.
No one can really be sure how their acquaintances feel about them. Eulogies are the closest we get. Imagine if he were able to hear all these great things said about him... It would be such a joy.
This is why I always make it a point to tell people how much I appreciate them and why (when I do, I mean). It can be awkward at first, but I’ve developed a good self-deprecation that lets me excuse myself for being gushy (“I might start crying; I’m a crier!”), and that disarms people for the most part. I think it’s really important that we let people know how much we value them and why we honor/respect them when we do. Because most of us do wander through life in a cloud of unknowing and uncertainty.
Off topic but your comment makes me think of Nick Drake. He died at 26, before even knowing he'd achieved anything, his music barely listened to, probably feeling a failure. Posthumously he's one of the world's most acclaimed recording artists.
RIP Bram.
At least in one of the Van Gogh movies, he says something like 'one day, people will understand'. To me, that suggests that he knew the value of his work whereas OP suggests that Nick Drake didn't know that he created something that people will value.
Larry David had the same thought, and it was the theme of the episode "The Covid Hoarder" in Curb Your Enthusiasm wherein Albert Brooks stages a funeral for his non-deceased self.
tig is great for a read only operations. Looking at the tree, peeking at diffs, finding specific commits. It's quicker to get in and out of. I reach for it instead of `git log`.
lazygit makes it super easy to make modifications. Reorder commits, revert specific hunks from commits. I find it easier to use if I need to look at a really big diff. I reach for it instead of `git rebase -i`, and it can do things no native tool can do easily (such as revert or extract specific hunks from commit earlier in the tree.
I use both multiple times per day. tig if I just want to look at stuff (fewer keystrokes to look at diffs in the tui!) and lazygit if I want to modify stuff (more powerful!).
I find marking files, hunks and single lines to commit extremely comfortable in tig. And also reverting is as easy as selecting a file or hunk and pressing Shift+1. But yes, more complex operations are not supported or rather you have to define an external command and thus use an external tool for those.
Not if it was done well, unfortunately... I suppose there's always sending a text to a friend saying "I'll leave the money in a blue bag on the corner of 4th ave at 10am tomorrow" and hiding in the bushes (but sadly we'd expect an attacker who was halfway across the world, not across town). I am pretending everything is fine until I can't.
RDS Proxy is very specific with which versions it supports. If it says it doesn't support it, it doesn't support it.
Postgres 14 is supposed to have built-in connection pooling. If you're on it, do you still feel the need for RDS Proxy? We're using pgbouncer and can't decide if we should switch to RDS Proxy or upgrade to Postgres 14 and drop the external connection pooler.
