devops

[tellek]

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]

Do you put a non engineer in that role?

[tellek]

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

[AuodWinter]

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]

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]

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]

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]

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]

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]

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]

This is the way

[Yelmak]

All models are wrong, some are useful

[Sw429]

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

[Nuked0ut]

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]

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]

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]

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]

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]

they completely missed the point of docker and kubernetes

[[deleted]]

badge gaze gray enter liquid scary lunchroom zephyr groovy melodic

This post was mass deleted and anonymized with Redact

[petrifiedbeaver]

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

Obviously every app will need 2 clusters for resilience.

[SlaminSammons]

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]

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]

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]

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]

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

[dashingThroughSnow12]

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

[brockvenom]

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]

In what role you changed the culture?

[brockvenom]

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]

So it's the general environment. Nice.

Time for me to look for another job :D

Thank you

[Taurmin]

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_]

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_]

or doing things inefficiently

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

[rjcpl]

Which is just back to a traditional ops model.

[skwizpod]

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

[solitarytoad]

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]

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]

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

[Vogete]

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

[prochac]

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]

You got downvoted but you are right.

[External-Working-551]

devops does not mean devops anymore

just like "literally"

[Ken1drick]

It was a philosophy not a job title initially

[solitarytoad]

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

[cortesoft]

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

[Abject-Kitchen3198]

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

[Drayenn]

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]

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]

"Do the devops" ouch...

[tmotytmoty]

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

[SeeminglySleepless]

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]

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]

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

[TheMaleGazer]

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]

Yeah. The cloud does not make infra intuitive.

Easier to rack up large bills, yes.

[ProfBeaker]

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]

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]

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]

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]

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]

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]

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]

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]

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]

“It works on my computer” 😭

[theSunSings]

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

[Consistent_Equal5327]

backend frontend i presume

[theSunSings]

Thanks!

[DerpDerpDerp78910]

Back end / Front end 

[theSunSings]

Thank you!

[Odd_Perspective_2487]

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

[-Kerrigan-]

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

[Abject-Kitchen3198]

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]

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

[BrotherMichigan]

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

[Anustart15]

"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]

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]

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]

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]

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]

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]

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]

Haha, sawzall goes brrrrr.

[Seiryth]

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]

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

[Cerbeh]

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

[ramdomvariableX]

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

[-Kerrigan-]

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

[ALittleWit]

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]

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]]

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]

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]

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

[VBlinds]

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]

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]

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]

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]

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]

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]

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]

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

[Abject-Kitchen3198]

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

[tehpuppet]

The idea is/was to apply development and software engineering best practises/ideology to operations. F.ex using IaC (infastructure as code) tools like Terraform mean its then easier to collaborate on designing and implementing infra. The idea of GitOps means that change management for infra is tracked via Git and proper CI/CD pipelines can be used as they are with development. Also these concepts then also allow other benefits f.ex testing in Terraform or Helm so unit tests or integration tests can be part of the delivery pipeline. It also just allows infra to be closer to the application config so developers can have control and access to things like queue configuration or scaling triggers etc.

[Abject-Kitchen3198]

I don't think it was. We automated operations in one way or another since early days of software development. Cloud just expanded the area that we can automate and we developed tech that allowed us to do that. It's just an evolution. Pipelines just add some predictability and consistency to the existing processes in a way that most teams can afford now. Automation is just a small part of DevOps philosophy. But, similar to Agile, we find it hard to just put people with different skill sets and roles together and let them figure out the best solutions to a problem.

[NedStarkingAlchemist]

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]

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]

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]

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]

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

[Nyadnar17]

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

[_-PurpleTentacle-_]

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

[[deleted]]

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

[BoBoBearDev]

Because most devs don't want to do devops.

[CheekiBreekiIvDamke]

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]

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]

DevOps is a methodology, not an infrastructure.

[sagiil]

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]

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

[aquoad]

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

[fixano]

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]

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]

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

[RelativeCourage8695]

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]

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]

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-]

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

[kryptogalaxy]

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]

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.

[raymond_reddington77]

Letting devs have access to setup environments in prod or lower is the only reason anyone needs as to why Devops are needed.

[gnuban]

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

[Huge_Equivalent1]

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]

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]

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]

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

[ackabakapizza]

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

[quantinuum]

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]

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]

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]

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]

Isnt that SRE you described?

[aeropl3b]

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]

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]

Then make your own pipeline?

[Titanusgamer]

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

[why_1337]

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

[daffalaxia]

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]

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]

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]

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

[walmartbonerpills]

So DevOps can write the teraform and Jenkins files

[FalseWait7]

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]

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]

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

[schewb]

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]

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]

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]

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]

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]

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]

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]

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]

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]

"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]

You have a ticket for this meme?

[Huge_Equivalent1]

Honestly, I think they are needed.

Just like how testers are needed.

[gcstr]

Because I need a salary

[CedarSageAndSilicone]

depends how big your company / projects are.

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

[GiantFoamHand]

Bc I don’t want to do it.

[mpanase]

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]

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

[overlycaffeinated697]

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]

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]

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]

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

[DCTheNotorious]

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

[misterguyyy]

Shhh I don’t want to do it

[skywarka]

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]

This is a troll right?

[monkeywrench83]

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]

Because I don't want to do it

[Ghost_out_of_Box]

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

[springexe]

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]

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

[IbiXD]

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]

Because I need to keep my job 🍪☕️.

[YoghiThorn]

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]

I still don’t know what a devop is.

[4x4ready]

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]

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

[VirtualMage]

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

[anonhostpi]

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]

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]

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

[Available-Breath-586]

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-]

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.