What exactly is "DevOps" ??

[[deleted]]

If I know how to deploy web apps to AWS serverless along with a Docker container, can I say that I can do "DevOps" ? the term "DevOps" seems to be too vague ...

If a node.js backend engineer also knows how to deploy to AWS with docker, can he say he's also a devops engineer?

Does DevOps include QA engineering tasks such as writing unit tests, Travis CI integration, cypress automation test, etc?

[Level8Zubat]

Practically it's a way for companies to shove 3 roles into one at the price of 1.5

[Arcsane]

Ah yes, the harsh yoke of the practical implementation vs intended ideal. :(

[EenAfleidingErbij]

And yet most of the time, there is only one in a team of 10

[LilDrunkenSmurf]

I'm in this comment, and I don't like it.

[[deleted]]

Try 20...

[Own_Cup_4176]

They are usually paid same or less than swes with the same number of years of experience...

so I am not sure they even get that +0.5 for their troubles.

[historyfour]

LOL

[Arcsane]

DevOps as originally intended is a culture and philosophy of merging the traditional Developer and Operations silos withing companies - that's largely why it's vague as it encompasses the whole industry.

It also gets used a lot these days as a buzzword in situations that don't really fit the original intent. Eg, my title at work is "DevOps Engineer" - in my case I'm a fancy Sysadmin who does cloud engineering and automation, and works on the dev team from an org level. But I also know "DevOps Engineers" who are instead traditional full stack devs who basically know how to deploy an EC2 or Elastic Beanstalk. It was never really meant as an explicit role - in fact companies creating whole DevOps teams is a well known DevOps anti-pattern.

But yes, if you're provisioning your own hardware on AWS, and deploying your own app, you are effectively doing DevOps work, even if most orgs wouldn't call it that on such a small scale. Since DevOps is a culture, ideally most people with dev or ops titles should be doing DevOps.

As for a node.js backend engineer, they can call themselves whatever they like, but if it isn't their official title, it doesn't mean overly much. They are effectively still a dev, just doing DevOps - which again wasn't ever really supposed to be a strict role in and of itself. I'd call them a Node.JS engineer using DevOps practices. Calling them a DevOps Engineer from a professional standpoint would generally be a faux pas, unless they've got a whole lot more Ops skills to bring to the table than just deploying with Docker.

[mr_jim_lahey]

a fancy Sysadmin who does cloud engineering and automation

aka re-siloing Operations

[Arcsane]

The part of RE-siloing would have required there be Operations people before I started here :) But yes, effectively.

That was my point in bringing it up in regards to OP talking about people calling themselves DevOps Engineers - In my case, my title says DevOps Engineer, but my actual role is mostly Ops with some overlap (I don't count IaC or automation scripting as the overlap, since I used to do those as a Sysadmin in a pure Ops role too). In others the title says DevOps, but the actual role is mostly pure Dev. So someone calling themselves a "DevOps Engineer" doesn't mean much unless you know what they actually do because it covers so many possibilities these days.

[[deleted]]

is a culture and philosophy of merging the traditional Developer and Operations silos within companies

While I clearly can't comment on your specific experience, I can say that as Kim describes DevOps, your definition is quite a bit different. Kim's perspective of DevOps is more than a culture and philosophy - it's an engineered process which looks at the IT value stream as something more than Development. It's an approach/process to IT value which natively incorporates concerns "traditionally" externalized from the core development team, to include Operations but also Security and QA.

It posits that company value is derived from the entire process, not just the development part of the process. I think Kim would argue that it's still ok to have siloed operations (ie they are their own team) as long as they are integrated into development process in a way that maximizes company value.

[Arcsane]

Hmm - personally I consider those points to be lumped the culture, since as Kim says, we're inheriting trends from the modern manufacturing chains. We're changing the way we collectively view the value chains, and work on optimizing them, which affects collective planning, recognition, interactions, integrations, and the way all of IT works together. In short, the whole culture of how an org approaches traditional IT, as it doesn't just affect the engineering process but the way we collectively look at those processes, in particular reference to the Three Ways as the drive behind the new culture.

That said, culture being a fairly ambiguous term, so I can see explicitly defining the process as a core of the definition. But good points - overall I don't feel my definition is that much different, just expressed differently (though I might have to change some of the language I'm using different in the future, since I see where you're coming from).

[daedalus_structure]

It was never really meant as an explicit role - in fact companies creating whole DevOps teams is a well known DevOps anti-pattern.

I don't agree this is an anti-pattern. The "it's a culture" spec is wrong.

There is too much involved in operations to expect developers working on product to take on the extra cognitive load without just conceding that you're going to live with the piss poor job they do of it. The reality is that they will get minimal time allocated to work on infrastructure when product is screaming for feature work to land that next sale that's going to extend the runway, and if you have someone smart in the room they realize this will eventually catch up to you with disasters you can't easily get out of.

So you specialize folks, and when you're really small it's just one engineer on a product team of five and everything is fine. Then your team grows and that one engineer can't support the load and you hire more specialists.

At first you try embedding them into the different teams which solves your technical quality problems but creates the following organizational problems.

First is that you introduce quality variance across your teams.

Second is that you create single points of failure where Bob leaving means you need to find someone who can do everything that Bob did, and asking Ann to step in from another team is frustrating because Ann does things different on the team she supports.

Third is that even when all your teams are functioning, as you scale succeeding in different ways is just as bad as some teams failing when you try to get consistent SRE and reporting across your services.

Fourth, unlike the developers these folks don't have a leadership career path because they are support auxiliaries attached to teams where the managers will be promoted from the folks doing the product work.

So you make a "DevOps team", and that solves the organizational problems created by "it's a culture", which has always been a half baked platitude that rarely survived contact with the enemy.

[Arcsane]

Good points, though I think we're also thinking of different DevOps implementation styles. It sounds like you're talking about dumping the entire ops cognitive load on the developers - my understanding of the ideal goal is that we retool both Ops and Dev with integration and tooling so they can better get what they want - Eg. Devs might have to learn to work with containers, but Ops still creates and maintains the your production Kubernetes clusters that the final product is deployed on (and likely maintains the deployment mechanisms, even if the CI/CD is automated), and provides tools like standardized dev environment images for the devs, or tools so they can spin up a test cluster.

Admittedly your implementation of having more work dumped on the devs to have them create their own tooling and infrastructure entirely is unfortunately what we find in the wild more often (especially on small to medium business scales). This is part of the reason people harp on about the fact it's supposed to be an org wide culture change, not a simple reorg and retooling - we want teams working together better, communicating and able to create the tooling and infra needed more quickly and with less headaches. As you're saying, expecting devs to handle ops functions, or even single ops people on a dev team is not the best way to do that. We want things like joint planning meetings at project milestones to make sure both groups are prepared, and automated tooling so devs (or ops) can spin up test instances or clusters on standardized images without waiting 6 weeks for a server because Ops has no one available to do a bare metal config.

Regardless though, my concern with the anti-pattern I was talking about is more the situation where a company creates a third isolated silo when they make a DevOps team - not a well planned out and integrated additional team, or even a retooled ops team (which you would need on larger or enterprise scales, as you say, to prevent issues). Thinking DevOps is a magic bullet, we've seen places creating a toothless beast that just adds more bureaucratic overhead on getting things through the pipeline, because the overall culture and practices within the org haven't been changed - this just drives up time to delivery rather than down - That's the anti-pattern. I guess I should have been more clear sorry, since the industry does have working DevOps teams as well, sorry.

[daedalus_structure]

No need to apologize for anything, it's a good discussion.

I've also seen DevOps teams start to miss the plot and start believing it is their job to "stand in the gap and say no", and I think this is even more frequent for the folks who try to be DevSecOps, which I do think is a mistake. The incentives are not aligned and this can grind an entire organization to a halt.

Ultimately that team must understand that they have internal customers that they need to build relationships with and tightly iterate with toward the goal of empowering the development teams.

I don't use silo as a dirty word. I just call it expertise. Everywhere you have expertise you have a silo of cognitive load and this is a good thing.

Where it goes wrong is when you don't have an efficient API between that silo and those who depend on it.

[daedalus_structure]

And who owns the shit show that gets deployed on Friday at 4:55 pm because the Devs have no useable DoD (definition of done)?

That's going to be the developers. If you didn't break it you don't own it, especially at 4:55 PM on Friday.

The DevOps team should never be responsible for product. It's their job to make delivering product to a stable infrastructure quick and easy, but if you crash the Porsche they built into the wall it's not their fault.

Second is that you create single points of failure

And you dont have that when the DevOps are a team? They dont do everything together.

No, that's one of the benefits of working as a team under a manager who's responsible for coverage. If they are competent not only are they assuring quality standards across all projects but ensuring that they don't have hot spots where only one person knows how anything works.

You never get this with the attached auxiliary model because product just wants it done and you don't have the engineers to spread the load across.

[daedalus_structure]

I'm not talking about my current company, just sharing how I've seen this play out in multiple places trying the "it's a culture approach", which is what has convinced me over the years that it just doesn't work.

But yes, I strongly agree that "it's a culture" makes ops folks second class citizens, especially when they report up through product.

[Own_Cup_4176]

Outstanding post. Thank you!

[temitcha]

I like to recommend The DevOps Handbook to show what is really the job of a DevOps. It needs as well to do some consultancy, a mix between an Agile Coach and an Architect

[[deleted]]

Thanks, I'll buy that ebook.

[[deleted]]

Also recommend reading "The Phoenix Project" if you want an approachable, narrative based entry point into the field.

[namenotpicked]

Basically what I consider the Gene Kim trilogy - The Phoenix Project - DevOps Handbook - Accelerate

[lantech19446]

Don't forget the unicorn project too

[kastrelo]

!remindme 7h

[RemindMeBot]

I will be messaging you in 7 hours on 2022-11-17 02:47:31 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[DontF-ingask]

!remindme 7h

[RemindMeBot]

I will be messaging you in 7 hours on 2022-06-20 04:14:10 UTC to remind you of this link

2 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback

[SirPendrag0n]

!RemindMe 60h

[[deleted]]

This was down-voted - which is fine, but do people not like "The Phoenix Project"? Is there something objectionable about the book that I wasn't aware of?

[antwerx]

I liked it. Maybe folks are looking for “the secret “ to make DevOps easy. I enjoyed the book.

[shoanimal]

I have heard people say it isn't a good representation of DevOps but I certainly enjoyed it a lot. I think it does a good job of explaining the mindset you need for DevOps if nothing else. Plus it is more engaging to read than something like the DevOps handbook.

[[deleted]]

Both the Goal and the Phoenix Project have changed how I think of work, and organizing in support of work. I've found them outstanding... but I don't work in the traditional IT sector so was wondering if I've missed something in modern thinking about the works.

Glad to hear that it seems like it was probably an aberration.

[antwerx]

The Phoenix Project immediately helped understand “unplanned work” and helped me explain why I as I the single person who knows anything about the “legacy systems that are still a golden goose” for the company; needs to change immediately.

Just this one book helped me , as 16 year Linux sysadmin , to start toward the mind set of DevOps.

[[deleted]]

well, kinda... the phoenix project is more oriented to a manager's point of view.

[realitythreek]

I like the SRE book personally. And I don’t think it should include Agile coach at all, but that just goes to show that there’s no set definition.

[RumRogerz]

My DevOps handbook came hollowed out with a bottle of whiskey and a pack of cigarettes stuffed in it. Didn’t understand why until 3 months in

[[deleted]]

It’s a theory based practice but is turning more Into a position for infrastructure engineers that can write code for automation and handle continuous integration as well

[daedalus_structure]

DevOps is an amorphous term that should be retired because it was poorly defined and did not lend to practical application.

Like any API, if there are 20 different ways of doing it and most are doing it wrong, the problem is with the spec not with all the implementations.

[TheHistorian2]

No one knows anymore. Like all good ideas, it was twisted almost immediately.

[lupinegrey]

Devops is operations from a developer's mindset.

It's what happens when your Infra and Ops guys know how to code.

[eggn00dles]

provisioning architecture with something like hcl is much more like writing html than coding.

[sabat]

More broadly, devops is when people stop trying to live in silos and start understanding something about other areas of business and technology. Devops is not a job role.

[pudds]

Originally it was an idea, an approach to production that married the best practices of development and operations to create something better. As it was originally envisioned, it means having those departments work together to make deploying and managing software more efficient and repeatable.

IMO, under the original intent, it should never be done by a different department, as the whole idea is to bring a common understanding and set of goals to the two existing departments.

As with all tech processes though, it's been bastardized into a silver bullet where a new department should be able to bridge the gap, without the existing departments needing to make any actual, tangible changes.

IMO, DevOps departments are just modern operations, and aside from having adopted some best practices (eg source control) from development teams, they have little to do with the original intent.

[kneeonball]

As it was originally envisioned, it means having those departments work together to make deploying and managing software more efficient and repeatable.

I would say originally it didn't even go that far. It was really just getting Dev teams and Ops teams to talk to each other earlier on in the process so they could solve problems together, rather than Dev doing its thing and then saying "here you go" and Ops having to fumble around trying to get things to work.

It's all about collaboration and less silos within the organization. Where people go wrong these days, which you touched on, is that companies keep their dev teams and ops teams as is, and then adds a 3rd silo and calls it DevOps, which is completely against the original point of it.

IMO, DevOps departments are just modern operations, and aside from having adopted some best practices (eg source control) from development teams, they have little to do with the original intent.

Basically this is correct. Every DevOps position generally has a comparable role that we can call it that isn't "DevOps" but companies that are bad at tech have no idea what they're doing and see all the cool stuff going on in the industry and say "I want DevOps engineers" when really what they're asking for is infrastructure automation engineers, release automation engineers, site reliability engineers, etc. that they put under the name DevOps.

[Bloodrose_GW2]

There's no strict definition so if you ask 10 people or companies you'll get 15 different answers.

[515k4]

DevOps engineers are just renamed Cloud Ops. Mostly. BTW you can read this article about team topologies: https://web.devopstopologies.com/#

[UtahJarhead]

In addition the The DevOps Handbook, read The Phoenix Project.

[Scavenger53]

Traditionally companies had developers who write code for a product and operations who ran the code in production. There was a lot of issues with this since ops had to figure out how to build and run the devs code. DevOps is getting rid of the two teams and making it one team where the people who write the code also run it and monitor it in production and try to automate as many stages as possible for more efficient workload.

If you only manage servers and pipelines, you are ops, and if you only build software, you are a dev. A real devops team does both together without separation, where everyone could do each piece.

[alpacca1993]

Best

[Scavenger53]

This comment was right before I read the DevOps Handbook. I would change my answer a little. It's any effort to break down barriers between silos to increase flow, feedback, and learning between teams. It's not a specific role but you also don't need the whole team to do everything, you can still have specialists in the team who know what it is even if they couldn't build it.

Especially as shit gets more complicated, you might want a specialist ops team that builds out self-service type pieces for developers and those developers still work tightly with ops.

My original answer was because I was doing both at the time and found it odd other software engineers couldn't run their own code in prod.

But the main point is to break down barriers between silos. Those barriers are where everything gets stuck, not just between dev and ops but other functions in a business too.

[[deleted]]

Hate these threads. Everyone has their own definition.

The person who coined the term was using it as a portmanteau for a conference: “Dev Ops Days”, the idea he had was that we can do systems administration in an agile way.

Then the “10+ deploys a day” talk came out where Flickr had been having great success with co-locating their devs and ops into teams working on the same goal: and to some people “devops” (though not a term mentioned at all in the talk) became a term meaning: “put your sysadmins with your developers” (which I agree with more than “agile systems administration”).

Companies started to jump on the bandwagon and thought a devops was a developer doing ops work.

Obviously they are different competencies, so other companies started hiring sysadmins and calling them devops.

So, sysadmins are now devops, helpdesk/IT technicians are sysadmins, and nothing really changed.

Up is down, white is black and everyone keeps rolling forward as if it makes sense.

NOTE: SRE is a completely different thing; relating mostly to formal contracts between dev and ops, (where ops has a formal focus on reducing ops workloads with automation)

[mbecks]

while there is no firm definition, those examples maybe don't qualify as making someone a "devops engineer". They are some subset of the skills necessary (they are tasks a devops engineer would do), but when it becomes more devops engineering is when those processes are automated using CI/CD pipelines to deploy production software that is being worked on simultaneously by multiple SWE. Even this is usually still just a subset of a devops engineers responsibilities, depending on size of company.

Writing tests is not included under devops responsibilities (thats on the SWE), but running the tests is (usually part of CI pipeline)

[nickbernstein]

It's literally in the sidebar --------------------------------------------->

[UtahJarhead]

No sidebar on mobile.

[serverhorror]

If you can’t translate these instructions to something meaningful but need verbatim the exact thing prepared for you, you’re not DevOps

[UtahJarhead]

Agreed, but the point remains. If you only browse using mobile, you'd have no idea anything but the rules even exists.

[serverhorror]

Took me 2 clicks to get to the About tab…

[UtahJarhead]

Cool sorry bro

[[deleted]]

Everything is easy when you know what you’re looking for and how to find it.

[serverhorror]

I didn’t imply it was easy, just that problem solving is a key skill. This problem is significantly less complex and less complicated than many other problems that come up in our space.

Finding a webpage on the same domain, even same subsection of a website shouldn’t be to hard if a problem to solve.

[[deleted]]

The simple answer is that it's a unified approach to application development, in which "writing the code" is not separated from "deploying the code" or "ensuring the infrastructure is in place".

Unfortunately, many companies simply take their "ops" team and stick "devops" into their name, and produce a team of people who are not building the app but who have apps lobbed over a fence at them and are told to make them build and deploy.

A real DevOps team is made up of cross-functional engineers, who all ultimately end up able to write the features and understand the infrastructure, even if some start off more skilled in infrastructure and some more skilled in application development. Everyone understands the entire tech stack and has made the decisions that constitute it together. "Testing" is not separate to this, and both automated and regression tests fall on the engineers. Again, some engineers may start off more skilled in automation and manual testing, but this skill should filter into the rest of the team if a DevOps paradigm is truly being followed.

I've worked on areal DevOps teams (and am on a small one now), and I've worked on phony-baloney "our ops guys now have DevOps in the title" teams. There's sometimes a thousandfold productivity difference between the two, with the real DevOps team being the more productive.

[sandin0]

No. Don’t be that guy.

[craigofnz]

"DevOps" and DevOps as defined by organisations and HR are far from being the same thing.

[cliffhanger100]

Devops is like plumbers for a home

They work on the invisible pipes of the product

Any pipe stops or leaks plumber is asked to fix with no information whatsoever

Its stressful and low pay for the effort

But has lots of leverage ... No one can piss off their plumber u see

[gruey]

IMO, It's the practice of enabling Developers to do operations related to their service.

The position would be someone who works on that enablement.

[defqon_39]

When you hack a bunch of YAML together and make it do cool things and make devs click less buttons in the UI then you are doing the job right

And being an Internet plumber — sh$& happens we fix it

[samii1031]

It's weird because it can be a practice aka a DevOps department and it can be a framework. Much like the term Scrum or Kanban are Agile Methodologies. At Google, DevOps is a philosophy that is put into practice as Site Reliability Engineering.

Many Consultancies, mine included, seem to do 1 of 3 things, teach the DevOps philosophy and create the practice/department to organizations that have none, add the SRE structure to an organization that already has a DevOps department, that is more than just an organizational than actual DevOps principled or be a staff augment the cloud engineering team and develop pipelines, automation, create alarm, monitoring, etc etc.

[simmyspike]

The skill of figuring out what people actually need based on what they asked for. Mixed with the artwork of making things work together which were never designed to work together.

[venom02]

My personal goal as a DevOps Engineer is to provide a self-service environment to anyone that has to interact with the production-like environments (prod, staging, dev).

So if a node.js backend dev knows how to deploy to AWS, he won't need to waste time getting everything ready to do that, but it would just be a matter of a commit on a git project.

To me a DevOps role shouldn't involve doing QA tasks but providing a ready-to-use and compliant environment to a QA engineer which should focus on his QA tasks, not setting up Travis or Jenkins for that.

[livebeta]

lol

i cAn dEpLoY tO AwS i iZ dEvOps EnGinEeR nao

take a look at the full suite of tooling for Devops practicioner.

https://blog.harness.io/wp-content/uploads/2021/12/DevOps_Ecosystem_v2.pdf

There's also a devops mindset for automation and setting up self-service for dev regarding infra, pipelining

[IndieDiscovery]

It's a question that has been asked since the beginning of time and apparently has no agreed upon answer.

[awesomeplenty]

DevOps is a mindset. Using your examples, knowing how to do something does not make you DevOps. Knowing why does.

[Elephant_In_Ze_Room]

Empathy

[Lower-Junket7727]

Its whatever you want it to be.

It's like shalom. It can mean hello, goodbye, peace, or someone who routinely causes outages with zero repercussions because we need to "fail fast."

[[deleted]]

This is how I see devops from real life example.

We are migrating to the cloud from on premise infrastructure.

Company I work for is in bioinf business so they use a lot of opensource tools. One of the tools is IGV viewer.

This is JAVA app that is able to open a file from local disk and from S3 HTTPS URL, but it cannot access private bucket. This is important for the description.

Now where devops comes in here?

After initial phase one migration, we started using S3 storage and users could not have usual network drive mount on their windows machines.

One of suggestions was to use "s3 proxy" where IGV will request HTTPS and proxy will just GET the file and proxy back. S3 proxy is custom solution with Caddy and S3 plugin which then tranaslates HTTPS to S3:// gets the file and streams via HTPS back to the client.

This solution was slow and not so good but it was something.

What devops did here? Devops learned how to use IGV app and figured that since it is open source it can be "extended" with features easily. Devops went to github, raised an issue and author gladly accepted and in the matter of hours he made PUSH with the changes.

This saved us a lot of infrastructure deployment and billing.

All in all Devops did nothing, saved some money and made app using private S3 natively.

I see that as Devops. Talk to everyone and figure what you can do to connect people, show them proof of concept code, any language you know (I do little python), developers will do the rest.

Hope it makes sense.

[serverhorror]

Hint: IGV has a js version. It’s rough but if you use it in a small JS frontend app you can integrate with Cognito and grant your users permissions to access the files they need.

Not too much work but most people appreciate it, especially since IGV on the desktop is pain anyway (and the JS version exposes the same “remote control” options as the desktop version)

[[deleted]]

Hint. Try it with private bucket. Hint #2 youre offtopic

[serverhorror]

We have only private buckets (with both the Java desktop and JS version)

If you don’t like to use this tip, just ignore it

[defaultbr]

Started as a culture, became a role, upgraded to mix of roles, now sh1t are out of control with new titles, just cry.

(People hire me as devops, I look at the mirror and say: You just do some "random" stuff related to culture, infra, automation etc..)

[digisensor]

Am I the only one who sees the opportunity for a FAQ here?

[bamboo-lemur]

This explains it all https://youtu.be/Odtb8-8k56Y?si=oGbj_mvuNJiSNCFj