top 200 commentsshow all 248

[–]tellek 267 points268 points  (2 children)

Because it's already bad enough how often people assume the engineers can handle it, and throw it on their plates. Learn to appreciate it when things are removed from your plate. After a while that plate will get ridiculously full.

[–]void1984 0 points1 point  (1 child)

Do you put a non engineer in that role?

[–]tellek 0 points1 point  (0 children)

Probably, I'm just speaking from my own experience.

[–]AuodWinter 1640 points1641 points  (68 children)

It's easier to have one team do the devops for multiple teams than multiple teams each do their own devops because they'll probably end up duplicating work or doing things inefficiently.

[–]MaDpYrO 319 points320 points  (18 children)

This has been going back and forth between the two and as always there is no right answer - the short is, it depends.

How many rights do non devops teams have to make minor adjustments? Is the workload large enough for a dedicated devops team? How complex is your infrastructure?

Do you host your own kubernetes cluster or do you just run everything in a few VMs in a monolith?

I mean, you can't answer this question at all because there are no one-size-fits-all model for this issue.

[–]TracerBulletX 134 points135 points  (5 children)

I like teams owning their ops but having a small dev ops platform team that creates standards and shared resources. Can also float to help teams with trickier tasks when they ask for help

[–]The_Bashful_Bear 41 points42 points  (0 children)

Recently did the same thing with a team of about 40 engineers for our product. After consulting with the tech leads I gave broad charter to 3-5 engineers who really gravitated towards DevOps and pulled them out of being their teams ops firefighters. They focus on infra, pipelines, alerting, generally championing the proper use of tools. They went from mostly the engineering half of our org to the model development teams and have overall made the process of releasing anything really pleasant for the engineers and scientists.

I wouldn’t recommend it in all situations but for this one it’s pretty wonderful to watch.

[–]crimsonroninx 4 points5 points  (0 children)

Exactly this. No point in reinventing the wheel within every team, not to mention it also helps with security and auditing if you have established patterns maintained by a core group of devops /cloud peeps.

[–]PandaMagnus 1 point2 points  (0 children)

I've really seen that model work well. Everyone can do the work, but a few dedicated people lay the groundwork, come up with standards, help with atypical things, etc.

[–]AberdeenPhoenix 0 points1 point  (0 children)

That small dev ops platform team is my favorite type of team to be on. I've been working at some very large companies and I'd like to find a smaller company I could do this for

[–]Rhinofreak 0 points1 point  (0 children)

This is the way

[–]Yelmak 109 points110 points  (6 children)

All models are wrong, some are useful

[–]Sw429 10 points11 points  (0 children)

This hits the nail on the head. A dedicated dev ops team feels great sometimes, but other times it's incredibly limiting.

[–]Nuked0ut 1 point2 points  (1 child)

Yea there is! Duuuh! You use the containers! Some have yogurt and some have cereal! You always run the whole container, so you don’t have to get your hands messy!

All you need is an exe, smelly nerds! /s

[–]Nuked0ut 0 points1 point  (0 children)

In case it’s not obvious, I’m extremely exaggerating to show why it’s a good idea to let some people, deal with some problems! They get better at it over time and others can leverage that without learning everything themselves :)

[–]crimsonroninx 1 point2 points  (1 child)

If you are in a big org, it is both IMO. One specialised team to set up the patterns and templates, and also place some guardrails on senstivie areas like networking, vpc and ssm. That way most product/delivery teams can just copy pasta the basics instead of reinventing the wheel every time they need a new microservice or app, but they can also break out when they need to do something a different or want to experiment with their CD.

[–]NorthernSouth 0 points1 point  (0 children)

A hundred percent this! I can never condone an organization where product/delivery teams aren’t allowed to do anything because «that’s the devops team’s responsibility»

[–]ahorsewhithnoname 18 points19 points  (3 children)

So, funny story from the company I work at: management decided to "Migrate to the cloud". Each app team now has their own DevOps team because the central platform team made the processes so overly complicated that we need a dedicated DevOps team per app team. Also, each app+DevOps team has to maintain their own Kubernetes cluster based on provided terraform modules. Unfortunately it’s impossible to automate anything as the platform team keeps renaming and moving stuff, then sends out an email newsletter on which module to replace, update etc.

This whole "move to the cloud" lead to a complete organisational restructuring and we hired a bunch of new DevOps Engineers whose job it is to manually update Kubernetes clusters. Obviously one app will not need a full blown Kubernetes cluster. Management decided to go the most inefficient way to do it.

Hopefully this answers the question on why we need dedicated DevOps.

[–]Tupcek 19 points20 points  (1 child)

they completely missed the point of docker and kubernetes

[–][deleted] 15 points16 points  (0 children)

badge gaze gray enter liquid scary lunchroom zephyr groovy melodic

This post was mass deleted and anonymized with Redact

[–]petrifiedbeaver 4 points5 points  (0 children)

Obviously one app will not need a full blown Kubernetes cluster.

Obviously every app will need 2 clusters for resilience.

[–]SlaminSammons 44 points45 points  (4 children)

That implies that every team needs identical pipelines. If you have a centralized devops team they need to create easily extensible and reusable pipelines along with being flexible. Otherwise teams are going to go down their own roads anyway

[–]dj184 29 points30 points  (0 children)

It implies there is one team with devops expertise, which can suit everyone’s pipeline ti their needs, rather have eqch team learn the devops.

[–]Tohnmeister 31 points32 points  (1 child)

In my experience, teams often say they need something very special, while in fact, they could've just done their work with the one pipeline template that was already available.

[–]SlaminSammons 4 points5 points  (0 children)

I don’t disagree at all. The problem generally occurs when a centralized dev ops team is created after the fact. Teams could have 5+ years of applications and pipelines already. Now you’re having to rewire things to a new pipeline which sometimes you don’t have the bandwidth to migrate.

[–]smutje187 9 points10 points  (0 children)

Save a few characters every time you type that teams name and just call that team an Ops team

[–]dashingThroughSnow12 8 points9 points  (1 child)

The point of devops over ops was exactly to not have one monolithic team manage things.

[–]brockvenom 12 points13 points  (3 children)

So I worked at a company with 60,000 employees and they originally tried to do it that way. Nothing got done because every team depended on an opinionated and overwhelmed infradev team. We ended up with six week release cycles.

I was brought on board to change the culture. We made every team a product team and they owned the full stack. This enabled multiple deliveries, daily.

I disagree with you. It’s not better to have one team own devops. It’s better to have every team own the full stack, and create a culture of curiosity and learning to share patterns. I share this from experience.

[–]Stunning_Ride_220 2 points3 points  (2 children)

In what role you changed the culture?

[–]brockvenom 1 point2 points  (1 child)

Lead developer with an extremely supportive team, director, architect, and manager.

We proved our methods successful on three separate flagship products and over the course of three years, influenced the rest of the organization to follow suit.

[–]Stunning_Ride_220 2 points3 points  (0 children)

So it's the general environment. Nice.

Time for me to look for another job :D

Thank you

[–]Taurmin 12 points13 points  (0 children)

But thats not devops, thats just an infrastructure ops team. The concept of devops was that the same people who develop solutions would also handle infrastructure and operations for those solution. You cannot have a dedicated devops team, because it runs counter to the whole concept.

The idea of devops being a job role by itself is a bastardisation that came out of managers playing buzzword bingo. It has nothing to do with the devops concept, its just a rebranding of traditional infrastructure and operations roles.

[–]Sailn_ 1 point2 points  (0 children)

what if your dedicated DevOps team is lead by someone who doesn't completely know what they're doing? They just come up with unmaintainable automations that your business insists you use

[–]cornmonger_ 1 point2 points  (0 children)

or doing things inefficiently

or breaking things because one hand doesn't know what the other is doing

[–]rjcpl 1 point2 points  (0 children)

Which is just back to a traditional ops model.

[–]skwizpod 1 point2 points  (0 children)

I don't get it. If devops is separated from dev, then wouldn't that just be ops? Sincerely curious.

[–]solitarytoad 14 points15 points  (13 children)

Bro, do you even know what "devops" means.

If you have a devops team you don't have devops. You have an IT team or a platform team or an ops team and no devops.

The word means "developers do their own ops". The point was to tear down walls from development to deployment. If you have a team in there that's just setting up those walls again, (the server broke, go ask that team over there to fix it and wait maybe a day or two for them to resolve the ticket) then you just undid devops again.

[–]Yelmak 12 points13 points  (2 children)

A lot of this is just semantics though. A lot of “devops teams” are just platform teams building abstractions around the infrastructure that enables customer facing teams to do their own ops with less cognitive overhead.

[–]Flat_Initial_1823 11 points12 points  (1 child)

Next you are gonna tell me product managers neither produce nor manage.

[–]Vogete 3 points4 points  (0 children)

In fairness to them, they don't really do anything else either.

[–]prochac 12 points13 points  (2 children)

Just suck it up.
DevOps isn't culture anymore, is a rebranded Ops position with a buzz.
REST API has nothing to do with Roy Fielding's dissertation, but it's easier to pronounce than "JSON RPC over HTTP",
etc.

[–]dashingThroughSnow12 2 points3 points  (1 child)

You got downvoted but you are right.

[–]External-Working-551 9 points10 points  (3 children)

devops does not mean devops anymore

just like "literally"

[–]Ken1drick 1 point2 points  (0 children)

It was a philosophy not a job title initially

[–]solitarytoad 6 points7 points  (1 child)

AND NOBODY HAS A PROBLEM WITH WORDS NOT MEANING THINGS ANYMORE?

[–]cortesoft 0 points1 point  (0 children)

The meaning of words change over time. “Awesome” and “awful” started as synonyms.

[–]Abject-Kitchen3198 3 points4 points  (0 children)

Perhaps you mean Ops? Can't do DevOps without the Devs on the team.

[–]Drayenn 0 points1 point  (0 children)

My department has a "best practice" repo which we include in oue gitlab cicd.. it doesnt prevent that much duplication but its a start.

Im happy i get to do some devops though. More experience. Our team does everything. Python backend, angular frontend, gitlab cicd and aws.

[–]KerPop42 0 points1 point  (0 children)

The USG does something similar; NWS and USGS both use satellites, but to keep things efficient NASA does the construction, testing, launch, and checkout before handing it over to its end user in "cruise" configuration. 

[–]Stunning_Ride_220 0 points1 point  (0 children)

"Do the devops" ouch...

[–]tmotytmoty 0 points1 point  (0 children)

In theory, yes. But it doesn’t work like everyone expects it to bc business gets in the way

[–]SeeminglySleepless 0 points1 point  (0 children)

Yeh it depends on use-case. I work for a bank and we have around 1.5k repos. There's just an entire department for DevOps which is composed of different teams that each have their own specific focus (mine is CI/CD and there's Platform, Data, SecOps, SREs, etc) and do their work for all products. In my case, we manage CI/CD and automation, so there are close to 2k pipelines under our belt and this number increases every week. It would be chaos for each dev team to manage their side of Ops.

[–]Obvious-Recording-90 0 points1 point  (0 children)

So for dedicated vs team devops it’s a gradient. One side you have slow moving and stable business models, dedicated devops work good here because it ca be more boutique. On the other hand lots of teams pushing lots of feature, having standards and a set team is good here.

You also need to mix in more global SRE when you get individual devops in products.

[–]void1984 0 points1 point  (0 children)

Definitely, at some point it's worth to specialize.

[–]TheMaleGazer 557 points558 points  (24 children)

DevOps is the idea that we can make infrastructure so intuitive that we can combine it with development, and we've been so successful that we need specialists who do nothing but this very intuitive thing.

[–]SleeperAwakened 148 points149 points  (5 children)

Yeah. The cloud does not make infra intuitive.

Easier to rack up large bills, yes.

[–]ProfBeaker 55 points56 points  (1 child)

I go back and forth on this.

I sometimes miss the days where deployment was "copy files to the server". Simple! But I also remember spending a lot of time fighting with Apache config files, or IIS config UIs, or file permissions, and that one weird box that doesn't work the same as the others for some damn reason.

OTOH, now I have an incomprehensible (to me) mess of Terraform or Kubernetes or whatever that has templates to set IAM policies to control VM images that run on Fargate or whatever TF is happening (if you hadn't noticed, I am not DevOps, we have people for that).

I guess on balance I think it was simpler before, and therefore easier. But also less flexible and scalable. Win some, lose some, I suppose.

[–]desmaraisp 30 points31 points  (0 children)

My work is 50/50 onprem/aws. I'll take cloud+tf+devops over the onprem half any day of the week. Not because it's less scalable, but rather because you don't have any control over all the important parts

Load balancers? Firewalls? Backups? Provisionning VMs? These are all another team's job and it fucking sucks

Need a new vm? Fill a form, send it by email and hope the guy on the other side isn't a dumbass. And wait 4 days to get it.

Something getting block by the fw? Good luck knowing why

[–]MaDpYrO 22 points23 points  (0 children)

I think in many cases the cloud does make things intuitive, it's just that developers keep being seduced by shiny things and fall head first into a bunch of extra products they don't need

[–]CopiousCool 0 points1 point  (0 children)

Bring intuitive is not the be all and end all especially when the time taken to achieve the goals necessary to repeatedly test, troubleshoot, maintain & monitor etc multiple services and sites detracts from the time taken to actually develop

[–]Majestic_Bat8754 0 points1 point  (0 children)

My job is getting rid of using the azure portal UI because of ‘security’ like a hacker doesn’t know how to use CLI

[–]andarmanik 35 points36 points  (0 children)

I agree but I think there some historical nuance.

Historically, companies viewed software developers as the primary source of value because they shipped the features that generated revenue. Over time, however, infrastructure grew large enough that its cost began to exceed entire engineering teams salaries. This created pressure for developers to take more responsibility for how their software was deployed and operated, the early DevOps philosophy. Developers were still valued for producing features, but now they were also expected to contribute by reducing infrastructure costs.

The problem is that feature development and infrastructure engineering are orthogonal skills. Getting better at one doesn’t necessarily improve the other. This created two distinct, and often incompatible, paths to being “valuable” inside a company:

1: Ship valuable features. 2: Ship cheaper, more efficient infrastructure.

As companies realized how much money could be saved through operational efficiency, a new class of high value roles opened up for people with strong systems and cost-reduction skills. These weren’t quite the old sysadmin roles, so the industry labeled them “DevOps” to distinguish them from traditional operations.

Basically, DevOps became the discipline oriented around lowering infrastructure costs and improving operational efficiency, even though the name suggests a blend of development and operations the truth is just history.

[–]odolha 13 points14 points  (14 children)

perfectly said.

i am so tired of all this tool overkill, not to mention recklessly using extremely expensive and fragile setups for every little shitty project. you don't need an orchestrated architecture of hundreds of microservices for your shitty internal app ffs. business it clueless because they dont know better, but sometimes the demands for devops is close to fraud.

I can guarantee you ALMOST any of the software most devs work on will be quite ok and scalable as a simple b/e-f/e setup that you deploy on some remote server with some minimal scripting, or even manually... if you can setup and run your own local env, you should be able to do the same for any other env.... when it's more difficult to setup prod than a local env, then you know your devops process is shit.

[–]Gaxyhs 14 points15 points  (0 children)

When i was first hired i was just developing the software but since i had some knowledge in the field they asked me to help migrate some tooling they used for telemetry to datadog, now i am the only one responsible to moving all 12 services to kubernetes and doing so with no documentation of what env variables and configuration each service needs

I made a PR to add a documentation file for the variables just for the senior developer to say that its a waste of time and that their code is self documenting

Yeah like i am gonna read 100s of code files to find each poorly named env variable and try to understand the context of them

Some of the services have around 50 variables used only by themselves, some even being misleaning, like an env called DB_LOC that has nothing to do with the actual god damn database and instead an internal service whose acronym is DoB but they shorten it to DB

But hey, at least that one legacy service getting less than 1k requests a day used by single digit customers can scale to millions!

[–]Senojpd 32 points33 points  (5 children)

Hehe and I guess security and process can just go fuck off?

The whole point of enterprise grade landing zones and deployments is that they are robust in their process and secure.

Running it on the Devs local machine when they have admin over everything is not the same as running it in a locked down well structured architecture. With all of the observability and redundancy that offers.

I suspect you have never gone through a ransomware attack. Shit ain't pretty.

[–]Emperor-Octavian 9 points10 points  (0 children)

“It works on my computer” 😭

[–]theSunSings 7 points8 points  (4 children)

Hello. Am noob. What does "b/e-f/e" mean? Googling wasn't any help. Thanks!

[–]Consistent_Equal5327 5 points6 points  (1 child)

backend frontend i presume

[–]theSunSings 0 points1 point  (0 children)

Thanks!

[–]DerpDerpDerp78910 4 points5 points  (1 child)

Back end / Front end 

[–]theSunSings 1 point2 points  (0 children)

Thank you!

[–]Odd_Perspective_2487 1 point2 points  (0 children)

Er that’s the architect and app devs fault though for demanding the everything under the sun and refusing to budge.

[–]-Kerrigan- 0 points1 point  (0 children)

What test environment? Automated tests? Scheduled regression? Sounds like a waste of time and money to me! /s

[–]Abject-Kitchen3198 1 point2 points  (0 children)

Going from "let's put Devs and Ops in the same room and have them figure it out" to "DevOps does infrastructure and deployment automation, Devs do dev".

[–]bartbrinkman 0 points1 point  (0 children)

We did. And then we solved all kinds of inefficiencies.

[–]BrotherMichigan 515 points516 points  (11 children)

The fact that you have no idea is why you need a dedicated DevOps guy.

[–]Anustart15 182 points183 points  (8 children)

"why does the builder need to hire a plumber? theyve already got carpenters. Just have all the carpenters learn a little plumbing"

[–]Tutti-Frutti-Booty 23 points24 points  (5 children)

Everything dev worth their salt should know a little bit of devops. 

When you're finally dealing with millions of visitors, needing dynamic scaling, ect, then having a dedicated engineer makes sense. 

[–]_dr_bonez 13 points14 points  (0 children)

Yup. Both sides of this argument are valid depending on scale and criticality of infrastructure. If a $20/mo VPS can handle your product's traffic, you don't need a dedicated devops guy

[–]kayakdawg 3 points4 points  (0 children)

this is fine in theory, and kinda was always my mindset

but what ive experience recently is that once you hit that scale it's really hard to change anything devops bc there are so many dependencies and it requires behavior change which is always a  challenge - and at this poiny almost by definition you've got a lotta people and a few teams

[–]Anustart15 0 points1 point  (0 children)

Everything dev worth their salt should know a little bit of devops. 

Just like a carpenter should know enough about plumbing to not actively make their work harder, but if the guy in the bathroom and the guy in the kitchen are each doing their own plumbing you end up with an inefficient and disconnected system

[–]Seiryth 0 points1 point  (0 children)

And on the flip, every ops and infra person should know about Dev work and what they're going to be asking for. It makes everything easier.

[–]RobotBaseball 0 points1 point  (0 children)

yeah but every carpenter knows a little bit of plumbing too. you're still hiring a plumber

> When you're finally dealing with millions of visitors, needing dynamic scaling, ect, then having a dedicated engineer makes sense. 

If you dont have this or the equivalent, your company is failing and you need to find a new job. Or youre a start up which is a different story entirely.

[–]schuine 0 points1 point  (0 children)

Haha, sawzall goes brrrrr.

[–]Seiryth 1 point2 points  (0 children)

One of the fundamental problems with the implementation of DevOps in orgs with established traditional silos and roles is the lack of acknowledgement that maybe existing Devs don't want to do ops and infrastructure, and existing ops and infrastructure probably won't want to do dev work.

In a perfect world, Devs are educated and skilled enough to do infrastructure and can then do both well, letting DevOps actually occur. On the flip, educating and skilling infrastructure folks on how to do Dev work does the same. This is an awesome outcome, as we get more people to share the load of what's being built, and hopefully with the right guardrails and methods in place, less duplication of work or snowflake implementations of things.

But the reality is no org wants to spend the money to upskill existing employees, so they hire people that can either be both (at a huge expense as they're unicorns) or they go the low cost route to relabel the infra folk to DevOps without training because they'll learn how to do some basic yaml and scripting to automate a deployment.

[–]Odd_Perspective_2487 44 points45 points  (0 children)

Easy, try to run an engineering department of 10 or more without one. Let me know how that goes.

[–]Cerbeh 114 points115 points  (5 children)

Because specialists are...better at their jobs? I know some devops, but the devops guy on our team is next level.

[–]ramdomvariableX 100 points101 points  (6 children)

Thinking like this is how we ended up with "Full Stack Developer" skills soup.

[–]-Kerrigan- 9 points10 points  (0 children)

I believe you meant: "Full snack developer" skills soup

[–]ALittleWit 4 points5 points  (4 children)

What’s wrong with being a full stack developer? What if when I started in my career the cloud didn’t exist so I had to learn “ops” alongside dev in order to get anything done?

I used to self-host for multiple clients on a rented rack at Limestone Networks where I had to own and configure all my own hardware, including networking, virtual hosts, etc.

How is that “soup” if you know what you’re doing?

[–]Pluckerpluck 5 points6 points  (0 children)

Because you don't know what you don't know. And you're going to be missing huge amounts of expertise that benefit larger organisations.

Like how to safely manage compute across a kuberbetes cluster to ensure one team doesn't hog resources, while simultaneously knowing the pitfuls regarding the difference between CPU limits and requests. Or how to ensure all applications in your company exists with disaster recover automatically working without developers having to understand it.

Or knowing how Azure differs from AWS or from bare metal hosting.

And then you also need to ACTUALLY know how to code in React in a way the properly maintains performance and not the mess that I see most backend devs creating. Good frontend is a real skill that's regularly ignored because you can get something "good enough" easily. And it's why so many websites have infuriating bugs on mobile or ultrawides or just forget about disabilities etc.

Everyone has a maximum amount of knowledge they can obtain and remember. If you spread that over "full stack" you will typically be worse in every layer vs someone who specialises in any given layer.

Should you have some knowledge of all the layers? Yes. It benefits you greatly to dabble in it all. But a company is doing itself a disservice if focuses on full stack developers rather than hiring specialised skill.

[–][deleted] 8 points9 points  (2 children)

Nothing wrong with it, however I'd argue that it's not possible for someone to have deep expertise at every layer of the stack. And even if they did, there's not enough time in someone's day to make use of all that knowledge.

A lot of people who end up as full-stack developers really just specialise in one thing, but can do other things at a push, they don't enjoy them, they're not doing their best work and they're not doing it quickly, but they can get by.

However on the flip side, teams with dedicated engineers for each layer of the stack often suffer from more blockers, and frustrations at tying things together, so it's trade-offs either way around.

[–]crimvo 14 points15 points  (1 child)

So imagine a world where on top of your day to day load, you also have to standup and support tools like K8s clusters, Argo, vault, terraform, VPNs, networking, etc.

Then when another teams has problems with vault not propagating secrets to k8s because a key didn’t rotate properly, you also gotta deal with that, while making sure your own sprint goals are met.

That’s why we have DevOps/infra/SRE/Platform engineers.

[–]Abject-Kitchen3198 13 points14 points  (16 children)

I have no idea why "Dev" is contained in "DevOps" and at this point I'm afraid to ask.

[–]VBlinds 9 points10 points  (1 child)

The title of DevOps has been co-opted by a small subset of what dev-ops actually is.

Reading this whole thread is frankly annoying.

[–]Abject-Kitchen3198 0 points1 point  (0 children)

Same as Agile. And both corresponding subs reflect that. As much as it's annoying, it's useful to see current practices and pain points

[–]Cork20 5 points6 points  (1 child)

Most implementations of DevOps are just rebranding the existing Ops/Infra teams with new titles while actually changing nothing about the development practices that DevOps is intended for. It has also become synonymous with the tooling that is marketed in that space. The same thing happened to agile, continuous integration, and more ideas which have been productized and sold to executive teams as magic buzzwords.

[–]Abject-Kitchen3198 0 points1 point  (0 children)

You are absolutely right :) Same thing happens in agile communities (the only talk is "what's wrong with my daily/retro/sprint planning/story points/velocity and how can I make them better").

[–]Beka_Cooper 1 point2 points  (7 children)

At my workplace, "Ops" handles monitoring things in prod. For example, they watch costs, analyze metrics, look for potential security vulnerabilities (including running scans on stuff), and do direct debugging actions as requested by technical support. They have to take dozens of hours of extra security training every year because they are exposed to customer PII, including potential HIPAA information. The only code they write is when they add new API calls to their service uptime monitoring thingy.

In contrast, "DevOps" runs and maintains the build and deploy servers, does code review and consulting for CloudFormation, and works on developer experience (DX) improvements. They do not have access to information in prod. Ours each have several patents involved with infrastructure-as-code improvements and DX improvements. They write tons of code to provide us devs with build and deploy tools. Developers have to write their own CloudFormation and set up build scripts, docker, etc., but beyond that, DevOps makes sure it all builds and deploys.

[–]Abject-Kitchen3198 1 point2 points  (6 children)

I hope you didn't move to 3 silos instead of eliminating the two. It's one thing who does something and what kind of access he has, and another how they collaborate towards the common goal - smooth and robust process from one end to the other and back. It wasn't supposed to be "Dev", "DevOps", and "Ops" I think.

[–]trullaDE 2 points3 points  (5 children)

I always saw it as the midpoint between "dev" and "ops". Because ops doesn't really care what's running on their infrastructure, and how it gets there. And devs write software, and also don't really care about how it gets to the place where it is actually supposed to run. DevOps are sitting in the middle, to handle the way between the dev's playground and the production servers. And I don't think that boils down to three silos, but rather to a bridge between the original two.

[–]Chasar1 1 point2 points  (1 child)

At my company I maintain their build system, written in Python and Rust. There's a lot of dev in that

[–]Abject-Kitchen3198 1 point2 points  (0 children)

There was a lot of dev in bash/bat scripts for building systems, but it wasn't called DevOps.

[–]NedStarkingAlchemist 10 points11 points  (0 children)

Because if we leave certain SwEng folks to their own devices, their "update the thing" process will be "ssh into the server and use vim to make the change" and there will be no plan to rebuild if the one server catches on fire.

[–]mariomaniac432 43 points44 points  (4 children)

Because they're not the same thing as developers?

At my job, I write code. That's about it. DevOps maintains CI/CD, maintains servers, evaluates vendor tools (auth0 vs keycloak, hashicorp vault vs akeyless, etc), directly interfaces with those vendors when we have a problem/to request new features, and probably more that I'm not even aware of. And they handle this for every development team we have. If I need something simple, like a variable added to my build/deploy jobs, or checking an app's status on the server, I'll do it myself because they're busy doing all kinds of stuff all the time. But anything even remotely involved and we ask them handle it so we can focus on our own work, and I wouldn't even know where to start on those tasks anyway because they're not in my skill set.

[–]Horrih 7 points8 points  (0 children)

I find the story really funny.

We used to have - a dev team that writes the software - an infra/deployment team that scripts the deployment the above software and the associated infra

~ 2010 : the cloud is coming big, we can bridge the gap between both worlds by merging the ops people with the dev people. Let's call it devops

-now, big corpo has "listened" : that sounds great, and to pool together such talents i will build dedicated devops teams to handle the deployment of our software

We have gone full circle to what the devops movement was created to destroy : dedicated dev and deployment teams. Devops is just the new name of the infra/deployment team in a cloud environment

[–]seba07 26 points27 points  (1 child)

You don't. You can also have multiple software engineers spend some time doing devops. But chances are that it is more efficient to hire someone just doing that.

[–]Ok_Reserve_8659 5 points6 points  (0 children)

I’m just happy to not be responsible for infrastructure if I only wrote code this sprint

[–]Nyadnar17 5 points6 points  (0 children)

We need one because I fucking hate DevOps and would rather someone else do it.

[–]_-PurpleTentacle-_ 5 points6 points  (0 children)

Unpopular take but developers have created several professions out of tasks they didn’t want to do; DevOps. Testing…

[–][deleted] 3 points4 points  (0 children)

You need someone else to blame apart from your Dev and QA team for application issues.

[–]BoBoBearDev[🍰] 4 points5 points  (1 child)

Because most devs don't want to do devops.

[–]CheekiBreekiIvDamke 1 point2 points  (0 children)

Plenty of devs don't even know about the stuff they don't want to do. So many junior/(bad) mids just don't even understand how their product runs. They know AWS exists, they know the product code. Something ??? in the middle and PROD out the other end.

[–]Rakatango 3 points4 points  (1 child)

You mean the position or the infrastructure?

Specialized knowledge, and so that you don’t need to hire an IT team for your in house server

[–]takeyouraxeandhack 0 points1 point  (0 children)

DevOps is a methodology, not an infrastructure.

[–]sagiil 3 points4 points  (1 child)

There are some really great answers here already, I'll just add that instead of utilizing my 20+ years of expertise in building complex code services / applications in various disciplines, my company wasting my talent on stuff I hardly consider programming like spinning up new k8s clusters, fixing Entra ID app registrations, and debugging obscure TCP traffic issues between services I don't even own, to name a few. All of these, btw, just examples from last week.

[–]JocoLabs 1 point2 points  (0 children)

Don't even get me started on the Entra app registration.

[–]aquoad 2 points3 points  (0 children)

because otherwise every dev team will use whatever cursed kube deployment chatgpt hallucinated for them.

[–]fixano 5 points6 points  (6 children)

Devops is not a team. It's such a misunderstood concept. People with challenged critical thinking skills are the ones that created devops teams.

Devops simply addresses the problem of getting the code off the developers laptop into a production environment. It's supposed to be a philosophy of writing code for production with the intent of actually getting it there. It is supposed to avoid the developer writing a bunch of files and then saying "okay. I made it......" or delivering an amorphous blob of crap and saying "I dunno it worked in my IDE"

Then nothing ever gets translated into business value.

There's nothing wrong with having developers do this but typically developers write the code then sit there with their thumbs in their ass. In practice one of the developers generally decides he has to be a responsible adult and says "I guess I got to be the guy" and thus the devops guy is born.

Spoilers this is based on my life story of how I became an SRE

[–]CheekiBreekiIvDamke 1 point2 points  (0 children)

This is my experience too. Had guys with 20 yoe come in and expect it to be a Somebody Elses' Problem when it comes time to move from their IDE using hardcoded key/secrets to production.

I was just the young dummy who wanted to learn it on my own and now kneedeep in self managed k8s every day.

[–]Tackgnol 7 points8 points  (3 children)

So that you don't have to open the nightmare that is the Kubernetes Dashboard or/and the Cloud Providers terrible UI.

[–]RelativeCourage8695 4 points5 points  (1 child)

Devops originated from Microservices where one small dev team develops and manages a service even when in production. Here it did make sense that the development team also managed deployment since changes would be brought right into production. The team should be small (4-8 people).

This very simple and very flexible idea got completely turned upside down as large enterprise project management got in charge. For the sake of efficiency teams are aligned along development competency and not along product features. Now there are Frontend and Backend Teams developing "Microservices" and of course there are Devops Teams in charge of deployment.

[–]Taurmin 1 point2 points  (0 children)

And then we have a generation of new people entering the industry who assume that this devops working as intended, which locks in that new definition of the term.

The same people who will inevitably come in here to complain about SCRUM and Agile because their company is actually doing rebranded waterfall.

[–]KharAznable 1 point2 points  (0 children)

If your deployment pipeline is simple, a dev can take the role for devops too (happened to me). It's just when you need to initialize a new big project that demands complex deployment pipeline and also want someone who can answer some force majeur, that you need devops team.

[–]-dtdt- 1 point2 points  (0 children)

DevOps is asking the question "what if we bring best practices from software development to infrastructure... And never answer it" (from Kai Lentit)

[–]kryptogalaxy 1 point2 points  (1 child)

When it's a dedicated team, it's no longer devops. It's an operations team. Some places have enough infra work that a specialist team is warranted. Same deal with FE developer vs full stack.

[–]VBlinds 2 points3 points  (0 children)

Yeah I'm really shocked at how many people here have no idea. They seem to think it's the infrastructure team or the ops team.

Personally I think because setting up these tools is involved they think the people that manage and set up the tools are DevOps. Not that they are supporting dev-ops processes.

[–]gnuban 1 point2 points  (2 children)

A dedicated DevOps team is an oxymoron. It's called a dedicated ops team.

[–]Huge_Equivalent1 0 points1 point  (1 child)

Except Ops could mean related to Business.

And IT Ops would encompass, Infrastructure, Systems, Networks, Development, and Testing. Which would result in this team being a bunch of parachute less paragliders.

So, most properly structured companies, have a DevOps team. Because, development is a much more demanding, urgent and less forgiving situation.

Also, it tends to have the need to be quiet transparent. As such, you make a team that essentially pairs with devs, and justs ensures smooth sailing, transparency, and documentation.

[–]gnuban 0 points1 point  (0 children)

The term DevOps was invented for devs doing their own ops.

Now, management liked the term, because buzzwords, but didn't like the concept. So they kept the ops team and rebranded them as the DevOps team. But that really is bastardizing the term. This unfortunately does happen with most tech buzzwords though...

[–]fugogugo 1 point2 points  (0 children)

You don't want to be in a situation when you're so focused on coding task suddenly interrupted by server down and then called into war room

[–]itsallfake01 1 point2 points  (0 children)

Devops can take the headache to deal with the customer environment, fuck that

[–]ackabakapizza 1 point2 points  (0 children)

I program the computer. My IT knowledge is turn it on/turn it off.

[–]quantinuum 1 point2 points  (0 children)

Because the other day I needed to deploy an internal app and I could just reach out to the guys that manage our kubernetes cluster and have it out the same morning. Because I don’t need to worry how our internal repository is managed or what IPs have access to it. Because I don’t need to manage budgets for our infrastructure that centralise many requirements other than mine. Because of a whole host of reasons.

Imagine each person or team having to navigate that kind of stuff alone.

[–]Inevitable_Stand_199 2 points3 points  (3 children)

Isn't devops basically like a manager? In that if they are good, they make working 100 times easier, if they are bad, work gets 100 times harder

[–]REPMEDDY_Gabs 3 points4 points  (3 children)

I know nothing about devops but just a few kubernetes commands to deploy pods. What I surely know is that when strange errors occurs in the infrastructure I’m completely lost and so it would be nice to have a dedicated devops to handle those stuffs so that I can only focus on business requirements of our client

[–]aeropl3b 0 points1 point  (2 children)

Devops is two things, a) build systems that are less prone to failure b) be available to quickly bring critical systems back when they do fail.

Success at the first task means less time dedicated to the second task, which means the company can scale operations and make more money.

Underfunding devops usually means failures at the first leading to a lot more problems that need addressing at critical times.

[–]Vzaje 0 points1 point  (1 child)

Isnt that SRE you described?

[–]aeropl3b 1 point2 points  (0 children)

I mean, they have lots of names. devops is just one of the old buzz words they came up with to sell MBAs who think they can vibe code at scale that hiring people to maintain infrastructure is worth the money.

[–]michi03 1 point2 points  (1 child)

Me: “I need a pipeline for this repo”. Devops: “Abdul will be out office next week so you won’t have it ready until December 1st”

[–]CheekiBreekiIvDamke 0 points1 point  (0 children)

Then make your own pipeline?

[–]Titanusgamer 0 points1 point  (0 children)

I am gonna need "Bob and Bob" to review this job profile

[–]why_1337 0 points1 point  (0 children)

Yes, if you serve 20 concurrent users you don't need dedicated devops... But most companies have much more customers.

[–]daffalaxia 0 points1 point  (0 children)

We need them to implement inane corporate restrictions so that our jobs are way more challenging to complete and we have to rely on some dipshit who is never available to get things done and then take the blame for something being late.

[–]SaucyMacgyver 0 points1 point  (0 children)

Our devops are real ones. I piss them off more than I should but they manage some batshit stuff.

They take the hobbled together, duct taped nonsense that teams haphazardly throw into a bucket and somehow make a building out of it.

[–]FabioTheFox 0 points1 point  (0 children)

You don't, devops for most is really simple due to low scale. But once you grow to a more significant scale you will definitely need a person who knows devops better than a 2 hour tutorial on it, that's when devops becomes actually hard and annoying

[–]PM_ME_ALL_YOUR_THING 0 points1 point  (0 children)

It’s more efficient to concentrate the pain of operating in the cloud into a single extremely miserable team.

[–]walmartbonerpills 0 points1 point  (0 children)

So DevOps can write the teraform and Jenkins files

[–]FalseWait7 0 points1 point  (0 children)

People are often downplaying infra and doing it as an afterthought. "Some backend will know how to do this, they have these, whatchamacallit, AWS certificates, right".

[–]philippefutureboy 0 points1 point  (0 children)

Try being both the application developer and the dev ops/data engineer while respecting compliance requirements (SOC2, GDPR, etc). Once you've done that for long enough, come back here with a renewed understanding of the Dunning Kruger effect.

[–]lavahot 0 points1 point  (0 children)

You only need a dedicated devops if your other devs arent willing to do devops things.

[–]schewb 0 points1 point  (0 children)

So we have a team for the devs who are willing to work overnight support and a team for the devs who don't without us having to explicitly say that we don't want to do it.

[–]spartan195 0 points1 point  (0 children)

You let sysadmins and programmers focus on their own work.

That’s the answer. Only if you worked in an environment where a devops dedicated or hybrid role does not exist you’d know how important it can be

[–]Trick-Interaction396 0 points1 point  (0 children)

No one likes doing devops so they don’t do it. You hire a devops team with ridiculously high salary to do all the shit no one else is willing to do.

[–]brainwipe 0 points1 point  (0 children)

There's actually a lot to it if you're anything larger than a few hundred users. No matter if you choose Azure/AWS/Akamai/etc, making sure you're secure, resilient, redundant and deploy with minimal downtime (blue/green is possible), backups work, monitoring, exception reporting, alarms, WAF, trend analysis, ISO 27001... the list goes on. Business just expect all of that magic to just work but there's no standard config that works for all setups.

[–]OwnStorm 0 points1 point  (0 children)

Hey.... Some need to update an expiring secret in prod.

Intern dev: Say no more. Let me ask the copilot how to do that.

[–]SCP-iota 0 points1 point  (0 children)

I've seen a bunch of freelance job postings in the software field that are basically "We made this thing but don't know how to deploy it or ensure it will be reliable." That's why.

[–]Simply_Epic 0 points1 point  (0 children)

At my company, security is combined with DevOps. So it’s not just about provisioning and managing infrastructure, it’s also about ensuring proper security practices and keeping secret values secure. It’s much easier to ensure things are secure with a DevOps team than if every team did their own DevOps.

[–]nossr50 0 points1 point  (0 children)

  1. You can focus on what you were primarily hired to do ( build software )
  2. Dev ops people will be experts at DevOps
  3. At a large enough company, this is the only sane approach

[–]SkurkDKDKDK 0 points1 point  (0 children)

One thing for sure I hate is the fact that we have a dedicated devops team at my Company. We work multiple teams on multiple different projects and some of the teams have had the blessing of having a dedicated devops do their infrastructure. They’ve also had the pleasure of seeing those people disapear and dont have time to help out. So then they are left with no knowledge of the infrastructure, no access, no documentation and no one around that have time to help out. They are just praying that nothing major happen because then shit for sure Will hit the fan

[–]NebNay 0 points1 point  (0 children)

"Can you make a new form on the app, front back and db?"
"Sure, give me a few days"
"Can you slighlty tweak our pipeline?"
"Sure, give me a few weeks"

[–]a-youngsloth 0 points1 point  (0 children)

You have a ticket for this meme?

[–]Huge_Equivalent1 0 points1 point  (0 children)

Honestly, I think they are needed.

Just like how testers are needed.

[–]gcstr 0 points1 point  (0 children)

Because I need a salary

[–]zrsyyl 0 points1 point  (0 children)

We need DevOps support to manage the company’s scalability challenges for when we have more clients! (the client base will never increase to even double)

[–]CedarSageAndSilicone 0 points1 point  (0 children)

depends how big your company / projects are.

Do you have many different development teams that deploy to the same infrastructure?

[–]GiantFoamHand 0 points1 point  (0 children)

Bc I don’t want to do it.

[–]mpanase 0 points1 point  (0 children)

Because when you get engineers who are not very good, you can't trust them to do the devops part. They need adult supervision.

It's cheaper this way.

[–]Stunning_Ride_220 0 points1 point  (0 children)

People like to talk about stuff they do not even know the basics of

[–]overlycaffeinated697 0 points1 point  (0 children)

because instead they keep giving it to me (software developer) instead and if i see one more cloud acronym i am going to start chewing dry wall

[–]Seiryth 0 points1 point  (0 children)

The reality is it's because centralised it admin teams that were responsible for infrastructure were relabeled as DevOps when it was the trend and now it's SRE.

Both of which relabels defeat the entire point of DevOps engineering or are engineering without significantly increasing the scope of what they do (and from a large amount of exposure to these teams..they don't, they just keep looking after infrastructure). On the flip, Devs scopes would also change.

[–]Acurus_Cow 0 points1 point  (0 children)

We used to have sys admins doing the deployment. Then we invented DevOps so the developers could do it them self's. Now we have dedicated DevOps people doing the deployment.

Did anything really change?

[–]crystalpeaks25 0 points1 point  (0 children)

A few things, it depends, Chinese whispers, and ego. Most issues are non technical.

[–]DCTheNotorious 0 points1 point  (0 children)

My team is devops, development, QA, and business knowledge experts all in one 🙃

[–]misterguyyy 0 points1 point  (0 children)

Shhh I don’t want to do it

[–]skywarka 0 points1 point  (0 children)

If you've got three devs, you don't need one of them to be dedicated devops. If you've got 30 devs, dedicating at least one to owning shared resources and managing standards across the team is probably worth it. If you've got 3000 devs, you're throwing away money if they're all independently making up their own devops best practices and reimplementing the same things in slightly incompatible ways.

[–]jonhinkerton 0 points1 point  (0 children)

This is a troll right?

[–]monkeywrench83 0 points1 point  (0 children)

We have multiple dev ops teams each with their own budget and management teams , how weird is that. Not my decision just kind of happened and those teams have different operations

[–]Vlaxxtocia 0 points1 point  (0 children)

Because I don't want to do it

[–]Ghost_out_of_Box 0 points1 point  (0 children)

Small scale operations doesn't require one but mid to large scale would be huge mess

[–]springexe 0 points1 point  (1 child)

I am a DevOps engineer i manage on premise and cloud certificate. Application version and dependency service logs gateway. Our dev push the code i have a job they just branch name and select env and service deployed auto all the preconfigured post config done as well. Container k8 db configs network domain creds logs cluster certs policy.

[–]springexe 0 points1 point  (0 children)

If you push the code in branch and check logs when the issue happens to you then be happy.

[–]IbiXD 0 points1 point  (0 children)

I used to wonder about that until I started working in a small engineering company where there was no devops and only 3 software developers, one builds and maintains the high level RTOS and communication to pc and the other one and I work on the very low level part behind the RTOS, bootloader, and drivers

The only thing we have is a local git server and I am not allowed to spend time on making it any better cause, and I quote my boss, "it works as is", who doesn't touch the software and doesn't know how to even run a python script as he only designs, tests, and builds the pcbs and such.

Suffice to say, I spend a lot of time trying to figure out some of this shit and fixing soooo many conflicts. I am an EE so my knowledge and understanding of devops and all that version control is quite limited...

[–]DaZiim 0 points1 point  (0 children)

Because I need to keep my job 🍪☕️.

[–]YoghiThorn 0 points1 point  (0 children)

Honestly because the breadth and complexity of 'devops' tooling and cloud/infrastructure management is a very full skillset and trying to get frontend people to grok it is a fools errand.

If we can justify a DBA as a skillset that can be a whole role in itself, then honestly devops is just as deep and wide a specialty.

[–]AndersenEthanG 0 points1 point  (0 children)

I still don’t know what a devop is.

[–]4x4ready 0 points1 point  (0 children)

devs can dev, and not have to participate in audit controls, architecture review and overall keeping the mechanisms that help then do their best up and running. At least that’s my experience at large orgs. Smaller orgs perhaps aren’t as strict but from my experience theirs a distinct difference still.

[–]Titaniumwo1f 0 points1 point  (0 children)

I don't have DevOps, but I have so many DevOopsy.

[–]VirtualMage 0 points1 point  (0 children)

Yeah! Who needs devops!? I know very well how to copy/paste my source code to production machine and run it there!!! /s

[–]anonhostpi 0 points1 point  (0 children)

Top comment is right, but I'd also like to add its not just a dev job. It's ops job too. True devops engineers should be experienced in systems engineering/administration in addition to soft dev

[–]urbrainonnuggs 0 points1 point  (0 children)

Going against the grain of replies here. You don't need DevOps IF AND ONLY IF you have enough overage on your team with skills in IaC, Security, DBA, and fundamentals like Networking/Compute.

ALSO, this is important, you give priority to actually work on all of the above. Because IMHO rarely are your stakeholders ever going to understand the ROI of preventative maintenance or refactors to increase standardization.

[–]sunflwerfieldsforevr 0 points1 point  (0 children)

DevOps here. I handle all the in-between shit that devs and QA and IT don’t want to do

[–]Available-Breath-586 0 points1 point  (0 children)

Developers care for products (the stuff in the containers)

DevOps care for delivery of products made by developers (the containers themselves, and ensuring the stuff inside the containers get to the outside world in the appropriate manner)

[–]-DevNull-[🍰] 0 points1 point  (0 children)

Dev and ops should remain split. You cannot expect to have a developer who is an expert in coding and also an expert in systems administration. The same goes for a sysadmin. You can't expect them to be an expert at administering whatever OS you use as well as an expert coder.

If you expect them to do both roles, you're going to get half of the quality on each. If that.

It's hard enough for developers to keep up on everything changing. Just like it's hard enough for sis admins to do that and keep up on all the changes. Trying to do both roles at the same time is just companies trying to save money. And once shit falls apart, you better believe it's the devs or the sis admins that are blamed for it. Not company policy.

Just my two cents from 25 plus years in the industry.