Ever since I became a product manager at Chef in January, I’ve observed a fair amount of confusion and uncertainty in our industry about the role of product management. Although this is my first job as a product manager, I now have enough of a grasp of the responsibilities that I can offer a succinct explanation of the role (so if you’re reading this, dad, you now know what the heck I do.)
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
A couple of weeks ago, Mathias Meyer wrote an article entitled “From Open (Unlimited) to Minimum Vacation Policy“, detailing how his company, Travis CI, has moved from away from an “unlimited” vacation policy. Mathias found that the dangers of unlimited vacation policies were coming true: Engineers weren’t taking any or enough vacation to avoid burning out. So, he decided to move Travis to a model where a minimum amount of vacation is required. Sounds great, but doesn’t it seem like we’re right back where we started? Isn’t this just a traditional vacation policy couched in different terms? And what was so bad about traditional vacation policies, anyway? Continue reading
One of my last projects for 2014 is to move Chef off our old Sympa mailing list server to Google Groups for Business. This migration was codified in Chef RFC 028 a few months ago, but we wanted to hold its implementation until the migration to the chef.io domain was completed.
Moving the list of subscribers is fairly straightforward, but migrating the list archives has been enough of a chore that I thought I would document the required steps. This way, if anyone else is faced with a similar task, they do not need to spend hours Googling and/or banging their head against the wall of the Google Groups Migration API, where there are dragons — lots of them. Continue reading
A couple of weeks ago I finished reading Tracy Kidder’s 1981 Pulitzer Prize-winning book, The Soul of a New Machine, in which he followed Data General (DG) engineers around for over a year while they tried to pull a miracle minicomputer, codenamed “Eagle”, out of the company. The firm’s survival was on the line. They were being slaughtered by Digital Equipment Corporation’s VAX 11/780 and they needed a winner, badly.
DG’s “new machine” ultimately became the Eclipse MV/8000, a name that, like the CDC 6600, is nearly unrecognizable to anyone today besides old computer nerds like myself. In other words, it’s damn hard to build a company that lasts. Both DG and its main rival, DEC, are gone, shoved aside by the PC revolution and the march towards inexpensive, x86-based servers running Linux. And so if you work in technology, you probably feel (or should feel) an immense sense of urgency, because there is always a surplus of discontinuous innovations just around the corner to disrupt whatever you’re working on right this instant. And those disruptors will in turn be disrupted by others, and then by yet others… 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
This is another in a series of reviews on management & leadership books that I’m doing on the blog.
Last week I finally sat down and read Jim Collins’s Good to Great: Why Some Companies Make the Leap… and Others Don’t. Obviously, at Chef we’re trying to build a great company, and I thought this book would show us a way forward.
Good to Great was written in 2001, so you might be wondering why it’s taken me 13 years to crack it open. Well, quite honestly, I once had a co-worker and friend who was given this book upon starting a new job, and he scoffed at it. In retrospect, I think he did so because it was obvious that his employer was most definitely not on the path to greatness. The notion that handing out copies of a business book could fix their dysfunctional culture & failure to execute is laughable. It’s about as useful as giving anti-drug pamphlets to a meth user. In any case, I associated his mockery with the conclusion that the book is bad, which it most definitely is not. Continue reading
This is the beginning of a continuing series of reviews about books on management and leadership. Think of it as a “papers we love” but for folks who have chosen to pursue a non-technical path in their engineering careers.
At some point I figure I’d like to be CEO of my own company. So it was with great interest that I picked up Ben Horowitz’s “The Hard Thing about Hard Things”, which is partly a memoir about his time running LoudCloud and Opsware, which he eventually sold to HP in 2007 for about $1.6 billion. Along with Marc Andreessen he then went on to found the well-known Silicon Valley venture capital firm Andreessen Horowitz, which has invested in Facebook, Foursquare, GitHub, Pinterest and Twitter, among others.
From this CV it sounds like he has been wildly successful as an entrepreneur and CEO. But like all Hollywood stories (and Wikipedia articles) it glosses over the twists and turns in his career that, for instance, almost saw LoudCloud go bankrupt several times. (He also pivoted the company from being a cloud services and hosting company to a product company, nearly bankrupting it again.) Horowitz claims that many management books out there only give you advice about the happy path, but don’t teach you how to deal with adversity. That’s where the book comes in: no-nonsense advice about the many difficult situations you’ll find yourself in as a CEO. 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