No I'm not. Because the people who need this mentality shift are also people who won't listen anyway and have a negative attitude. And the people who already understand this don't need to see this article.
Iceberg is not Snowflake originated, it was built by folks at Netflix - the same folks who built Tabular.
But yes, this is definitely bad for Snowflake, Databricks can position itself as a very strong competitor with this move and moving more towards Iceberg.
Interesting, foreign key constraints typically make sharding harder, interesting to see them add support for some type of fkey constraint (even though it's same-shard only) to the db. I wonder how it impacts use-cases like vreplication/online DDL - I suppose you have to be careful with the exact semantics of the fkeys.
Skeptical. This video by Sabine clearly explains why a lot of these fusion research claims are dubious with a focus on ITER and JET: https://www.youtube.com/watch?v=LJ4W1g-6JiY
This is normal, companies want to organize their staff into the best roles they fit in to the projects which are most important. This is important for a healthy company. The manager would have obviously worked with higher management and there was some tradeoff to be made here, so it would have been let through, keeping in mind the persons interests(hopefully).
Google SRE is overinterpreted. they are a big company with lots of resources and exceptional engineers. It's not reasonable to model smaller companies like that.
There's definitely miscommunication around this. I know I've miscommunicated impact, or my communication was misinterpreted across the 2 or 3 people it had to jump before hitting the status page.
For example, The meaning of "S3 was affected" is subject to a lot of interpretation. STS was down, which is a blocker for accessing S3. So, the end result is S3 is effectively down, but technically it is not. How does one convey this in a large org? You run S3, but not STS, it's not technically an S3 fault, but an integration fault across multiple services. If you say S3 is down, you're implying that the storage layer is down. But it's actually not. What's the best answer to make everyone happy here? I cant think of one.
Complex systems are really really hard. I'm not a big fan of seeing all these folks bash AWS for this, and not really understanding the complexity or nastiness of situations like this. Running the kind of services they do for the kind of customers, this is a VERY hard problem.
We ran into a very similar issue, but at the database layer in our company literally 2 weeks ago, where connections to our MySQL exploded and completely took down our data tier and caused a multi-hour outage, compounded by retries and thundering herds. Understanding this problem under the stressful scenario is extremely difficult and a harrowing experience. Anticipating this kind of issue is very very tricky.
Naive responses to this include "better testing", "we should be able to do this", "why is there no observability" etc. The problem isn't testing. Complex systems behave in complex ways, and its difficult to model and predict, especially when the inputs to the system aren't entirely under your control. Individual components are easy to understand, but when integrating, things get out of whack. I can't stress how difficult it is to model or even think about these systems, they're very very hard. Combined with this knowledge being distributed among many people, you're dealing with not only distributed systems, but also distributed people, which adds more difficulty in wrapping this around your head.
Outrage is the easy response. Empathy and learning is the valuable one. Hugs to the AWS team, and good learnings for everyone.