My insight after a decade in distributed systems
By Jeffrey M. Barber
Ten years is plenty of time to accumulate generic career wisdom which I share on my personal page with my (poorly written) consolidated writings, but I want to focus on the key technical aspect of distributed systems. There are a lot of fundamentals to contend with, but I think the hardest to deal with is state. State is hard, and many people don’t want to deal with it (for very good reason).
Building a company around a toy requires embracing the toyness (and thinking beyond Excel)
By Jeffrey M. Barber
So, progress is going slow as I’m on the pathless path wandering.
It’s fantastic to wander, but I realized after reading How Tech Loses Out that I’m an anti-salesman and negative marketer. This section caused a bit of reflection:
So initially, your technical people are actually negative marketing. They recommend that people do not use your product, because they know how it was built. And like yeah, don’t, don’t buy it. So initially, the marketing skills of a company are actually negative.
Writing to disk and the tyranny of small things
By Jeffrey M. Barber
Today, I’m writing about the process of writing to the disk and building a durable solution which can be survive both a process death and power outage. Well, actually, this is wasn’t written today but was written over the course of a week of writing code; in this spirit, it’s really a journey of how I approached a problem. At core, I’m building a custom embedded data store like thing for Adama.
I’ll also be looking into using RocksDB before I embark on writing a specialized solution for Adama. The goal is to solve the “single node” storage problem for Adama with a reasonable backup solution, and I’m optimistic that a reasonable solution can be found.
Actually, scratch that, this isn’t about reasonable, this is about having fun to squeeze pennies and make computer go fast. The central problem is what could be called a “tyranny of small things” where the hardware works on predictable batches. In other words, the more you give the OS, the more that will get done. Let’s validate this to ensure we are always close to what the metal can provide.
Progress on a new data store
By Jeffrey M. Barber
I’m happy to report a few users to the system! That’s pretty great, and I’m ahead of my own expectations.
Progress has been made on the high priority blockers as well as continued polish on the main infrastructure. Just the other day, I sorted out an interesting race condition where writes were out of sequence. This was detected as I was load testing the new storage engine. I’m feeling joyful as the new storage engine is shaping up to be better on a few dimensions, so let’s chat about the changes.
Introducing volatile data
By Jeffrey M. Barber
For those keeping track, I have a manifesto on user interface architecture where I outline how I intend to build a minimal UI kit on top of Adama. I’ve had a few starts of it, but I was getting distracted by the lack of polish on Adama. Now that Adama is stable where the primary critique is a combination of performance and scale, I’m paging in the second leg of my strategy. One thing that is on my mind is the role of volatile data.
So, I replaced gRPC with net and discovered more about latency
By Jeffrey M. Barber
As I’ve been mentally tortured by poor performance (and my inability to prioritize), I replaced gRPC with vanilla netty and very simple code generated codecs. Today, that effort went to “production” and the results are…