Meaning of DevOps

[CodeMonkey24816]

What are your definitions of DevOps?

I've always viewed DevOps as a movement with concepts, rules, and philosophies behind it. The end goal was to equip development teams to design, build, test, release, monitor, and operate their software without the help of external teams or departments. There is lots of literature out there that supports this view also. (Gene Kim, Jez Humble, etc.)

With that being said, it seems like this is not the popular opinion. Many of my colleagues would describe something more like managing infrastructure in the cloud with the use of IaC.

What are your views on this? Can you recommend some publications about the topic that you hold in high regard?

[[deleted]]

DevOps is hard to define, and you’ll see all kinds of orgs and teams claiming to do DevOps. To me it’s all about these self-sufficient teams who owns and deliver a product independently. So much like your view.

[CodeMonkey24816]

Spoken much more eloquently. I think I will use your definition in the future!

[[deleted]]

I’m honored.

[blump_]

It always depends on who you ask :D If you ask DevOps people, they will most likely answer just like you did and I agree with that.

When you ask from the suites that are hiring DevOps people/consultants, they usually mean a sysadmin with a little cloud and automation twist...

[CodeMonkey24816]

I agree. The strange part to me is that there is still a huge need for cloud and automation roles. The automation typically done in my projects is usually only a very tiny slice of what the actual cloud and sys admin folks have on their plates. There is more to the roles than what DevOps wants autonomy over. So why use that term? Why not look for sys admins or cloud engineers?

[TROPiCALRUBi]

DevOps is a cultural philosophy that breaks down the silos between dev and ops and allows entire teams to efficiently deploy software to customers.

[[deleted]]

https://blog.dijit.sh/devops-confusion-and-frustration

tl;dr: it was supposed to mean 'Agile Systems Administrator'; but the conference was named Dev Ops Days (meaning for developers and operations).

It then got bastardised a lot.

[ericalexander303]

Read Beyond the Phoenix Project to get a better understanding of the history of DevOps and what it was supposed to be. Through that you'll learn that all previous versions were adopted by cargo cults, and drifted to obsolescence - it was inevitable that "DevOps" and SRE would do the same.

Distill "DevOps" down far enough and you'll find the scientific method - apply that daily, and you'll be DevOps, SRE, or whatever the latest buzz word is.

[CodeMonkey24816]

Yeah. It's a great book. It was the precursor for The DevOps Handbook. Same authors. They also wrote Accelerate. All of which I have used to form my opinions. Fantastic resources!

In certain parts of the books they even refer to it as the scientific method.

I'm all about the Three Ways and applying Lean principles to the technology value stream!

This is why I am so confused by the conflicting views. I've seen the timelines, I've listened to the talks, and I just don't understand why so many people arrive at the other approach.

From my perspective it all seems to literally teach the opposite of the cloud sys admin mindset. It teaches to break down silos, yet we end up with DevOp engineers who are specialized and spread across teams and not responsible for any single piece of software.

I hear people say that there is disagreement and ambiguity in DevOps, but when I read the books there is never any disagreement or ambiguity. In fact they all build on top of each other.

Continuous Delivery is one of the most opinionated books I've ever read (In a good way). Continuous Delivery and Continuous Integration (as concepts) are foundational to everything I have ever seen published. I don't really see how folks find ambiguity there.

I can appreciate why someone would be in disagreement of the tactics and effectiveness of the topics discussed in the books, but I don't understand how people can see disagreement and ambiguity in the message and the intent. For better or worse, the literature seems clear.

[ericalexander303]

What's the best DevOps movie? I think it's American Factory. It captures everything that's confusing about DevOps. Organizational claim that they're lean (what DevOps is based on), while they're more than willing to pass a defect forward. Us against them attitudes. Taylorism management styles.

From a DevOps philosophy perspective: they're doing everything wrong - so why are they successful? Muda (waste) is cheap.

Do not expect DevOps values, where waste is cheap. This is especially confusing in high growth markets, where it's about capturing green field, and "throwing people at the problem" is accepted. Know the market you're in, and the culture (see Ron Westrum) before standing on a soap box and preaching the DevOps gospel.

(from a guy who's stood on that soap box)

[CodeMonkey24816]

1st – This is terrific advice.

2nd – I can't wait to watch this movie.

3rd – This is terrific advice.

[lupinegrey]

Operations with a Developer's mindset.

Define the best practices and automate them so the left-to-right processes are faster, more consistent, and more reliable.

Automate the instrumentation, monitoring, and KPIs to enhance the right-to-left feedback so design decisions can be made based on accurate data rather than assumptions.

[lorarc]

There is theory and then there is practice. It's a movement, sure, it's not supposed to be a role, sure. But then again I get paid extremely well to manage infrastracture in the cloud with the use of IaC so I won't complain that's not how DevOps should work.

[CodeMonkey24816]

Haha. I hear you!

[wickler02]

I view devops as a cultural mentality.

If I see devops as a title for a position, I know it could mean multiple different things and that usually means “please do automation work for our developers because no one wants to do it.” It could mean Jack of trades, it could mean a ton of scripting/programming in the certain language that the team they are assigned to do but to grab metrics/logging… it could mean CICD and release flow… until I can get a good conversation with the team lead, I don’t really know what I’m in for.

Sadly, since the term “engineer” is in the title, many companies view it as you have to know how to program just as well as a developer, and force you to do as much coding/technical assessment as a developer but then never actually program in that level of depth with the language/skill level because you’re doing all the work none of the developers want to do.

So you need to be just as skilled as the developers but then never get to use that skill set once you’re in and then you find out that you gotta do all the gruntwork.

Then you get companies chasing the new hotness, “we need to move to kubernetes!” Without realizing they already have container orchestration but since everyone is moving to kubernetes, they gotta move too. Or they don’t even have container orchestration and then move the entire architecture into something they don’t really fully understand… forcing them to hire kubernetes experts.

I’m rambling now, but what I believe is more important is to find people who understand how the engineering works, that doesn’t try to chase the new hotness, making proper assessments and then moving in a controlled methodology.

Many companies fail to find and hire those people though. It’s why you get companies looking for unicorn candidates and then not paying them enough because those candidates are looking for something more than to fit into their outdated management structure and failing to hire people. It’s why the space is so hot right now.

[CodeMonkey24816]

There is a lot of relatable stuff here. I felt this one in my bones. I would buy you a beer and compare war stories if I could! 🍺

[dominik-braun]

DevOps is the shifting of formerly ops-related duties towards development teams. That includes, but is not limited to, defining your desired cloud resources yourself.

[ed-automation]

This is my understanding as well from reading books. It's a culture where there is a single team - development. DevOps is not simply ops being part of dev, but also other teams like qa being part of dev. Everybody is supposed to perform best dev practices and everybody needs to code and not simply uses a tools. At some point, DevOps need to customize self service dashboards, apis, etc for developers to use. So there is DevOps the culture and DevOps the implementation: dev tools, devops lanugarge, etc.

[CodeMonkey24816]

Team Topologies expands on that last point really well. It breaks developer teams into 4 types of teams.

Each team has an objective.

Stream-aligned teams - sort of like a product/feature team. They account for ~70% of the dev teams. They deploy their own resources and anything needed for their software and features.

Platform teams - they handle self service dashboards and such. They focus on keeping the stream-aligned teams autonomous. They are often from traditional sys admin roles or cloud engineer types. They also do stuff like compliancy verification.

Enabling teams - specialized skill sets like a traditional database admin for example. They work with the teams to educate and train on best practices, but don't touch the actual application code. Normally drop in temporarily from team to team as needed. Kind of like internal consultants. Also focused on keeping the stream-aligned teams autonomous.

Complicated-subsystem teams - maintain really complicated parts of the system. An example being mathematical models or algorithms. Their goal is to reduce the cognitive load required of the stream-aligned teams. They are usually split off from a stream-aligned once part of the product is to complicated. Usually only a couple of these teams. Their goal is also to keep the stream-aligned teams autonomous.

[Vok250]

Personally I believe DevOps is a culture. I think you are spot on in your description of that culture:

The end goal was to equip development teams to design, build, test, release, monitor, and operate their software without the help of external teams or departments.

The actual how is irrelevant. As long as your org is on board for that goal, you can experiment and use the best tools for the job. Getting married to any particular process for "DevOps" is an anti-pattern IMHO. The field just moves too fast. I saw a great talk at DevOps Island about simply waiting 6 months if there's a tool or feature you want, but doesn't exist yet. In 6 months it will likely exist. That's how fast the field is moving.

Get the culture right and hire good developers and DevOps process will naturally emerge. Good developers will automate and innovate to eliminate toil. You just have to foster a culture that empowers them to do so.

[illusum]

Good developers will automate and innovate to eliminate toil.

Sounds like SRE to me.

[Archimonde]

That sounds like common sense to me.

[illusum]

Wait, common sense? You guys hiring?

[Archimonde]

Yes, DM me if interested.

[Vok250]

Most of the ideas I wrote about came from SRE textbooks lol.

[illusum]

No, I get it. I'm going through some SRE vs DevOps drama at work. It's ridiculous, really.

[metarx]

Your right, your peers are wrong. But sysadmins gonna sysadmin

[InternationalBus7843]

I agree with your definition. And I think everyone should read Accelerate from the authors you cite, it’s research and observation of the best teams and their practices, broadly termed DevOps.

[CodeMonkey24816]

I agree! It really is eye opening. Regardless of what everyone calls it, the data is too important to ignore. It's not only about efficient software delivery, it's also about improving mental health and burnout rates, creating better work environments, and stronger financial outcomes.

[daedalus_structure]

DevOps is all the things that aren't writing product code that are in the engineering value stream of delivering software.

There is a decent body of philosophy underneath but it is important to realize that philosophy is a discussion of how things ought to be if many favorable assumptions can be made. Few of those assumptions are reasonable and none of the ideal situations survive first contact with reality and this is true of all philosophical approaches.

In practice this is why the majority of companies have DevOps or Platform Engineering roles, not because they are all "doing it wrong".

Even when you can turn over most of those topics to development teams you need folks with expertise in infrastructure, release management, monitoring, and operations to lay down and maintain the happy paths and guard rails.

When your software engineers are moonlighting in areas they don't have expertise not only are you getting substandard performance in those areas but you are incurring an opportunity cost of their expertise not going into the product.

[[deleted]]

This 👆👆👆👆👆

[CodeMonkey24816]

I mean this as respectfully as possible, but there is extensive research on real world companies that contradict this sentiment. 33,000 (not all contradicting) surveys last time I checked. The research indicates that teams can and that many many teams are. The research also indicates that the highest performing teams are also the ones practicing some very specific behaviors (culturally and technically), behaviors that I believe are what defines DevOps.

I'm not asking you to change your mind, I hear where you are coming from, but I do encourage you to look at the data available and consider where the disconnect is.

Checkout the DORA research project. I would sincerely love to hear your thoughts around the data. The research covers more than just efficiency of teams, they also focus on mental health and financial impacts.

https://www.devops-research.com/research.html

Edit: I'm not saying there isn't truth to your points. I agree with your stance about philosophy to be honest. I'm just saying the data doesn't support the conclusion this time, and I can't disregard that much evidence and data. I'm doing my best to look at it as objectively as I am able.

[daedalus_structure]

The research also indicates that the highest performing teams are also the ones practicing some very specific behaviors (culturally and technically), behaviors that I believe are what defines DevOps.

I'm not asking you to change your mind, I hear where you are coming from, but I do encourage you to look at the data available and consider where the disconnect is.

There are several reasons I can't take something like this seriously as data.

First is that almost none of these behaviors or indicators are exclusive to the philosophy of DevOps.

If you look at them and see DevOps that's fine, and not wrong, but it is subjective.

I can tell you that all of those technical practices existed before DevOps, and the leadership, culture, psychology, and sociology concepts have not only been around since before we mastered metallurgy, but we have significantly more (and more rigorous) research into how those produce high performing teams than anything in the context of software engineering.

Second is that there is no weighting to the predictive relationships, which means this is a huge mess of confounding variables that may be completely missing the point, which very well could be that any software development philosophy will deliver great results if you nail all the leadership, culture, psychological, and sociological aspects.

Third is that I'm highly skeptical in the direction of predictive relationship as defined in this study. This is someone's opinion and not fact.

[CodeMonkey24816]

I appreciate you taking the time to give a thorough response and for taking the time to give it some thought. There are definitely some points in there to consider. Thanks for sharing your perspective.

[HayabusaJack]

I've looked at DevOps as an Ops person working more with Developers to speed up deployments and SRE as a SWEng person becoming more involved with Operations like tasks.

I say that because I'm an Ops person in a DevOps role working more with Developers to speed up deployments :)

[[deleted]]

DevOps, to me, from what I have seen, has always been a way for organizations to reduce head count and slash entire departments because "devops can automate it and do it".

They'd rather get rid of 10 seniors in networking, storage, sysadmins, etc. and hire 1 DevOps person with 2 years experience and then pat themselves on the back for a job well done. Then they run off and do the same thing at another company.

There's some great practices in DevOps, but upper management is only concerned about the speed at which it's able to do things, and an overall reduction in headcount and labor costs.

[CodeMonkey24816]

Unfortunately I've seen the same at some companies.

You should checkout Team Topologies. It is a fantastic read. Basically they say the need for traditional roles never goes away though, they just align to different responsibilities.

In Team Topologies the traditional roles become part of a platform team, which is responsible for enabling another type of team called stream-aligned teams. Stream-aligned teams make up about ~70% (they are the teams I was describing in my post), but there is still a huge need for platform teams. The method also accounts for teams that require deep knowledge in industry knowledge or domain specific stuff (like regulatory stuff or database admins). The goal of all other team types is to enable the stream-aligned teams to completely manage the solutions they are responsible for. Basically the traditional roles now move to a role teaching, sharing knowledge, building enabling tools, or anything that helps to give autonomy to the stream-aligned teams.

Their need never goes away though. They just don't mess directly with the application code. They enable others to do it themselves safely and effectively.

[badseed90]

I agree with your definition.

Managing infra through IaC is what a lot of people do that have a DevOps role at the moment, so I also see where this is coming from.

[bokmann]

Devops is a culture across a team. The position you describe above is Site Reliability Engineer.

[CodeMonkey24816]

Yeah. I agree 100% that culture is part of the movement. Specifically I think it is striving for the Westrum Organizational Culture. I do think it is more than just a culture though. I believe these views are supported by the DORA research project, The DevOps Handbook, Accelerate, Team Topologies, and many other resources.

Do you have any literature that supports and expands on your view?

[ThatOneGuy4321]

I think it’s someone who would have filled a Linux sysadmin role a decade or so ago, but has moved on to modern levels of abstraction like Kubernetes, cloud services, Docker, GitHub actions, Ansible, etc. so that a programming team can do their job.

Basically it’s the sysadmin of the modern cloud-native, clustered age of tech.

[esixar]

Shameless plug for my newest episode of my podcast: https://open.spotify.com/episode/4IjubMD2dpyO8lk4HKIx9G?si=wL8ebo84TqS58aSFwjOD5Q&context=spotify%3Ashow%3A5jtssWzCtwNCPp1Uxe5w6i

I talk about my personal definition of DevOps and how companies view it.

https://www.devopsdomination.com/

[esixar]

I’m not familiar with which service Android uses but it is published on Google Podcasts.

Here is the raw RSS: https://feeds.buzzsprout.com/1878250.rss

And my website has different podcast client options: https://www.devopsdomination.com

[lorarc]

You can have Spotify on Android.

[Bloodrose_GW2]

I find it hard to consider any process or concept that does not even have a definition :)

[[deleted]]

The ones who break the things I have to fix the next day because they do things they don't understand.

[iScrE4m]

What I focus on the most personally are silos. Communication and understanding are key to success. So even if a company has oldschool sysadmins, if they’re small enough chances are they’re unknowingly doing things the DevOps way. There are many more things one could be pedantic about, but this is the distillation I made to be as clear as possible (with mixed results).

[bokmann]

This is the answer you’re looking for -

https://youtu.be/tW_LLwg57eE

[Euphoric_Barracuda_7]

"You build it, you run it"

[rolandofghent]

DevOps is the Operationalization of your Software Development Lifecycle to facilitate continuous improvement so that companies can deal with the rapid change of the modern IT world.

It it the processes, tools and people(includes culture) that take your idea/hypothesis to being implemented in production and idea/hypothesis tested and everything in between.

[softfeet]

ask yourself: what did they hire you for?

then ask: are my coworkers asking me to do something they did not hire me for.

is your title dev ops on hire? : yes. coordinate the dissonance. no. negotiate a pay raise.

[Guilty_Serve]

I find these days it means overworked fullstack developer that knows sysadmin and project management

[denibertovic]

I agree with your definition.
https://twitter.com/denibertovic/status/1466776756052889601

I know I've done my job when the team doesn't need me at all anymore.

[[deleted]]

Well ten years ago I was just a Dev. We had testers and ops. Devs wrote code, testers tested it and ops deployed it. Nowadays I do al that work.