The default limits are _very_ conservative in large regions
(Admittedly, by the time you've asked for those limit increases you should probably reconsider what you're doing, you're bleeding $$$ at this point)
1,262 karma · joined May 23, 2015
From one orange to another
The default limits are _very_ conservative in large regions
(Admittedly, by the time you've asked for those limit increases you should probably reconsider what you're doing, you're bleeding $$$ at this point)
I've not done much frontend work, but I'm not sure ClojureScript aficionados would generally feel that TS has much benefit over JS when CLJS is in the picture as well. Salt your JS to your own taste imo
The foundational services do not use cfn for the vast majority of their deployments.
Unless the incident is now being referred to as “Cloudstrike”, in which case, eww
The things I've seen juniors try to do because "the AI said so" is staggering. Furthermore, I have little faith that the average junior gets competent enough teaching/mentoring that this attitude won't be a pervasive problem in 5ish years.
Admittedly, maybe I'm getting old and this is just another "darn kids these days" rant
It's nice to at least have the option of making that tradeoff
(And I suspect for plenty of applications, the class cache will be worth more time than (an also probably cached) image pull)
[1] https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
Of course, I wouldn't be surprised if the boffins at lambda add some integration between snapstart and class caching once their leadership can get it funded
CDNs and cloud providers are a bit of a special case. AWS definitely has soft blocks during tax peak and large sporting events, CDNs (guessing here) would likely be doing follow the moon(?) (i.e. off-peak) rolling releases
My disagreement with the parent comment was driven by lack of nuance
Do you really think that Amazon is deploying (non-emergency/operational) code changes during BFCM or re:Invent? Or that Fox/CBS/NBC are deploying code changes during the Super Bowl?
Also (unless you have some business need to deploy before the weekend) why deploy on a Friday afternoon? You're just asking for latent defects to page you in over the weekend. Save yourself the trouble and delay that deployment till Monday morning. Your team will thank you in the long run.
Sometimes repetitional and/or sleep damage isn't worth being uncompromising on idyllic CI/CD goals.
Coral is a schema definition language, yes. But it’s also a full rpc ecosystem.
Smithy at this point is only really an IDL that (in most cases, at least before I left) is “only” used to generate Coral models and then transitively Coral clients and services. The _vast_ majority of Amazon is still on “native” Coral
No mention of Racket, Scheme or SICP!?
As an extreme example, Starlark isn’t a powerful language, it isn’t even Turing complete afaik. This is advertised as a positive attribute for a build description language (I don’t have an opinion, never used it myself).
Conversely, C would classify as a powerful language even considering how barebones it is from a “feature” perspective . Poke any memory however you like is a pretty powerful power
https://news.ycombinator.com/item?id=42308716
for more
I imagine that number is tunable up to multi digit tb if you your monthly bill is worth Jassy's attention
https://docs.aws.amazon.com/aurora-dsql/latest/userguide/CHA...
The more interesting (i.e. constraining) limits are transaction size (both row count and data size) and transaction time, which aren't configurable.
https://brooker.co.za/blog/2024/12/03/aurora-dsql
Specifically, transaction latency is constant relative to transaction statement count, even across region, so I guess that's something
The quotas page is always the most interesting for any aws service.
10Mb transaction size and 5min transaction duration limits are interesting limitations that kill any "everything lives in the db" notions that one might have.
A fully transactional, scalable, distributed data store + queue + db + data stream with triggers is my endgame
Also, the 128mb limit on transaction temporary storage seems _very_ limiting for big ol' analytic queries
> With its innovative active-active distributed architecture, Aurora DSQL is designed for 99.99% availability in single-Region configuration and 99.999% in multi-Region configuration, with an innovative active-active, distributed architecture, making it ideal for building highly-available applications
We get that its architecture is innovative and active-active
Normally I'd give the developers the benefit of the doubt. But the sheer number of issues, and how fundamental some of them ~were~ are[1] leave me little room for sympathy.
https://en.wikipedia.org/wiki/British_Post_Office_scandal#Pr...
Transaction idempotency is such a basic property for a financial system that I struggle to believe that Horizon was tested in any meaningful way.
"the engineers who built the thing" (Gareth Jenkins) are also under investigation for perjury.
[1] Horizon is still in use, in its buggy state, with replacement scheduled for 2030....
I think it would leave me furious for weeks and push me into a depression rut.
I'm trying to take the whole debacle as long term inspiration to be excellent at what I do - it's tough to stay positive when so many people involved (Fujitsu, PO upper management, the original prosecution) seem entirely morally bereft, with little chance of consequence.
Just because there are unanswered questions that doesn't mean we can't have bare minimum codified standards.
Furthermore, standards aren't invalidated just because practitioners disagree with them. Plenty of <insert engineer type>s disagree with the standards body of their respective field, they still follow the standards out of fear of prosecution or simply as a path of least resistance and when those standards are found to be defective, they (generally) evolve.
To clarify, there was not _one_ bug, but hundreds.
https://en.wikipedia.org/wiki/British_Post_Office_scandal#Pr...
From my read of the information publicly available, there was a fundamental lack of distributed/transactional system understanding from the developers at Fujitsu.
This[1] article recently posted here[2] reminded me of the Post Office Scandal.
The lack of respect for established CS theory (transactions and distributed systems) and established accounting practices (double entry book keeping or even the idea of a ledger) is mind boggling.
[1] https://news.alvaroduran.com/p/engineers-do-not-get-to-make-...
Do you have any "killer app" style use cases in mind for jank? Babashka is great in CLI/FaaS settings, native Clojure is great for "situated" programs that can afford a JVM startup and some memory overhead
Which settings are you particularly excited to use jank in?
Worth reading once a year imo
https://en.wikipedia.org/wiki/British_Post_Office_scandal
Anything that moves money should be treated with upmost seriousness and be aware of as many historical mistakes as possible.