Simplicity – Google SRE Handbook (2017)

Indeed, allegations of hypocrisy are a class of ad hominem. They don't necessarily weigh in on the validity. It just... feels good? I guess? People LOVE to feel like they caught a hypocrite. It's probably in the Top 5 most sought after dopamine kicks.

Sure, but if we argue that these values and principles should be applicable, then it should also be possible to make an argument why and not blame the irrationality on emotions.

It seems more likely that bounded rationality is at play here, where different parties only know part of the picture (and fail to bring these together and find out what would be best globally.)

Maybe this is also about the desire to create, which of course is also common in engineering. It does not contradict my argument that the cost of maintenance and operations is being ignored eg when one creates things all the time and never removes stuff. And it should be possible to measure or estimate that cost.

I never took that as dealing with emotional attachment, it was just a shorthand to express that at any moment you would kill cattle so don't do things you can't easily replicate.

No, that had nothing to do with emotional attachment. It’s a short phrase to remind people that they can’t make each device special with one-off because it needs to be repeated/destroyed all of the time.

Separately, cattle vs pets is much older than containers. It got popular with ephemeral EC2 instances when people were first forced to grapple with lifetimes of VMs measured in hours and the ability to scale massively as needed.

Curious what examples do you see there. I don't doubt the experience.

When I draw analogies of my past experiences to present situations, that does not mean that my past experiences are the best way to convince people of what is the right thing to do. I still need to do the hard work of pointing out what it is that is in the common interest and why eg deleting stuff and simplifying is good.

In such a discussion it won't help me to say people who disagree with me are generally just emotional, does it? Even if I may have encountered people with such emotional reactions.

Unfortunately complex solution we have accumulated over time is usually because business did not want to spend a bit more up front to come up with cleaner solution.

In the same way business is also very reluctant to spend time/money on cleaning up stuff.

I never ever had to make up complex stuff on my own. It always happens on its own.

I like this way of saying it. I don't think anything here is well studied at all. It is not like we are all fishing in the dark but the organizational structures that determine the conditions in which software development and operations happen are not well understood. I found Herb Simon's writings and his concept of bounded rationality very lucid.

When we shift from "reliability" to "safety" we also need to shift from the individual to the system.

"If you are only one developer" suggests zero interests in being nuanced.

To be clear, this linked specifically to simplicity which I'm certainly in favor of emphasizing the importance of. But IME the exact opposite happens when people try to imitate Google overall in a smaller setting, where instead too much resources are spent on meta-issues instead of the product being developed.

> On the other hand, the book has some nuggets that make it worth reading

Definitely! Mostly just a word of caution to not get overeager hoping to apply this everywhere, because "here be dragons".

> I doubt the majority of SREs at Google have even read the "Google SRE book".

That's absolutely true, but by design. SRE already had exceptional horizontal knowledge transfer before any book. The book was published (specifically, published) to extend that knowledge transfer outside of Google's own walls so the rest of the industry could also benefit.

I was a SWE-SRE for several years and absorbed a lot just through talks and postmortems. I left Google and joined another big org that was a ... bit ... less far along in its SRE ambitions. I couldn't convince a single person to read the book, even after linking to specific sections to explain why e.g. jitter is important to have in tandem with backoff. Nobody cares, they have boxes to tick and janky bullshit to ship.

Most people are not interested in learning from books these days, inside or outside Google, but at least inside Google you can learn from an unbroken lineage of experienced SREs.

If you're trying to build out an SRE org in your own company, you're better off hiring one ex-Google Senior SRE than you would be if you bought everyone a copy of the book and two weeks of formal training. Actually embedding real-world experience into your teams is the most effective form of knowledge transfer available.

I've seen it be a company culture thing where every discussion was resolved with we'll put it behind a config/flag. It's an easy way to avoid hard choices. It's probably something like that the author refers to.

Because is just useless. I mean seriously, what valuable insight does anyone get from that? It's some sort of truism wrapped in a word sandwich, ready for linkedin lunatics to pat themselves on the back sharing it. Do you feel you've gained something by reading it? Is this a valuable piece of intelligence which would guide your future decisions? Will you bring this to the team during an argument to push your agenda? This feels like the same type of 'feel good' content which people read and then feel like they did something productive. But I would argue that every piece of insight coming for a mega corp, valuable inside the mega corp is actually dangerous outside when people take it as dogma and try to apply it. SRE in general is something which IMHO of working in the industry for decades has poisoned the industry with half assed cargo cult implementations. But it has Google branding, so it must be valuable, hits hard for the fanboys and obviously can and should be applied in every company and every context.

I also find it ironic to see 'Simplicity' touted from the same people who let Kubernetes lose in the wild, but that's a different story for a different time

Not OP but I'll give my take because I mostly agree. Because Google lives in a world few of us do. I'm SRE/DevOps and our lives are nothing like Google SREs. We have almost zero control over software that is chucked our way. Any attempt to try and control them fails with management telling us "Just fucking ship it". Finally, something I realized after working with various FAANG SRE types, they don't understand what bad development practices look like, they can't imagine it.

With Google, the deletions almost always are intentional, not accidental, and this is a huge problem with it. Google (not GCP) deleted ten years of my data without warning or notification or remorse or recourse even though I was doing nothing illegal. Amazon would never do something like it. To Google, once a customer or service becomes just 1% inconvenient, it's time to get rid of the customer or service. It's a very valid concern.

The drinking culture is also pretty weird.

I think you picked the least interesting part of SRE to poke at.

It's the equivalent of saying "SWE just adds new stubby endpoints to a service, so simple".

Spot on, but you missed two gnubbies and another password.

“It has numbers attached” does not mean something is backed by data.

Unless they are testing correlations between these target metrics and business success or some other external cost metric, it’s still “just feels”.

I’ve seen internal crusades against cyclomatic complexity that resulted in massive engineering waste to reduce and reliability saw no improvement.

Google : We will breach the rules we preach.

> That was seven years later. Maybe the problem is that Google stopped reading what Google wrote.

The problem is that it was never that good. Anyone who has used K8s at scale will tell you at length how it doesn’t scale. People should stop focusing on tech companies like celebrities and focus instead on domain problems related to their business.

> If we should only read things written by organizations that make no mistakes, then we will never read anything.

That was a “mistake” that should not have even been possible. If the pension fund had not used a multi cloud strategy the entire business would have been lost. A mistake is not configuring Kafka correctly and losing some data, deleting an entire account should not be given a pass.

> Oh, completely ignoring anything anyone from Google ever writes again? This is akin to the cancel culture which we all know is how society should work. /s

Maybe if Google focused on doing actual work instead of writing feel good engineering pieces, they wouldn’t have the Google graveyard and an unstable cloud offering that may spontaneously delete multi-billion dollar accounts.