Read The Book Here

Hi! This is a little microproject I want to do: I want to compress my years of experience building the API backend of a top-50 Steam game into a bunch of weird, rambling advice that I can deliver with all of the authority of someone who can’t differentiate success due to merit from success due to luck.

work environments are divided into dev, prod, and stag

• dev is the live one so named because that’s where we show off our feature dev-elopment to our customers
• prod is a test environment where we prod at new features that aren’t ready yet
• stag is a special build where all of the avatars are replaced with various deer

for some reason new developers are confused by this but I think it’s entirely clear

I’m going to go against the common wisdom on this one. If you aren’t confident enough to push to production on Friday, you aren’t confident enough to push to production, period. Invest in your rollback and monitoring and staged rollout tech until you don’t lose 20% of your week.

more like clownstrike amirite?

(satisfied, he walks away from his keyboard, another day defeated)

today in work:

a build with “build” in the name of the build will build, but it won’t deploy because when we build it, it includes “build” in the name of the completed build

but when we try to deploy it, it decides that “build” is the cut-off point for the name of the build, but it uses the “build” in the name of the build rather than the “build” added by a completed build: as a result it can’t find the correct build

in conclusion: build

there’s a DORA metric associated with how fast you can recover from a prod outage which is why, in order to game the system, I have created the “helltime oscillatrix” which breaks prod over 100,000 times per second, once a month

There was a recent Reddit post where a DevOps employee lost their shit because their co-workers weren’t getting on board immediately with their Terraform repo, and

I’m gonna say it: despite ClickOps’ many problems, Terraform has a bad UI and ClickOps has a good UI, getting people who are used to being able to do things with a few clicks to read a stack of manuals is going to be a challenge, especially if those people have “other things to do with their time”.

Having an organization where everybody makes changes to infrastructure with PRs and a papertrail seems like it’s obviously gonna be better but affecting that particular change by simply creating the repo isn’t gonna do it.

You’re gonna have to make the Terraform repo the ONLY way to change infra, and for a good while you’re gonna have to deal with going from an org where everybody can make changes to an org where everything is backed up by only one person knowing Terraform.

Like, don’t confuse this for me saying “infrastructure as code is bad”, it’s good, and for any org with more than a handful of people making cloud changes it’s gonna be obviously better, but the effort to switch over to Terraform, which is hard, from ClickOps, which is easy, is significant.

nine nines of reliability ( 50.999999999% uptime )

basically my theory of ops tooling is that if you’re a small team without a dedicated specialist, it needs to be rock solid and dirt simple, and SaaS providers get you there a lot faster than DIY