One of the vendor’s lead technologists mentioned that it was pretty involved and it sounded worthy of a good blog post. That mention had come up again when another piece of architecture was discussed.

On the surface this had seemed like a good thing that the company was working at the edge of this space, but as the day went on and the themes of simplification of architecture and focus were discussed, it had become apparent that they had spent entirely too much energy in a space that was still nascent in the industry building a complex data and analytics pipeline. Much of this effort would have been better spent on simplifying the ability for new data insights to be generated and productizing them instead.

While it may seem somewhat meta and ironic to discuss the merits of blog posts in a blog post, this seemed like a good experience to share.  Blogging about bleeding edge technical pursuits at your company can have other benefits such as building the strength of your brand in the technical community which can be a powerful recruiting boost.  Just don’t conflate useful research and POC’s that you learn from and blog about with what you actually put together for your production data architecture nor lose sight of the actual analysis goal.

Photo Credit: Link by Rob Davies

You’re better off taking real steps to change your habits first and after you’ve adjusted your routine for the better even if in a small but measurable and consistent way, then make your purchase for whatever will save you time or help you get to the next plateau. So start walking more, eating better, or doing small home projects first before making your bold proclamation purchase.

Here’s the kicker. This is not the end of a post just talking about your personal life…

Businesses fall into the same traps!

It can manifest by hiring some outside consultant or speaker or having a series of large offsite meetings intending to effect change but in the absence of management and cultural support for the initiative. The response within the events themselves can run the spectrum from excitement to disinterest, but often the same end result of no meaningful change occurs without proper pre and post event alignment and follow-up.

In the DevOps space we’re at the point on the hype curve where organizations with a shallow understanding want to jump on for touted benefits, but aren’t really interested in transformation. That’s not going to happen no matter what consultant you hire.

There’s a great clip from the consultant Andrew Clay Shafer on the Food Fight podcast “The Future of DevOps”.  The whole show is a fantastically blunt, but very real assessment and discussion of learning organizations, DevOps, and a host of worthwhile topics and worth a listen, but you can hear the clip here:

https://www.youtube.com/watch?v=jT6JdGHVbj0&feature=share&t=13m37s

We want “The DevOps” but we don’t want to change anything. Is there some way that we can DevOps without changing anything. Give us that thing. Can we just have the DevOps certification and then we’re done with you?

Hiring a consultant or even getting a handful of people training/certification is easy. Changing your organization, changing multiple teams’ responsibilities and relationships to each other, building trust and tearing down walls is hard.

Another inspiration for this post was the video Don’t Reward Yourself Before You Earn It by John Sonmez

Photo Credit: Link from http://taxcredits.net/

I worked at a company several years ago. We created a dedicated devops team. The rationale was solid – the company had a monolithic idea of roles and titles. We also had a large group on both sides that were only interested in doing their little bit and going home. By creating this title/team, it was easier at a company level to justify them working on non-standard projects.

So a “devops” team was created. This was a small team of what essentially boiled down to “super sysadmins”. We wrote puppet manifests, worked with the developers to automate build processes…shit like that.

What ended up happening was that the devops team was seen as elitist by the operations team, nosy and invasive by the developers and everyone just passed the blame on to them – “Devops did that. Not us”

In my department we setup a DevOps responsibility rather than a team or specific job title. The responsibility lies with a subset of the sysadmins and developers. It doesn’t take them out of their main teams and it’s not their only responsibility.  They do their main day to day work respectively with the rest of the sysadmins and developers but additionally have a role being on call, exposing monitoring capabilities in code as well as hooking it up to tools, setting up automation, doing deployments, etc.   Lessons learned are shared with the rest of their teams and the members with this on call responsibility are not coincidentally also some of the most well respected troubleshooters and thought leaders in their groups leading the whole team to improve.

User stories for themselves or other dev/sysadmin team members are created in JIRA under a DevOps epic along with a DevOps label. Though it’s not a perfect world where these stories are always done right away in the next sprint or on top of Kanban TODO list, the team members do have incentive to push for the improvements generally in the areas of monitoring or some reliability improvement.

As with many places, there isn’t a special budget to just spin up a new DevOps team, but by building the roles from within existing teams we captured the experience of the teams.  Augmented occasionally with some help from automation experts from other parts of the organization, this has worked well. It should go without saying that members with DevOps responsibility should have capacity budgeted in their sprint to deal with production issues and continuous reliability improvements, but sadly common sense is not necessarily common.

Photo Credit: Doc Searls – Link