Blogs

RedMonk

Skip to content

The parallel universes of DevOps and cloud developers

The City and the City, by China MiévilleWhen I think about people who live in that foggy world between development and operations, I can’t help being reminded of a China Miéville novel called The City & the City. It’s about two cities that literally overlap in geography, with the residents of each completely ignoring the other — and any violations, or breaches, of that separation are quickly enforced by a shadowy organization known as the Breach.

Much like people starting from development or operations, or for you San Franciscans, the Mission’s weird juxtaposition of its pre-tech and tech populations, The City & the City is a story of parallel universes coexisting in the same space. When I look at the DevOps “community” today, what I generally see is a near-total lack of overlap between people who started on the dev side and on the ops side.

At conferences like Velocity or DevOpsDays, you largely have just the ops who have learned development rather than the devs who learned to be good enough sysadmins. Talks are almost all ops-focused rather than truly in the middle ground or even leaning toward development, with rare exceptions like Adobe’s Brian LeRoux (of PhoneGap fame) at Velocity NY last fall.

On the other hand, that same crowd of developers shows up not at DevOps conferences but rather at cloud conferences. They often don’t care, or perhaps even know, about the term “DevOps” — they’re just running instances on AWS. Or maybe another IaaS or possibly a PaaS, most likely Heroku, GAE, or Azure.

The closest thing to common ground may be events for configuration-management software like PuppetConf or ChefConf, or possibly re:Invent. But even when I was at PuppetConf, the majority of attendees seemed to come from an ops background. Is it because ops care deeply about systems while devs consider them a tool or implementation detail?

The answer to that question is unclear, but the middle ground is clearly divided.

Disclosure: Amazon (AWS), Salesforce (Heroku), and Adobe are clients. Puppet Labs and Microsoft have been clients. Chef and Google are not clients (although they should be).

by-sa

Categories: cloud, community, devops, Uncategorized.

  • mpdehaan

    I think in Ansible land (admittedly, the last paragraph applies to us) we’re starting to see a lot of this converge to where labels apply much less, so I don’t really feel this way.

    Mainly, a lot of people are rolling out ops infrastructure — and configuring the OS — for the benefit of their applications not segregated teams, and often in cloud capacities. So when they are doing it, they feel they are developers, but they are all talking about the very same tools.

    This is of course good because the main point about DevOps is not an ops thing, it’s to break down walls between Dev and Ops so developers know what happens in prod and ops know what happens in dev, an you look at software as one large organic system.

    Maybe if you’re a Developer in cloud API land, you were very “devops” from day one, so you’re less likely to apply a label to it.

    What’s most exciting though is so many operations and developer folks blurring together, that people can really be both, and people are developing some really compelling interesting and new tools where before the walls between positions tended to not encourage alternative approaches to how things get managed once deployed, or how they get rolled out.

  • Chris Haddad

    The devops story has been driven from ops stakeholders, and often lacks a compelling message for developers. Instead of shifting ops work to devs, or automating only the delivery side of the project life cycle, a message describing devops from a developer perspective will encourage interest. at WSO2, we have been describing how to re-imagine Developer focused activities, reducing dwell time, and increasing project velocity by using a DevOps Cloud embracing development activities and operations activities. You can learn more about the approach at http://wso2.com/whitepapers/devops-meets-alm-in-the-cloud-cloud-devops-paas/

  • williamlouth

    I think this has more to do with the speaker friend circle of the conference organizers than these communities not having any interest in the inner workings and challenges each one is facing.

    I gave a “QoS for Apps” talk at Velocity Europe that tried desperately to bridge Dev and Ops via System Dynamics ( Code + Flow + Policy + Control). Admittedly I had problems due to losing my voice because of a nasty cold just days before but I would not care to repeat the experience again irrespective. You are setting yourself up to be a fall guy as many other talks just banged on about metrics, monitoring and devops is ALL about the organization. Just imagine the shock many attendees get when you start putting up code and control theory on your slides.

    I don’t agree with the view the DevOps is ALL about the organization. That is not a holistic or systems view, at least from my own engineering perspective, but for the organizers this “is their thing”.

  • Michael Hüttermann

    This is a great post, Donnie, thanks for sharing. I’ve experienced the same. One example: giving talks at some DevOpsDays conferences, part of the audience of my talks felt a bit conservative about discussions targeting the “other side” (Ops=>Dev, Dev=>Ops), or even felt slightly annoyed by topics located exactly in the interface between Devs and Ops. This is interesting, isn’t it? Some people feel to be supporters of the DevOps movement and attend such conferences and are themselves not open-minded enough to close the gap between those two different functions in IT. Also some feedback about my “DevOps for Developers” book goes into this direction. E.g. some feedback suggests, for some guys discussing or rolling out one, two ops tools is everything that makes up DevOps. Certainly people have different contexts and backgrounds, and the DevOps movement started from the ops side, but nevertheless, somehow this is strange isn’t it? Maybe one reason is also that DevOps means many different things to different people. That was one reason for me to write the book in ’12 and to offer one definition of what DevOps is.

  • Pingback: Coming Very Soon: Monki Gras 2014. Why You Should Get Involved – James Governor's Monkchips

  • garethrushgrove

    I’m going to disagree (a little bit) with the lack of developers at events like DevopsDays, Velocity and PuppetConf. I’ve been to both, even organised DevopsDays events and meetups in London. I was originally someone who would characterize myself as a developer – now I don’t really characterize myself as either dev or ops. And I think this is increasingly true of a bunch of people at these events.

    If a developer is at a devops event and talking about load balancers do they look like an ops person to the casual observer?

    Another observation is that it varies a lot based on geography in my experience. So RAMP in Budapest last year I’d say was very developer heavy, DevopsDays in Hamburg and Gothenburg a few years back felt like they leaned towards having more developers, whereas the last DevopsDays in London felt more ops heavy. Velocity in London felt like it varied between rooms. PuppetConf in SF was maybe more operations people but it covered lots of beginner material and was several thousand people. Monitorama in Boston was mainly about people building/developing tools, even though a bunch of the people doing the developing would probably categorize themselves as ops folks.

  • Pingback: Repost: The parallel universes of DevOps and cloud developers – Donnie Berkholz’s Story of Data | Red Hat Developer Blog