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
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
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
I hate giving Apple more money than I have to. Sure, I own a MacBook Air and it’s wonderful, but I chafe at Apple charging me $99 for an AirPort Express just to stream music wirelessly to my stereo. I don’t need another Wi-Fi base station, anyway. So I decided to build my own AirTunes server with a Raspberry Pi. Here’s how to do it really easily. Continue reading
I often get asked how to automate host naming and/or DNS records using Chef. In fact, there was an individual in IRC today who asked some variation of the same question I always get:
Currently I set hostnames on my nodes by looking up the ip from ifconfig and doing a reverse DNS lookup on that IP. It turns out this is painful since my upstream never sets the rDNS correctly without nagging. I’m thinking of just building a “nodes” data bag with IP -> hostname mapping. Is there a better way to do this?
Often I’ve answered people by telling them that if they’re using configuration management, the names of their hosts are completely irrelevant. They shouldn’t even bother adding them to DNS or to even care what their names are. I thought I’d explain my rationale behind this and why host names are largely unnecessary if you’re using a configuration management tool like Chef. Continue reading
A month ago, I presented a webinar entitled “Cooking on Windows with Chef” that demonstrates the power of Opscode Chef on Windows. If you missed the webinar, you can watch that recording here.
One major way in which Windows has lagged Unix/Linux is in the desktop-based virtual machine development model using tools like VirtualBox and Vagrant. Vagrant, if you’re not already familiar with it, allows you to bring up and tear down development environments very quickly, and provision (configure) them using the same Chef cookbooks with which you’d configure your actual production environments. To that end, a bunch of folks have released an updated version of the vagrant-windows plugin, which adds WinRM and native shared folder support between Windows guests and the host operating system. Vagrant-windows has actually been around for a while, but had to be updated to deal with the API changes between Vagrant 1.1 and 1.2. This took a significant amount of work. Continue reading
Ryan Holmes, the CEO of Vancouver social media startup HootSuite, wrote a column in today’s Financial Post entitled “Why Canada is failing at tech“. Holmes basically asserts that Canadians are “failing” at technology because the country isn’t graduating enough computer science and engineering talent to fill the available job openings. I don’t think Holmes has gone deep enough in his analysis. Why aren’t many people choosing computer science and engineering as career paths and the “jobs of tomorrow”? The answer to the question, I think, is pretty simple: it’s actually not a very nice job being a software developer. Continue reading