While the client library doesn’t adhere to the Go database standard, it is still starting to get some use. Therefore I decided to add CircleCI testing support, ensuring the code maintains a basic level of functionality.
Following up on my earlier post, it has been pretty straightforward to so far to migrate this blog from Rackspace to GCP. It’s going pretty much as expected, but the architecture is going to be slightly different than I initially thought.
Another interesting paper came my way, thanks to the Morning Paper mailing list. Nines are Not Enough:Meaningful Metrics for Clouds discusses a topic that I deal with regularly in my role at Google.
SLIs, SLOs, and SLA are easy to discuss in a general sense, but surprisingly subtle to put into practise. This paper, authored by Google engineers, explores why this is so, and offers a new framework for thinking about them.
As an Engineering Manager at Google, I get a lot of email — everyone does. Google — at least my group — doesn’t make heavy use of IM-like tools internally, and I’m happy about that. Combined with traffic from the internal system, it all adds up to a lot in my Inbox.
So I was forced to really think about how I handle it all — and not miss anything important.
I recently came across a new paper co-authored by John Ousterhout, one of the original authors of the Raft protocol. In it John, and his co-author, describe an approach which can double the throughput of some popular replicated distributed key-value stores.
Sometime ago I was asked where to begin to learn data engineering. It was a broad question, and it took some to understand what exactly I was being asked.
The batching of data or computation amortizing a fixed cost over multiple units — is a very common pattern in many computers systems. It’s particularly prevalent in networking and CPU memory accesses.
But the implementation of batching includes many subtleties — in particular when to wait for more data, and when to transmit what you have.