Live data from Hacker News

DevOps uses a capability model, not a maturity model

octopus.com

51–60 of 115 posts

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

#51

Lately I've been made to understand that DevOps or Software Engineering is not for me, capability/maturity models, processes written in anything other then code, or metrics this and that just ism't me. We can argue about the meaning of words all day long but like I said this just isn't me. Some of us just prefer to say close to the metal (as in reality with all its complexity that escapes the precision of words and t…

I don't think any place actively looks for grey-beards in particular. But well, they do have an easy time posing as seniors.

The only question is whether pushing for working things instead of nice talk will get enthusiastic support or opposition from the management.

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

#52
post #16

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…

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.

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

#53
post #44

Earlier quoted context omitted.

> 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. The "DevOps" job title can arguably just be a sysadmin, but I do think the main ideals of the movement are just so tightly ingrained in software now that we don't even notice. It's e…

> It's easy to forget that 10-15 years ago, the most common dev/ops model was "toss it over the fence" Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs. The wall was never the only model around. It still isn't. The same kind of company that practiced it still largely have walls. The IT industry just hired…

> Hum... My first guess is that what really changed was the ratio of developers working on places that do this to the ones working on places that integrate the jobs.

Well sure, and that's because software companies that integrate the jobs is now so much more widespread and commonplace, thanks to "devops". Kind of my point.

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

#54

Lately I've been made to understand that DevOps or Software Engineering is not for me, capability/maturity models, processes written in anything other then code, or metrics this and that just ism't me. We can argue about the meaning of words all day long but like I said this just isn't me. Some of us just prefer to say close to the metal (as in reality with all its complexity that escapes the precision of words and t…

Companies who need every engineer to "Do Everything™" are doing it wrong. A team may need to cover a lot of ground, but by putting together folks who have different skills. It's a management skill to assemble a team with diverse experience, rather than only hiring individuals who are "a team on their own".

I don't think you should feel excluded from "Software Engineering" just because you don't have a passion for managing containers. We need people who can write great code in the world, too!

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

#55

I don't think this is an either/or problem. Very simply put, the maturity and capability form a two-dimensional "grid", within which each organization fits its levels - e.g. let's say "maturity levels" on the vertical axes, and "capability controls" on the horizontal one. Where the two meet on the grid, you get the two-dimensional org level. I recently had to conduct an org maturity analysis and identified a #1 (out…

Doesn't this come down to tail vs. dog?

Suppose I plan to assemble infrastructure for some ideal of "Deployment Maturity" - no downtime, any time of day, one-click, etc. But it turns out the development team has designed the software to be un-load-balanceable thanks to in-memory sessions, so, thud goes my big plan. That's a very common problem.

Of course many of us see a "proper" devops discipline as interdisciplinary, so I suppose those folks would tell me to get in there, gently push devs out of the way, and fix that session mgmt problem. Of course I need advanced skills, but I also need advanced permission. Somebody's gonna fight me. Now I'm turning into more of a site reliability engineer.

So the maturity model definitely applies - especially when it comes to security - but when you're in devops-just-means-ops mode, you're much more tail than dog and it seems like you have no choice but to put capability first.

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

#57

Lately I've been made to understand that DevOps or Software Engineering is not for me, capability/maturity models, processes written in anything other then code, or metrics this and that just ism't me. We can argue about the meaning of words all day long but like I said this just isn't me. Some of us just prefer to say close to the metal (as in reality with all its complexity that escapes the precision of words and t…

SOURCErer

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

#58
post #17

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…

For me what upsets me about devops work, is that for many organizations it is a synonym for systems engineer, lots of Ops and very little Dev.

The term Devops has been almost completely co-opted by sysadmins at this point.

Platform engineering is a term I used to use in its place to try and differentiate but it seems that's being taken over now as well.

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

#59
Working with the logic that the author talks about can cause terrible situations for large companies. If you create a culture based on trying new things in companies that are in constant business development, you must create a culture that will take responsibility for it. otherwise, you'll have environments where answers to "hey why isn't this working" questions can't be found.

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

#60

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.

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 compared to "proper" programming language or purpose built DSLs.

Like, I complained that Puppet is just kinda "shitty half-finished programming language" compared to just having Python/Ruby as DSL but boy I'm fucking happy to use it now (and to be entirely fair, it got better over time as a language) compared to whatever the fuck tool is in vogue this time that uses the "data language + template language" (because apparently programmers deploying the code can't program or something) model for interaction.

Same kind of work sans running to DC to fix stuff but you now have black boxes you have no chances fixing/analysing yourself and your broken code might fix itself next day because you thought it was your bug, but just a given cloud API decided to return nonsensical error that looked like it was your fault (greetings to MS Graph API team here)

Post reply on HN