From my last blog post, you know Kubernetes manages the blog you are reading right now. But I violated pretty much all the rules of good blogging by only briefly discussing why I wanted to start running my own production Kubernetes cluster in the first place, and how exactly I made that happen. I think I was just excited it was working and I wanted to share…

via GIPHY

Now, I’m writing to remedy my excited self’s mistakes. This blog mini-series makes the case for why I wanted to run my own Kubernetes cluster. It also contains the first of what I hope will be many posts deep diving into the steps necessary to utilize Kubernetes, and the other tools in the Cloud Native ecosystem, for personal, production use cases.

I’ve avidly followed the Kubernetes project since it was the basis of my undergraduate thesis in 2015. But despite all my reading and minikube experimentation, I felt I was missing out the important lessons you can only learn from using a technology to run real applications in production. I acutely felt this pain when contributing code to the Kubernetes ecosystem, as I was able to fix bugs, but didn’t have knowledge and empathy around the production user’s experience.

After a Saturday of disk partitioning, a trip to CVS for an emergency thumb drive, and much Googling, I’m writing this blog post from a MacBook Air running Ubuntu 17.10.

I won’t write an entire tutorial on the installation, as some great ones already exist (in particular, I benefitted greatly from this tutorial from CalTech and this tutorial from Christopher Berner). Instead, I’ll share why I installed Ubuntu 17.10 on my MacBook Air, some tips I found helpful during the installation, and the remaining shortcomings I hope to address in the coming weeks.

It’s not often that academia analyzes the unix tools we use everyday. But rsync is one fortunate exception as Andrew Tridgell not only wrote rsync while pursuing his PhD, but also published a short and accessible paper outlining its inner workings. While I’d highly encourage reading the entire paper, I took away one major tl:dr; from the rsync algorithm: be lazy. This lesson will be applicable anytime I write performance conscious code.

For the past couple of months, I’ve been working on Sheepdoge, a tool for managing your personal Unix machines with Ansible. It’s like boxen, but for Ansible.

One new sheepdoge feature I’m particularly excited about is the use of concurrent.futures during sheepdoge install. concurrent.futures provides a high-level API for executing code asynchronously, making adding thread/process based concurrency trivial. It is a standard library python module as of 3.2, and is available on python 2.7 through the futures backport.

Few programming experiences are more informative or rewarding than meaningfully contributing to open-source software. However, even programmers with strong technical skills can experience discouragingly high barriers to entry when contributing to a new project. This barrier to entry feels particularly high for the popular, high-velocity projects. Unfortunately, these projects are often those which first catch the eye, and attract us to open source. Overwhelming. Perhaps Steve Harvey shows it best…

Like over 3 million Americans, I struggle with OCD. OCD has impacted, and probably always will in some capacity impact, my life a lot. Unfortunately, software engineering, both my career and one of my favorite hobbies, is no exception.

What is OCD?

via GIPHY

Everyone who suffers from OCD has a different experience. For me, OCD manifests as certain distorted thoughts sticking in my brain. These sticky thoughts are typically catastrophic events touching on some of my deepest fears and most cherished values. Intellectually I know these events have little chance of happening, but OCD doesn’t care.

Like many others, I’ve spent the last couple of weeks since the election thinking a lot about new ways to empower and amplify all the voices fighting for justice. While it’s not easy to know what to do in a situation like the one we find ourselves in, I’m reminded of words from Bryan Stevenson, a civil rights lawyer, who spoke at my graduation back in June. His entire speech was insightful and inspiring, and one particular request stuck with me: get proximate. In other words, be as close as possible to the situations in which you most want to see change.

Over the course of my final year at Williams College, I spent a lot of time working on a distributed systems thesis with Professor Jeannie Albrecht. My thesis is entitled “Predictive Pod Auto-scaling in the Kubernetes Container Cluster Manager”, and it is entirely open-source. The written portion, presentation slides, and evaluation code can be found on my Github. Additionally, our contributions to Google’s open-source cluster container manager Kubernetes can be found on my fork. These changes will hopefully be merged into Kubernetes master branch soon.