Distributed Systems and the Butterfly Effect
The late science fiction author Ray Bradbury’s short story classic “A Sound of Thunder” is about a group of hunters who travel back in time hoping to kill a tyrannosaurus rex dinosaur. Predating the debut of the “Jurassic Park” film franchise by decades, the follies of technology innovation that allow, among other things, for humans to interact with dinosaurs, predictably goes awry. However, the main theme of “A Sound of Thunder” is not so much about the risks of appeasing humans’ archetypical curiosity about scary beasts as it is about how interconnected our actions are. Bradbury portrays, for example, how the mere accident of going back in time and stepping on a butterfly can set in motion a chain of reaction that eventually leads to cataclysmic events in the future.
In today’s IT world of distributed systems built with Kubernetes and container orchestration technologies, it is beginning to emerge just how deep applications really are, as well as how deeply distributed they are. One of the effects this very distributed and connected infrastructure has is reflected in the famous quote by Leslie Lamport:” A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” In other words, killing a butterfly might not set into motion a network breakdown, but then again, who knows what the effect of any mishap or mistake might be, whether it is a blocked service or spilling coffee on a cloud network provider’s data server.
In this latest The New Stack Makers podcast, Guillermo Rauch, founder of hosting service Zeit, and co-creator of the React framework Next.js, said much of his work today involves network synchronization. More specifically, he described his work with state and how it’s synchronized over networks and how that has affected his creation of policy structures for applications. He also described his ambitions to help improve the groundwork for coherent and consistent systems for data consistency models.
The theme of interconnectivity is also “a great segue into how our deeper thinking has gone into building resilient systems from both a service architecture perspective but also within the context of front-end applications,” Rauch said.
As for microservices, they are “chatty,” Rauch said. Microservices “are actually really bad for availability.” This is because even very minute incidences of lost connections between microservices can lead to sub-par network performance. “So, one of the things we set out to do was to say ‘okay, let’s break this chain of it chattiness over to network, because that’s what Leslie Lamport is referring to as one of the complexities of distributed systems. They’re all of these computers in between and all these networking artifacts in between that can hurt your availability.”
TNS Publisher Alex Williams hosted this podcast.
Photo by Kristel Hayes on Unsplash.