Some of the blog readers may know that I (Aaron) have been doing a bit of traveling lately. Some of the conferences I have been attending fall under the DevOpsDays heading. Recently, I was at DevOpsDays Toronto and earlier this year at DevOpsDays Seattle. I've gone to so many (and applied to speak at more) mostly because I love these events. What's awesome, what really makes them stand out, is that they're not just another lineup of Big Names pitching their brand of How To Do DevOps Correctly, but that the organizers push for local and locally relevant content that speaks to their communities directly.

(more…)

This is the first post in our “Tools From the Kit” series. To see more posts in the series, checkout our introductory post.

If there is one tool that our engineering staff cannot live without, its most certainly GitLab. If your familiar with GitLab, then you probably know about it being a GitHub like tool that you can host on your own server, entirely for FREE! What you might not be aware of is that GitLab, the company, wants to build GitLab, the product, into a suite of tools to manage your entire engineering flow.

(more…)

As engineers we often find ourselves holding tight to the tools that enable us to be more productive every day. At Cage, we’ve built tools chains that drive what we do every day. These tools boost our productivity and velocity and let us feel safer as we build bigger and better things.

(more…)

It hasn’t been too long since Cage Data made an announcement like this, but here we are again. As we continue to grow, we want to make sure we’re continuing to offer the best possible customer support. After some conversations with our team we determined that our biggest need was some frontline customer champions to answer your calls and requests when the rest of us are knee-deep in technical problems.

(more…)

I’ve been inaugurated with my first DevOps Days. It was a fantastic, exhausting weekend where I probably gained more perspective on the DevOps community in 2 days than most of my working career.

What’s a DevOps Day anyway?

If you’re not familiar with the concept of the DevOps Days conference, it’s sort of like an industry conference injected with extreme participation. The attendance is kept intentionally low (although we were at about 425 attendees) and a major focus of the event is the Open Space meeting. Even the Keynote Speakers are encouraged to be new voices in the community over the existing and previous-years’ speakers. This leads for an awesome overall message of “your voice matters.” The only downside is that you meet a ton of people and do a lot of brain-stretching in a short period of time; my introverted side was totally spent by Saturday morning.

Technology can’t fix a people problem

My first major takeaway from the convention was this: People are important. If you find yourself “Rubbing DevOps on it” but the rash just won’t go away, it’s not a technology problem, it’s a culture problem. I could repeat this over and over, but helping people is why I fell in love with technology. The primary motivating factor behind leaving my previous jobs has been a culture issue. It was never that I didn’t love the work, it was that I hated the way the organization’s culture permeated their workforce. Culture matters. Your people matter. If you focus on your people, your product will reflect that.

Automate your 💩

Secondly, it’s all about technical debt. This was a new term for me, personally, but the concept isn’t new. The idea focuses mainly on opportunity costs for any task. Every time you cut a corner, there’s work that you’re not doing that needs to be completed. This work can manifest suddenly as unplanned work when multiple band-aid fixes inevitably go wrong, or when something breaks and there’s not enough documentation and the on-call tech has to troubleshoot the entire issue from scratch. Except that tech doesn’t even have information about what the system is supposed to do. So it was crystalized like this for me:

1. If you can automate it, automate it. If a human doesn’t have to be involved, why make the work for them? This task is important because it frees up man-hours for more important work.
2. If you can’t automate it, you need documentation. For incidents, Minimum-Viable Runbooks are crucial. There should be no guessing what systems do and how to fix them at 3am.
3. Any task that improved quality of life for your employees is critical. Getting paged after hours interrupts sleep and reduces quality of life. Removing unplanned work takes priority even if that means your planned feature release gets delayed.

DevOps CT: Challenge Accepted

All in all this was an awesome conference that greatly encouraged me to build a similar community in Connecticut. Dave and I have already begun by planning our first DevOps CT Meetup. So if you are interested in getting connected with the DevOps community, please sign up and join us in conversation. I would love to talk about all the pie-in-the-sky ideals and discuss all of the realistic challenges that we face daily when trying to affect real culture change in CT. It’s a huge challenge to take on major monolithic organizations like the insurance giants in Hartford, but I leave it to Barney Stinson to share my thoughts on this: “Challenge Accepted.”

This was a guest post written for the VictorOps Blog. To help make your on-call suck less, check out VictorOps

In the world of IT Operations, there is no escaping the Dreaded On-Call. Someone has to keep a look out at night to make sure the business continues to run and we’re not all going to get a nasty surprise come the morning.

(more…)

Since 2009 I have been working with the Kampala Children’s Centre in Kampala, Uganda with the mission to provide resources through technology for the children at the center to have new opportunities for their futures.

(more…)