Live data from Hacker News

DevOps uses a capability model, not a maturity model

octopus.com

61–70 of 115 posts

Re: DevOps uses a capability model, not a maturity model

#61
post #16

Earlier quoted context omitted.

This isn't unique to devops, this is a general software thing. But there is an answer, which is the standard technology stack: - AWS - Postgres - Linux - Docker - Jenkins or similar - Slack - Pagerduty - Jira - Packer - Terraform - etc If you stay on the path there will be dozens of tools, plugins, and paths to do outstanding things with minimal work. Parallelising builds for example is built in to jenkins (if you de…

You'll probably spend at least an hour figuring out IAM permissions before you even get to deploy a VM.

nah just throw few layers of abstraction and throw a templated YAML at another tool that sets it all up for you!

Something broke ? Well, rip it up and reinstall! But what about the data ? Who cares?

Re: DevOps uses a capability model, not a maturity model

#62
post #24
post #19

Earlier quoted context omitted.

For many organizations, a rebranding of systems engineer.

Hence the call out. There is a "Dev" in DevOps which was meant to cross the organisation silo of developers and system admins, to "shift left", to understand the value chain and do whatever to deliver value. Which meant different things to different people, and it ended up meaning different things to different people.

"Dev" in our Devops (we call it sysops usuall tho) is "we make the tools to glue stuff together instead of relying on dev teams for anything that's longer than few hundred lines of code long.

Re: DevOps uses a capability model, not a maturity model

#63

DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was Syst…

> DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together

I would argue that it was the other direction, in my experience the DevOps philosiphy was very similar in at the core to the agile philosophy; however it met the same fate as the agile movement. Everyone who was an "agile" consultant or "scrum master" found a new buzzword to declare themselves experts of and then use to go around doing a whole lot of nothing and generating impressive sounding promises, before moving onto the next gig.

Re: DevOps uses a capability model, not a maturity model

#64
post #60

Earlier quoted context omitted.

As a developer and sysadmin, devops is distinctly different thing. Deep knowledge of operating systems is traded for knowing how to manage an entire virtual data centers with code. This is far beyond the “scripting automation” of the past. In my perspective, DevOps is a fundamentally different job from what Systems Administration has historically been. It’s a strange new world to me but I like it.

As a developer and sysadmin, there is no trade and only difference is that you probably (and I'm saying probably because probably some poor fucker had at some point) won't need to debug NIC driver/firmware problems on "cloud" server. We have both on-prem and cloud stuff, we've ran automation (via Puppet mostly) from the very beginning, and so far biggest difference is that writing template-backed YAMLs is utter shit…

If you listened to half the managers at my current client DevOps simply means using YAML to configure your infrastructure.

Re: DevOps uses a capability model, not a maturity model

#65

DevOps as a movement died when it started being used as a job title. In my experience, it quickly stopped being a philosophy for Dev and Ops teams to work on working better together and just because a new name for System Administrator. Before the popularity of the term "DevOps" it was always true that any System Administrator worth hiring knew how to script for automation (the job title for people who didn't was Syst…

As a developer and sysadmin, devops is distinctly different thing. Deep knowledge of operating systems is traded for knowing how to manage an entire virtual data centers with code. This is far beyond the “scripting automation” of the past. In my perspective, DevOps is a fundamentally different job from what Systems Administration has historically been. It’s a strange new world to me but I like it.

Developers are allowed to call themselves developers at any layer of abstraction. Why shouldn't that be the case for System Administrators?

Re: DevOps uses a capability model, not a maturity model

#67
post #2

Useful take on a common problem. Another way of approaching the same concept would be through the Cynefin[0] framework; maturity models occupy the simple or complicated contexts, whereas capability models can be fulfilled via iterating in the complex domain. [0] https://en.m.wikipedia.org/wiki/Cynefin_framework

Cynefin is a great model - I must admit I've been insterested in it for a long time (I think Liz Keogh brought it to my attention) - but I've not applied it practically. Anyone got ideas for using it IRL?

There are a couple of specific situations I tend to run into fairly frequently with my consultant hat on:

1. People or organisations wanting to implement process by well-defined stages and checklists. They'll see that works in certain situations elsewhere, but not realise that such processes will fall apart quickly in the complicated or complex regions they're trying to manage. Talking through where they sit on a Cynefin diagram can help them understand which action model is the most useful, whether it's really possible to define "best practice" for any given situation, etc.

2. Products being managed as though they were projects. Big organisations tend to run on a project model by default because it seems like a way for them to manage risk - a certain amount of budget signed off for a few months to a year that ensures X, Y, Z is delivered for a certain timeframe. The true risk is that absolutely kills innovation for an early stage product looking for PMF. You don't really know what the end result is supposed to look like, but you probably do know what the process for getting there should be. Being able to talk about complicated (often, projects) and complex (often, product development) regimes being distinct areas that require different handling is a good start.

Re: DevOps uses a capability model, not a maturity model

#68

What upsets me about devops work is that everything I do at a client is a lineage of architecture and design that needs to be maintained going forward and it only exists at that client. The lineage of interesting or useful things I do are tied to the client and dies with that client or when I leave. I just think of the thousands of CI/CD systems, build systems, attempts at parallelising builds, impressive optimisatio…

> and there's no cross polenation except when they are open sourced

This is true of software dev as well. Open sourcing things is something you have to sell well and demand up front.

Re: DevOps uses a capability model, not a maturity model

#69
Has DevOps, the approach to software development that accentuates the amalgamation and communication between software developers and IT experts, undergone a rebranding effort in recent years, replacing its nomenclature with Site Reliability Engineering (SRE)? Was this transformation brought about due to a growing demand for individuals who possessed a modicum of familiarity with cloud technologies, and sought to transition into teams responsible for software reliability engineering? Moreover, did this shift also encompass DevOps practitioners with rudimentary coding proficiencies?

Re: DevOps uses a capability model, not a maturity model

#70
My challenge to the author is why can't maturity models be dynamic and continually improved. What is being suggested here is too complex and involves a lot of busy work.

Why can't you, as part of the process implement a capabilty driven dynamic (as in you review and change it) maturity model?

I mean, capability driven sounds great to talk about but how do you go about implementing it? A maturity model is simple to define and measure. I worry about endless meetings with what is proposed here but maybe I misunderstood a few things.

Post reply on HN