Pierre Zemb

Engineering Manager @ Clever Cloud
Distributed and Database systems

The unseen treasures of Infrastructure Engineering: Academic Papers

I really like using RSS feeds. My Feedly account has more than 190 feeds, all neatly organized by categories. They help me keep up with new ideas and interesting blog posts about engineering. But there’s another source of information I’ve been using for a long time that not many people know about: academic papers. You can discover details about infrastructure that you might not find in regular blog posts. Academic papers, unlike typical blog content, often dive deeper into specific aspects of infrastructure.

Best resources to learn about data and distributed systems

Learning distributed systems is tough. You need to go through a lot of academic papers, concepts, code review, before being able to have a global pictures. Thankfully, there is a lot of resources out there that can help you to get started. Here’s a list of resources I used to learn distributed systems. I will keep this blogpost up-to-date with books, conferences, and so on. A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

Crafting row keys in FoundationDB

As I’m working on my latest contribution around FoundationDB and Rust, I had the chance to dig a bit into how FoundationDB’s bindings are offering helpers to generate keys. Their approach is interesting enough to deserve a blogpost 😎 Row key? When you are using a key/value store, the design of the row key is extremely important, as this will define how well: your scans will be optimized, your puts will be spread, you will avoid hot-spotting a shard/region.

Notes about ETCD

Notes About is a blogpost serie you will find a lot of links, videos, quotes, podcasts to click on about a specific topic. Today we will discover ETCD. Overview of ETCD As stated in the official documentation: etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node.

10 years of programming and counting 🚀

I’ve just realized that I’ve spent the last decade programming 🤯 While 2020 feels like a strange year, I thought it would be nice to write down a retrospective of the last 10 years 🗓 Learning to program 👨🏻‍💻 I wrote my first Hello, world program somewhere around September 2010, when I started my engineering school to do some electronics, but that C language got me. I spent 6 months struggling to understand pointers and memory.

Announcing Record-Store, a new (experimental) place for your data

TL;DR: I’m really happy to announce my latest open-source project called Record-Store 🚀 Please check it out on What? Record-Store is a layer running on top of FoundationDB. It provides abstractions to create, load and deletes customer-defined data called records, which are hold into a RecordSpace. We would like to have this kind of flow for developers: Opening RecordSpace, for example prod/users Create a protobuf definition which will be used as schema Upsert schema Push records Query records delete records You need another KeySpace to store another type of data, or maybe a KeySpace dedicated to production env?