Pusher's purist: Five steps to reaching your DevOps zen

Pusher describes itself as a hosted real-time messaging service, sporting as it does a selection of APIs, developer tools and open source libraries. The firm’s claim is that it simplifies the integration of real-time functionality into web and mobile applications.

Developers are supposed to be attracted to Pusher for its ability to build certain features into their applications including in-app notifications, activity feeds, chat and the ability to engineer-in syncing abilities across devices.

It sounds like a lot of Dev that needs intelligent connection and integration with quite a lot of Ops if it’s going to be able to run.

James Cunningham is head of DevOps at Pusher and insists he is a DevOps purist, not a DevOps spin doctor (as we know, there are plenty of those) due to his track record and previous roles in product development officer and as a chief technology officer.

Could Cunningham’s proximity to “real DevOps” provide us with insight and ammunition against DevOpswashing? You know… the kind of firms that do neither Dev or Ops, but have two guys in technical support that will talk to you about DevOps if you want. “So hey, we call this the DevOps Division (capital letters and branding trademarks) etc.”

1: Specificity factors in DevOps hiring

Cunningham says it's important to kill the silo that Ops (operations) used to live in and merge it into the Dev (developer) software engineering team - he also thinks it is important to hire DevOps engineers specifically, in a similar way to specifically hiring a frontend or backend engineer as a speciality in the engineering team.

"DevOps engineers are a force multiplier, so they don't necessarily need to scale up linearly with the team, particularly considering part of the role of a DevOps engineer is to share operational knowledge among an engineering team,” he said.

2: DevOps tooling democracy

Dedicated DevOps has a responsibility to ensure developers have the tools they need, but this truism does not lead us to a one-way street. That is to say, the rest of the engineering team has to be involved in the creation of tools, even if from a high level.

“The actual implementation can be handled separately although it is good to get wider involvement to lower the bus factor. It is also incredibly important that this be a rolling process that evolves over time. Business and technical needs change, yet a lot of tooling gets stuck in the past, so to speak," said Cunningham.

3 DevOps silo destruction

A slightly disturbing trend seems to be simply relabelling operations to DevOps, without breaking down the silo that operations itself used to exist within. Cunningham thinks it is up to the DevOps engineers themselves to force the break down in that silo where it does exist.

4: When to DevOps… and when to just Ops

Cunningham is of the opinion that, in a well-disciplined engineering team, DevOps engineers direct and oversee the operational aspects but do not necessarily maintain full responsibility… that still comes back to the purist operations function.

It’s a question of knowing when the job should be an integrated DevOps function and when it should be old school operations. Like, before we used to call it DevOps, remember?

5: DevOps trends and new demands

Looking at the road ahead technology wise, containers are definitely going to remain a trend in 2016, this much we know to be true. However, Cunningham thinks the focus will shift from container runtimes (like Docker and Rkt) and schedulers (such as Mesos and Kubernetes) to the build tools and pipeline.

Cunningham concludes: "Containers have gotten by fine so far being built from shell scripts, but this is not scalable. I see a need for a tool that sits between shell scripts and full-blown configuration management. I also think we are seeing software defined networking, at least in terms of overlay networks, fizzle out; in lieu of traditional networking to take advantage of the decades worth of optimisations that have gone into it."

The road to DevOps realism and enlightenment

Are we reaching the point where a new level of DevOps realism and enlightenment starts to cut through the stinky guff that the industry has thus far managed to produce from within its ranks? Could baseline (sorry, runtime) discussion at the coalface lead us away from DevOps washing or is this (above) another case of more of the same? Are there really seven DevOps truisms and we’ve missed two (or more) important factors here?

The road to DevOps realism and enlightenment is a road less travelled. Let’s keep walking - energy bar, anyone? ®