Resiliency and new domains - 123dev #30
Posted on October 5, 2021 • 3 minutes • 630 words
Comments
Resiliency
Code and systems break all the time. At a certain scale it’s important that your start building software that can heal itself. It’s sometimes confusing what that means because what state should the software return to?
While it was bent out of shape the paper clip wasn’t broken, but it wasn’t useful as it was intended to be. Software is similar in that it may still be functioning but not usable for its intended purpose.
Unfortunately, there’s no code that I know of that automatically can bend back into it’s intended state when exposed to heat. It’s something we as developers have to make it do with carefully tuned systems to check and verify the current state.
Resiliency on top of unreliability
When telegraph usage was ramping up in the world there were two big problems for adoption—cost and reliability. To solve the problem of high cost many companies created codes that would compress a message into the lowest cost possible. The lowest cost was sometimes the shortest amount of characters but not always. Compression also helped with being able to communicate faster but that was a side affect. Messages could be encoded at one end and decoded on the other to convey a lot of information. One example I found from a theatrical code book was the word “Filander” which translated to “are you willing to appear in tights.”
As telegraph lines got longer there was another problem of how to make sure the message was correctly received. Not only could there be encoding errors but without repeaters data loss could happen regularly at long distances. In order to validate messages checksum letters were added which made the message longer but it was still cheaper than sending it twice.
That story reminds me it’s possible to build reliable systems on top of unreliable technologies. Packet switching networks and TCP/IP is another great example. By assuming an unreliable connection the creators were able to design very robust communication.
Links
This post series has a lot of great introductions to building resilient systems. Most of it is focused on designing systems and is still good information for developers to know. Bonus points because the first post has a terrifying gif.
Patterns for Resilient Architecture — Part 1 | by Adrian Hornsby | The Cloud Architect | Medium — medium.com As you may know, a quote that shaped the way I think about architecture is from Werner Vogels, CTO at Amazon.com. He said: Having worked on large-scale systems for more than a decade, if I could…
I’ve known about .new TLDs for a while but I didn’t know how many there were. This list has everything from creating new docs and calendars to jpgtopdf which rolls right off the tongue.
I’m only sad that new.new isn’t a redirect to register a new .new domain.
.new - Google Registry — whats.new Browse the full list of .new shortcuts available today from Adobe, Spotify, and many more.
Some great lessons in this post that are true from my experience too. I especially liked the tips that great teams make you exponentially better and writing code for humans.
I’ll add that you should make sure you write your code for humans in the future who will have to solve unknown bugs and reproduce the context of the problems you were trying to solve and probably hate the code they’re reading because it uses old frameworks and the author left the company with only a vague git commit message that says “fixing bugs”.
The 10 Most Valuable Lessons I Learned As A Developer — blog.oliverjumpertz.dev I’ve developed software for over 21 years now, which is way over half of my lifetime. Here are some of the most valuable lessons I learned along the way.