The other evening I went to a very informative talk by Joe Stein on Apache Mesos at the New York City DigitalOcean Meetup. I have to say that I’m very impressed with DigitalOcean organizing meetups about interesting technology that they use in their stack. Ever since I first saw DigitalOcean at the New York Tech Meetup several years ago, I knew they were going to go places because of their strong developer orientation — a niche that Amazon Web Services has consciously left behind in the pursuit of enterprise cloud adoption.

Although I learned a lot from the talk, something that Joe said at the very end about “no longer needing configuration management like Chef or Puppet” made me roll my eyes yet again. I’ve also heard people say sentences like, “we have Docker now, we don’t need configuration management.” My reaction really has nothing to do with the fact that I work for Chef. If there truly is a configuration management killer out there, I would love to know about it, and if it is real, I would seriously contemplate quitting my job and going to work for that vendor.

My objection is basically that declaring the death of configuration management is a really naïve way of thinking. Do you still need to configure things when running applications under Mesos? Yes? Then you still need configuration management! Many of these presentations about the new-hotness-funnily-named-hipster-technologies have a slide that looks something like this (I’ll pick on Joe here again for a minute):

This looks like a shell script that you cooked up on your laptop! Moreover, that payload (yourScriptAndStuff.tgz) that Mesos is going to unpack and run in your cluster — how did it get created? More shell scripts!

In sum, I mostly object to the cognitive dissonance that I detect from these types of presentations. Let’s see: Mesos is a system that gives me a “data center operating system” to abstract all the compute resources like CPU, memory, disk, etc. I can simply declaratively state which of those I need, and a bunch of schedulers and executors will pick up my job and run my job somewhere appropriate. That’s great. Now how do I actually use this tool? I write a bunch of imperative scripts? What? Why would I want to do that?

Docker suffers from a similar problem. Okay, so you’re giving me a wonderful abstraction called the “container”, which is a portable, self-contained runtime image for my application. I can run it anywhere! That’s awesome. How do I build it? Oh, I have to write a “Dockerfile” which appears to be a cross between a Makefile a shell script, and CONFIG.SYS. I’m not sure how that’s scalable when I have 500 applications and 20 versions of each.

The whole point of configuration management is to give you a declarative interface to something you would have done imperatively, because it’s easier to understand and maintain declarative statements rather than imperative ones. And so long as we have computers, we have things that need configuring. Unless you want to spend your days building things by writing one-off scripts, you need configuration management.

This is another in the series of technology management, entrepreneurship, and business book reviews that I’m doing.

Po Bronson has always been one of my favorite journalists if for no other reason than that his book, What Should I Do With My Life? was instrumental in setting in motion my career direction (minus a brief stopover in journalism-land myself). Bronson wrote that book after he’d been a reporter for Wired in Silicon Valley through the 1990’s. After the bubble burst and he became disillusioned with tech and startup culture, he took his career in a different direction and now writes commentary about the evolution of American society.

Bronson’s The Nudist on the Late Shift And Other True Tales of Silicon Valley was published in 1999, right before the end of the dot-com bubble. Knowing how the story ended up gives us the ability to look more broadly at the tales told here and assess them critically. For example, if we had hypothetically read this book in 1998, could we have predicted the bursting of the bubble? (Probably.) Are we in a bubble now, and will it burst again? (Possibly-to-probably.) But more importantly: what forces underlie the industry, and how does one remain optimistic in the face of so many actors who aren’t primarily motivated by the tech itself? Continue reading →

This is another in a series of reviews on management & leadership books that I’m doing on the blog.

Geoffrey Moore wrote his seminal product development book, Crossing the Chasm, back in 1991. That was eight to ten years before the first dot-com bubble. Now, if only entrepreneurs in those heady days of pets.com had read this book, just think of how much capital, venture and otherwise, might have been preserved. Moore’s lessons are still extremely relevant nearly a generation later, and indeed, I see many companies making the same mistakes in product development & execution that he describes here. As such, the book should be required reading for any senior engineer, product manager, or product marketing person. This last group was initially the target audience for the book. Continue reading →

The Hippocratic Oath, taken by doctors, is often paraphrased as “first, do no harm”. I’d like to note the broad applicability of the Hippocratic Oath to system administration. What, for example, is the first thing that you do when receiving a Severity 1 incident in the middle of the night? Correct answer: Look around at your surroundings but don’t change a bloody thing. No good has ever come to a system administrator whose first response is to pound the keyboard furiously and poke around systems, making random changes. This isn’t Hackers, after all. Like a doctor, you need a hypothesis as to what is wrong before operating on your patient.

Beyond just incident handling, though, I’d like to apply the Hippocratic Oath for System Administration using a philosophy that I call, somewhat uncreatively, leaving the defaults the hell alone. Too often I’ve seen people randomly change configuration settings without a true understanding of why. This behavior applies not only to system administrators randomly tuning Linux kernel parameters or PostgreSQL postgresql.conf settings without rhyme or reason. It also applies to the way in which applications are set up in the first place. In this post, I’ll give you some of my guiding principles for leaving things alone and just accepting the defaults even if you know they might not be optimal. In other words, leave the unnecessary tuning for your car, not your job. Continue reading →