[mugsie]

DevOps as it has been implemented in tons of company is bs.

Its like the "Agile" push that companies thought they could get by buying a tool, and changing nothing else (release schedules, feature based release dates etc).

My favorite way of looking at it is simple - replace the word DevOps with empathy. That is the core of the idea, so lets try it - "Empathy Team", "Empathy Person", "Empathy Engineer".

DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team.

[mhurron]

> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team.

Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.

[bobmagoo]

That's exactly what my previous company tried to do with their development team.

It caused the dev team to implode (everybody but one person on the 8-man team left within a year). The systems' stability and overall architecture was utterly terrible, servers would fall over because they would log so many things that they'd run out of disk space ("what's logrotate?" "What's a slave database?"), no metrics, no definition of success for a service, etc.

I suppose you could pull this "DevOps" thing off if you really wanted to, but you have to hire folks who can program and actually like sysadmin work. Otherwise you end up hiring developers to do everything, who are terrible at sysadmin work, and who get burnt out because they never get to actually program.

[mhurron]

You're still trying to make developers do everything.

DevOps is not get rid of the Ops team. DevOps is not get rid of the dev team. It is get Ops and Dev to talk and understand each other. Ops should not be completely clueless as to how the developers workflow works. That doesn't mean they are a developer. Development should not be completely clueless about what happens during deployment but that doesn't mean they're on call to handle OS issues.

DevOps is these two teams are working for the same company and same goal, so damn well talk to each other and act like it.

Hint: In a devops work flow, if you were large enough to need a separate ops team, you still have a separate ops team.

[icedchai]

Or, in the small company case, you never hire any dedicated ops people to begin with. You have developers fighting fires all day, getting interrupted constantly, causing them to hate their jobs.

[gibsonje]

Small company. We don't have many problems. We have a couple pain points but we fix them over time. When hosts die, it generally doesn't mean anything. There's redundancy in all things. I don't find myself interrupted often.

Previous job had a "Systems" team and a "Database" team. Both were just teams of obstructionists.

"Oh you need something today? Well, if you get a jira ticket made I could look into getting the requirements written up sometime in the next 2 weeks, to get the work assigned out next month."

Not saying that's the norm, but damn I hope I never experience that again.

[marktangotango]

If you were the guy getting hit from 20 different people, each with their own emergency, has to be done now, $4 million deal counts on it BS task, I wager you'd be singing a different tune. Oh and come to find out, that $4 million dollar deal? It had fallen through the previous month only no one had communicated it to the person makeing the request.

My favorite was the marketing manager who thought an email, with a full size image attachment, and note saying 'this needs to go on the marketing site' was sufficient requirements.

Requirements and prioritization are not a bad thing. Excessive bureaucracy is.

[gknoy]

  Both were just teams of obstructionists.
  "Oh you need something today?
    ... get a jira ticket made 
    ... work assigned out next month."

It is possible that you might have a different opinion of the situation if viewed from their perspective. It's likely not deliberate obstructionism, but rather them trying to triage the requests so that they can be most effective across all customers. (It's possible that your ops team did not adequately communicate this to you.)

In my current job, I am the sole developer responsible for maintaining a certain set of our codebase. I have multiple internal customers, each of whom have separate (external) customer-facing needs. I have enough tickets created for three people working full time, so I am constantly having to triage which are the most important.

Part of the solution to this was to have a proposed plan for when to work on things -- I can then say, "Thank you for this well thought out ticket. I will be able to work on that in June." The most important thing is that my users' opinion about the criticality of things does not always match the overall picture, and I am always having to choose which tickets to postpone.

[ploxiln]

This is a good point, but it's a sign of dysfunction. I've seen the case when 50% of the issues are "P1 highest priority" (and most of them forgotten in a week or two). People making requests need to get some idea about what development effort (and maintenance!) costs. I don't know a good way to do this, except to be in a very small company.

[smackfu]

Tickets at least require things to be documented, which is the biggest problem with ad hoc devops.

[smiler]

Sounds good. Does your company hire remote? :)

[digi_owl]

As an outsider i feel that the whole devops thing has come from a few web people spinning up some slapdash service using AWS etc and call it a day. Then something breaks and it is firefighting from that day onwards.

I wonder if one can draw parallels to the BYOD thing.

In both senses it seems to boil down to someone bypassing the IT admins because their manager wants to see results ASAP, and IT is going "sorry, budget and/or regulations says we can't at this time".

[mugsie]

I actually look at from another perspective:

It seems to have stemmed from Ops teams saying "What can we do let dev teams build what they want, but in a way we can support it"

e.g. - a system needs an entry in the /etc/hosts file (a bad example I know, but a nice simple one for the basic use case)

old method: Dev files a Jira ticket, and the Ops team make it part of their golden images for production.

new method: Dev makes a change in the Config Management DB. Gets reviewed by a member of Ops, who either approves, or makes a suggestion to change it. Change gets tested against staging, then merged, and the system gets updated.

Ops know what the system needs, Dev knows how long it will take, and has an understanding of how it is deployed in real life.

[icedchai]

Actual new method: dev logs in to production server, changes something live as part of a emergency / hot fix. It never gets documented anywhere.

[toomuchtodo]

I wouldn't go that far. Its documented on the system when it gets hot imaged and the image is never rebuilt from the config mgmt tool again /s

[dreamfactory2]

so not code as infrastructure and therefore precisely not devops

[curun1r]

My view is slightly different. I see the rise of DevOps as coming from realizations about how modern applications are structured and how that's incompatible with the way operations used to be done. Think standard n-tier architecture vs a micro-services architecture that auto-scales depending on load.

Applications used to run on a fairly static number of instances that were maintained by an operations team. When more capacity was needed, operations would provision new machines. But now, especially with the increasing shift toward the cloud, infrastructure is seen more as something that's created programmatically, or even in response to events (load or otherwise) in the network. It's a powerful conceptual shift to think of infrastructure as something that isn't physical, but is more ephemeral. Just like a process on a server may die, a server on a cloud hosting platform may die. But you can engineer for failure at the infrastructure level the same way that you'd engineer for failure at the system level.

With this change, you can no longer rely on a fleet of sysadmins to manage everything for you. Instead, you rely on scripting everything..."Infrastructure as Code." You create recipes to create each and every part of your infrastructure and tools to orchestrate everything. Gone are the days where you actually ssh to boxes in a terminal...there are far too many boxes to make this practical. Instead, ssh becomes the protocol that your orchestration uses to communicate with its fleet of machines. Things are much more dynamic and you start to view your infrastructure more holistically rather than as a collection of individual machines.

Once you've started to think this way, you realize that neither the traditional development mindset or the traditional operations mindset work in isolation. You need to meld the two together so that operations understands better how to automate everything and development understands more about the environment in which their code will run.

[HelloNurse]

What you describe is coping with situations of high infrastructure complexity and unreliability (many servers, moving and failed servers, etc.) by adopting advanced scripting and more abstract and sophisticated administration tools. It is an interesting technology trend, but I fail to see any significant social and organizational aspects beyond demanding everyone to be more competent.

[kyllo]

Yeah I can see an argument for having development engineers and production engineers so that the devs writing new features can focus on that without getting distracted by production issues. The production engineers do monitoring, config management, and bug fixes for prod issues.

The problem is in most orgs, the roles for people who fight fires in production tend to be demoted to a lowly "support" title, and paid/hired for accordingly, which is really not commensurate with the value they provide to the organization.

[amyjess]

I had several reasons for leaving my last company, but this was one of them. We had no QA, no IT, no ops. We just had devs doing everything. It might not even have been that bad if we were fairly compensated, but we were all making 3/4 market value in terms of pure salary, no insurance, and no equity to make up for it.

We were understaffed, underfunded, and underpaid.

[pjscott]

I was in that situation once, in a previous job. It sucked, so instead of fighting fires all the time, we fixed it. We sought out and exterminated bugs, we set up better monitoring, we wrote automated fixes for the things that could be automatically fixed, and so on. Pretty soon things quieted down for good.

[bcoates]

> Most posters here don't seem to get it. Most replies appear to be the idea that DevOps means you fire your Ops people and the Developers do Ops previous job and their own Development job as well.

Exactly, you have to fire the developers too.

[rem7]

yeah, CTO should be doing devops...

[exelius]

> DevOps is about dev and ops teams communicating and having empathy for the requirements of the other team.

DevOps is about not having separate dev and ops teams (or QA for that matter). It's about having one team that coordinates on implementing user stories and comes up with the right solutions. Some members of that team have certain skill sets - i.e. some are more ops focused and some are dev focused - but it's one team. It's about creating personal accountability; there's no more blindly assigning tickets to an offshore ops team and hoping it gets done right. If you're doing DevOps right, you developers and your operations people are on the same team, sit in the same area and attend the same scrums.

DevOps means that instead of saying "Ok, my work is done, but the deployment scripts need to be updated so I'll create a ticket with the ops team and they'll get it done next week", you can say "Ok, my work is done, but the deployment scripts need to be updated and I don't know how to do that, so I'll assign it to Mike." The feedback can go the other way too - if an implementation of a feature is too cumbersome to deploy, the ops guys are in the scrum with the dev guys and can work on a better design together, up front.

[chatmasta]

One good solution I've seen to this is a hybrid approach. QA was their own team, but sent a representative to each other team. That meant QA engineers had two scrums each morning -- one for the team they were assigned to, and one for QA as a whole. It worked very well. QA had their own processes that other teams didn't need to worry about, but QA also understood the needs of all other teams.

[smcl]

Obligatory quote echoing your final sentence, from the seminal DevOps thought leader Jon Hendren: "DevOps is mostly just a way of reorganizing all your nerds and making them talk to each other more"

[VLM]

"replace the word DevOps with empathy"

This scheme also works with diversity, quality, best practices, and change management.

[serve_yay]

I seriously can't figure out what the hell you guys are talking about.

[mugsie]

Yup - it does. I just seem to prefer the empathy quote for some reason :)

[mmatants]

Empathy is the actual mechanism for how those other things (quality, etc) are achieved. Diversity helps empathy (represent the user and relate to them better).

[VLM]

Another way to extend the analogy is its a standard management technique when provided with something you don't want to do, set up an isolated team with no deliverables, no authority, and no direct reports. Ta Da we got us "quality" or "diversity" or "Dev Ops" and we didn't have to change anything.

[signal]

That's close, but still a problem. If you put change responsibility formally on the shoulders of a team or individual you're throwing them under the bus. It needs to be approached as a cross-functional team initiative (which is reproduced to scale out). A DevOps team might work if they're in a leadership position, but how does it work on the ground?