Ritchie, A Distributed Programming Language
If you drive a car, you might know that most of the complexity of driving is with the traffic, i.e. the decisions you make in response to your environment. Controlling the car itself is very simple. You have a slow-down pedal, a speed-up pedal, a turning wheel and a drive mode (PRND) selector.
Yet, beneath this simplicity, a car is a very, very complex system. There are tens of thousands of mechanical parts in a car, several thousand of them in the internal combustion engine itself, that easily do a few hundred million revolutions of the crankshaft over the lifetime of a car. You don’t need to know about it because collectively the automobile industry has figured out how to build a car so easy to use and so reliable that it would work faultlessly with nobody having to maintain it beyond a couple of hours every year.
The automobile industry has pared down, distilled and improved the driver operations to the minimal 3-control model over centuries.
Rebuilding Levee with Claude
I had been building levee, a self-configuring circuit breaker and rate limiter, on and off for almost a year. Then I over-designed it to failure. Part of the blame was mine, for trusting faulty benchmarks – implemented wrongly by, yes, Claude. It was only when I started questioning the results that Claude owned up to the flaws in its own benchmark logic. After several rounds of re-architecting them for a realistic simulation, the verdict was a gut-punch: Levee was the worst performing circuit breaker of the lot, by a huge margin.
Building Levee: A Self-Tuning Circuit Breaker
Circuit breakers are wonderful intermediaries between two high-traffic synchronous network services. They prevent the caller from overloading the callee when the latter is in trouble. In turn, this protects the caller from getting backed up with too many pending requests. This is all assuming that the circuit breaker is well configured, as are the timeouts and rate limits.
Unfortunately, I’ve seen way too many incidents where the “well configured” assumption is not held true. Too often, concurrency is allowed to bloat until it exhausts resources and that in turn happens because equally often, the timeout is set as if it were a prayer instead of a protective limit.
The MetaComputer™ (Part "How" of 3)
In the previous articles of this series, I talked about why we need a new computing model and what that model should look like. The “why” was pretty clear – we’re drowning in accidental complexity while building distributed systems. The “what” painted a picture of a unified computing environment that makes building distributed applications more tenable. Now comes the challenging part – how do we get there?
Starting at the Foundation
When you’re building a skyscraper (yes, I’m bringing back that analogy from Part “Why”), you don’t start with the penthouse. You start with the foundation. In our case, that foundation is a programming model that treats distributed computing as a first-class citizen rather than a bolt-on addition.
The MetaComputer™ (Part "What" of 3)
In part “Why” of this series that appeared previously, I talked about the need for a new computing model that simplifies modern cloud-native distributed application development. In this part, I’ll go into some details of what this new computing model should be and what it should provide.
The MetaComputer™ (Part "Why" of 3)
It’s been a quite a while since I truly enjoyed programming at work. Don’t get me wrong. I like wrangling with code to make interesting stuff happen. The problem is that for a long time now, making interesting stuff happen with code hasn’t been the end game. Since the last ten years or so, it’s become incredibly more complex to get finished code to start working in the real world (aka production). Some say it’s because we OD’d on microservices. That probably true but there’s more to it than that alone.
Using a QLC SSD for Backups. Am I Insane?
I have a properly working Seagate Backup Plus Hub. However, I’m now using a Samsung 870 QVO for Time Machine backups on my Mac, despite its bottom-of-the-pile TBW (durability) rating. It actually makes sense.
Buy or Build?
One of the decisions a CTO has to frequently make is whether to build some piece of functionality in-house or buy it from a third party vendor. In this post, I share my framework for making these decisions.
I also include a case study each for a buy decision and a build decision. Added bonus – some thoughts on whether you should sell something you’ve decided to build.
Functional Complexity
One of the most important determinants of buy-vs-build decisions will be the ability to spec out the entire functionality. Often we know what the primary functionality should be – e.g. being able to show metrics on a graph (a monitoring solution). The devil is in the details, though, and spending some time in discovering peripheral functionality is very helpful in avoiding a situation where you jump head-first into building something seemingly simple and then get stuck.
5 Competitive Advantages in Technology
The technology universe is in a constant state of flux with new advancements arriving faster than one could keep up. A technology leader, in this scenario, needs to look for something durable to build the foundation of their new (or improved) technology organisation.
Spending 36 months leading the charge (and occasionally failing) at a fast growing business that’s powered by technology can teach a lot. Coming off the back of a career built with customer-facing development teams at companies serving over 100 million customers, I now have some idea of what it takes to make a strong technology foundation for a modern business.
The Best Feature of Go
I’ve been programming since the late 90’s and I’ve done quite a bit of coding in C, C++, a lot of it in PHP and some in Python as well. On the front-end I’ve done some JavaScript and I’ve also had the misfortune of programming in Java 😉
I started programming in Go in 2012 and since then I haven’t wanted to program in any other language. I’ve had a handful of large Go implementations across two companies and by now I have my own short list of favourite features.