USENIX Blog

When you attend a talk that starts with a Google engineer asking, “What would happen if all of the machines you are running on restarted right now?” you might get really worried. Think about the Google services we use on a daily basis and what would happen if they suddenly stopped working—Google Maps, for example. Hopefully, we’d be able to get home from the office, but if we were travelling or looking for a business location, that would become a disaster. What about Google Search? Would we be able to even do our job if it went down?

I’ve taken a lot of classes in my several years attending LISA, and over that time, I’ve gotten to see a lot of different teaching styles and techniques. My least favorite style (and probably yours, too) is a strict lecture, where the instructor occasionally flips through slides, but mostly reads from notes, and has no engagement, no interaction, and no interest in whether the people in attendance are getting anything from the talk.

It’s 2017. Containers are “a thing.” For real. A few years ago, we were kind of wondering if they were, or if they were just a passing fad. Those of us who were busy Getting Things Done(™) don’t have time for all of the fly-by-night technologies that show up on HackerNews for a week, only to fall by the wayside. That’s the cheap excuse I’m using to justify my lack of experience with Docker, Kubernetes, and the whole containerization movement that has crept up in the past few years.

I’m a fan of documentation. I have been, ever since I first inherited an infrastructure and had to try to figure out what the previous admin had done. I try to write decent documentation—documentation that I wish had been was there when I first tried to learn about a particular system. I also find myself doing so much that what I can keep in cache in my brain is limited, and stuff I’ve worked on tends to “page out,” so to speak. Writing good docs is an excellent way to do your future self a favor.