Failure is very important to understand about reality.
Software Development and DevOps should do this more often, as real world failures are always different from test cases.
This is especially true in the field of web sites, cloud development, kubernetes, microservices and other distributed “Stuff” (which starts with DNS!).
There was a great thread last year that ended with this quote:
“Error Budget”: How much infrastructure you’re allowed to set on fire to learn the meaning of the word “heiß”. Every organization has an error budget, but most don’t plan for it.
The start of the thread is around [Archive.is] Kristian Köhntopp on Twitter: “So the little one was a bit over 12 months old, and could already say “Mama” and “Papa”. It was around christmas, and there was a candle on the table, glowing interestingly, so he wanted to touch it. Of course I told him “Nein, heiß!”.”.
Then Kristian Köhntopp summarised the thread in this great blog post: [Wayback] On Touching Candles, And Error Budgets | Die wunderbare Welt von Isotopp.
Too bad ThreadReaderApp still is unable to archive trees of messages (not even single threaded trees with multiple participants) as this is possible with the Twitter v2 API: [Archive.is] twopcharts_nl on Twitter: “is wel eenvoudig mogelijk nu met api v2.… “
- [Wayback] Introducing a new and improved Twitter API
- [Wayback] What’s New with Twitter API v2 | Docs | Twitter Developer (that should all be available by now)
The first v2 endpoints are now available within Early Access. Additional endpoints, features, and access levels will be released soon.
- [Wayback] Standard v1.1 compared to Twitter API v2 | Docs | Twitter Developer
So I archived the thread in two Archive.is links:
- Kristian Köhntopp on Twitter: “Cries in XSLT. Also, Now you can code in yml with a specific Google syntax.… “
- Jonathan Lassoff on Twitter: “This is fantastic. Experience is one of the best teachers. But still… sad to have a meltdown. I was envisioning a high fidelity simulation with generated requests, and a simulated userbase that grows faster than real world, so as to simulate new bottlenecks, a bit at a time.… “
In the thread, Kristian also mentions [Wayback] Code rant: The Configuration Complexity Clock
That article has a very important observation:
At a certain level of complexity, hard-coding a solution may be the least evil option.
–jeroen