DevOps

1667 readers

29 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Posts must be relevant to DevOps
No NSFW content
No hate speech, bigotry, etc
Try to keep discussions on topic
No spam of tools/companies/advertisements
It’s OK to post your own stuff part of the time, but the primary use of the community should not be promotional content.

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 1 year ago

MODERATORS

[email protected]

Thinking in Systems: A Sociotechnical Approach to DevOps (thenewstack.io)

submitted 11 months ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

I'm the author. With 5 years experience as a DevOps Engineer then Lead, I've wanted, for a very long time, to distill my critique and pave a way toward a healthier practice of DevOps. Before anyone jumps to tell me how DevOps Engineer is a misnomer, I address this in the article.

I wrote this piece because DevOps has all too often been misunderstood as a practice. Here I attempt to examine successful DevOps practice as a sociotechnical solution that weds culture and tools (the DevOps most are familiar with) with radical agency and visibility. I reference some stupendous thinkers in this space, like Jabe Bloom and Andrew Clay Shafer who were the first to argue for a sociotechnical approach to our work as IT professionals.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 11 months ago* (last edited 11 months ago) (2 children)

I agree that complexity is the problem and I'm avoiding Kubernetes like the plague. I set up a nomad cluster in a few days and it just works, has service discovery, and is perfectly simple to understand. But there are almost no books or courses about it, because Googles influence meant that everyone started using Kubernetes, and it's a mountain of complexity requiring entire teams to manage it.

I didn't really understand the rest of the article. I've never been very good at understanding what holistic means in practical terms, and what we should change specifically in how we work to become efficient.

[–] [email protected] 2 points 11 months ago (1 children)

Hey there! And thank you for reading.

Let's take your example, as a Nomad cluster operator. The Acme Corporation may have a team for provisioning and maintaining this Nomad cluster. The organization wants to give customers the option for self-service. As a Nomad cluster operator on the Nomad team, because you are empowered with agency and visibility, you get to think of creative solutions to the problem of self-service. The billing team? They're doing that too. And your two teams may collaborate. But the onus is on you to be creative and work within your skillset to best deliver.

Maybe you decide to go sit with the billing team for a week to understand the provisioning flow from the moment a customer presses pay to the automatic creation of a new Nomad cluster. Because you are empowered, you act. You're happier because you don't have to go through seven layers of command to be effective.

Does that help?

[–] [email protected] 2 points 11 months ago

Ah yes, I understand exactly and that's actually how the company I'm working for today is operating. I guess I just didn't understand the word holistic, but yeah, we have a platform team (using nomad) and we want developers to be able to use nomad to run their own stuff, have their own test environments, and be able to do anything they want without us being in the middle.

[–] [email protected] 1 points 11 months ago* (last edited 11 months ago)

I agree that complexity is the problem and I’m avoiding Kubernetes like the plague. I set up a nomad cluster in a few days and it just works, has service discovery, and is perfectly simple to understand.

I think Kubernetes gets a bad rap out of ignorance. You can make it as complex as you want, but you can also keep things trivial and simple if that's what your aiming for.

Case in point, I operate a Kubernetes cluster with microk8s. I got my nodes up and running in a one-time setup, and after this all I need to do is kubectl apply -k to get my apps deployed and running. Each konfiguration script is trivial too. ingress, services, deployments. That's it. A docker compose script is far more complex and hard to maintain than that. Where's the complexity?

Honestly, have you ever gave kubernetes a try? If you did, what exactly did you tried to do? I bet that if you do an honest apples-to-apples comparison with any setup that you believe works, you'll notice that you're doing far more work to achieve the same result. This is a given as you're pointing out nomad of all things as something simple.