In November 2014, I started helping software teams ramp up on Amazon Web Services and DevOps. This was gratifying work because a few years prior, I was involved in a project that did a terrible job of DevOps and suffered greatly for it. Now I was helping other teams avoid that same fate.
And what an adventure it turned out to be! I got the chance to work with Intel, Infusionsoft, 3-person startups, a well-funded Spotify competitor and so many other interesting companies doing interesting things. I called the consulting practice Phoenix DevOps because, well, I live in Phoenix, Arizona, and it turns out the concept of immutability (sometimes known as “Phoenix Servers”) is a central tenet of DevOps.
Along the way, I wrote A Comprehensive Guide to Building Scalable Web Apps on AWS, Part 1, and gave lots of DevOps presentations at various meetups and conferences.
During that time I also discovered the outstanding Blog of Yevgeniy Brikman (“Jim”). Jim mentioned one day he was looking for DevOps people and I loved his work, so I messaged him: “Hey, I do DevOps for lots of teams and have no time right now but let’s talk!”
It turned out Jim was doing consulting very similar to what I was doing through his own consulting practice, Atomic Squirrel. And after many conversations and trial projects, we decided we really liked working with each other.
As we compared all our experiences, we realized we’d basically been doing the same thing for every client. Setup a best-practices VPC, automate deployment, setup monitoring/metrics, get ramped up on AWS, etc.
Doing consulting on an hourly basis was one paradigm for helping clients solve these problems, but what if we could solve the problems really well one time and then consult with clients merely to help them adopt what was already built? That would mean we could significantly lower the cost and time needed to get your DevOps on.
Well, that’s what we’ve decided to do! And so today, it is my pleasure to announce that I am officially winding down Phoenix DevOps and joining with Yevgeniy Brikman in a new company we call Gruntwork.
Why call it Gruntwork? Because that’s what this work is for almost every software team. Whatever app you want to build, the infrastructure stands between your vision and your app; almost no one gets excited about automating their infrastructure. Not to mention that it’s hard to find DevOps engineers, they’re often expensive, and they hold all the keys to your kingdom. And when they leave, then what?
So Gruntwork is here to do your grunt work for you, and because of the way we’ve set things up, and the thousands of hours of collective experience we have, we can help you achieve a result that’s more effective and less expensive than the most amazing DevOps person you could hire.
One other aspect of Gruntwork that’s important to Jim and me is that Gruntwork has to be able to completely disappear and you should still be ok to run your infrastructure. Would I base my important project’s entire infrastructure on a new company that was just started by a couple of guys? Only if I had complete control of the source code and could run it without them.
So, unlike most businesses which strive to build lock-in to your product, we are actively striving to build “not lock-in”. It’s actually kind of hard to do sometimes, but it means that customers can choose to come back to us not because the cost of switching is so painful but because we continue to actively provide them value.
There’s more to share in the Gruntwork story, but I think that’s enough for now and we’ll announce more when we’re ready. In the meantime, I am thrilled to be working with Jim, who’s been a fantastic business partner so far, and I am thrilled to embark on this new adventure!
Thanks for reading. Now time to get some Gruntwork done…