Vedang.me, posts tagged tigerbeetle2025-01-06T15:18:04+05:30https://vedang.me/Vedang Manerikarhttps://vedang.me/tigerstyle-or-how-to-design-safer-systems/TigerStyle, or how to design safer systems in less time by Joran Dirk Greef2023-06-26T05:30:00+05:30Executive Summary
The three core ideas of Tiger Style:
See the whole picture. (always think about design, coding, testing, operator experience)
Check yourself before you wreck yourself. (assertions)
Give yourself a time machine. (simulation)
Developing is system is more than just coding.
Design
Coding
Testing
Operator experience in Production
Don't be hasty. An hour in design is worth weeks in production.
Testing is what dominates the development of complex systems.
How you paint your software from scratch is all about 4 colors and 2 textures:
Network, Disk, Memory and CPU
Latency and Bandwidth
Use assertions everywhere!
The slightest logic bugs should shut everything down.
Limit your loops with minumum and maximum bound assertions
Everything has a limit and you must make the limits explicit.
Design for simulation from day 1
Simulation lets you test in days what you'd take years to find in the real world.
The video
Notes on the video
(Pg 4:59) "Tigerstyle sees the whole picture, checks yourself before you wreck yourself, gives you a time-machine!"
(Pg 6:25) "Decide your tools on quality, not quantity" [tools]
(Pg 7:25) "Developing a system is not just about coding … the design phase before and after, the coding, the testing phase after coding and the operator experience in production" [coding]
(Pg 7:55) "Total time of ownership = Design + Coding + Testing + Incidents" [shipping]
(Pg 10:10) "An hour in design is worth weeks in production" [quotes]
by Joran Dirk Greef
(Pg 10:40) "Simple and Elegant Systems tend to be easier and faster to design and get right, more efficient in execution and much more reliable" [quotes]
by Edsger Dijkstra
(Pg 13:10) "Testing is what dominates the development of complex systems." [testing]
(Pg 13:15) "Callout to Jepsen as a great tool for testing distributed systems!" [jepsen, clojure]
(Pg 15:25) "There is more to software than just engineering. It is at least the intersection of engineering and art." [building]
(Pg 18:40) "Four colors of systems programming: Network, Disk, Memory, CPU" [distributedsystems]
(Pg 18:56) "The two textures that all these colors share are: latency and bandwidth" [distributedsystems]
(Pg 19:10) "In the design phase … 1) Back of the envelope calculations" [design]
(Pg 19:30) "Sketch as many solutions as you can using … (colors, textures) .. because sketches are cheap and rewrites are expensive" [design]
(Pg 19:40) "Find great names for your components … TigerStyle doc in our repo gives you tips on naming" [design]
(Pg 20:35) "Define your mechanical fault models" [design]
Think through your fault models and see if your system is designed accordingly.
(Pg 21:10) "Be explicit up front about the fault models your system can tolerate" [design]
(Pg 21:40) "Stateless is always better than stateful" [design,state]
State is very hard! :D
(Pg 22:00) "It pays to reduce surface area that you commit to. The more surface area, the more unexpected interactions." [design]
(Pg 23:00) "Zero Technical Debt policy … do the best that you currently can … do it right the first time" [design]
Knowing that your work is solid motivates your team
(Pg 24:00) "Walk and Talk when you are discussing hard problems" [design]
Walking and discussing is really simulating for the brain.
Design tricks put you in good place for coding.
(Pg 26:30) "Assertions: NASA's power of ten rules for safety critical code" [reference]
Your system should run safely or not at all .. shut down in the face of a bug.
(Pg 27:30) "Write assertions checking your function arguments" [correctness]
that they are as you expect, and also assert that they are correct in relation to each other.
and you do the same for the return value
now your functions are contributing to correctness
(Pg 27:42) "The ultimate purpose of abstraction is for correctness" [quotes]
By Joran
(Pg 29:00) "If it compiles, you've just begun!" [correctness]
(Pg 30:20) "Start to think like a hacker: what don't you expect? What would be unusual in this case?" [hackers]
(Pg 32:40) "Everything has a limit … systems have limits .. make them explicit so that your design can handle edge-cases" [limits, distributedsystems]
(Pg 34:09) "Static memory allocation is just one example of everything having a limit." [limits]
Memory, Network, CPU, Disk all have limits and need to apply back-pressure.
(Pg 36:10) "Assertions are a force-multiplier for testing" [testing]
Do not let your programming language turn them off in production!