Earlier quoted context omitted.
Yerp. As a former *nix admin, around the time that "DevOps" became a term, I read it as "system administrator, who also now has to fix developer code." Which, honestly, was already part of the job at a lot of places I've worked, owed to the age old problem of people who "test" something on their weird personal desktop environment, then hand it off and shrug off any questions with "well, it works on my desktop". That…
It’s a tough place to be when the bar is perfection
DevOps is broken
351–360 of 363 posts
Re: DevOps is broken
#352Earlier quoted context omitted.
The extent of devops for your developers should be: 1. Push code to an automated pipeline 2. I understand that the automated pipeline may need input from me in order to run successfully. Beyond that, you need other people building the "platform" that they're deploying to (for the most part). Probably the ideal example here is Heroku. Your devs shouldn't be required to do all of the actual ops stuff. They need access…
To grossly oversimplify, there are essentially two views of DevOps. 1.) What's probably the traditional view which is breaking down the walls between devs and ops, developers carrying pagers, etc. I.e. at least in an idealized world, there are no devs and ops--only DevOps. 2.) As you suggest (and which probably more closely matches how "DevOps" works especially in larger organizations), an internal (or external) oper…
Re: DevOps is broken
#353Earlier quoted context omitted.
> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :) As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all. My personal favourite is how many large multi-nationals are now building in-house clouds? WTF is the difference between an "in-house…
An in-house cloud will just be a bunch of commodity servers running a hypervisor that gives you an API that allows you to automate the provisioning of infrastructure. I am guessing that in the 80s you weren't writing Infrastructure as Code to define exactly what resources you needed for your software, having it all set up automatically, and so on.
https://en.wikipedia.org/wiki/Job_Control_Language
True, they didn't call it "Infrastructure as Code" but it was used to define mainframe resources for jobs to use when they ran?
Re: DevOps is broken
#354I'm not sure if having two teams is always going to be better than having one DevOps team, but my experience in having two teams is that it's rare to have the incentives aligned. The author of the post pointed out that dev teams will cut corners and throw broken applications over the wall to ops to deal with. When ops gets woken up at 2am because someone in dev cut corners, what happens? Does dev feel the pain? Almos…
Re: DevOps is broken
#355Earlier quoted context omitted.
"anything else not happening on a developers computer which they should control but wont" Ok, I've seen this, but IME (24y in industry, the last 6 as a consultant) in the vast majority of cases, it's more like "things devs should control but CAN'T [bc CICD etc are silo'd and owned jealously by an overburdened ops team unable or unwilling to facilitate self-service]".
Some of the 'jealousy' may also come from bad experiences. It only takes a few instances of people royally messing stuff up in production for their deployment rights to be stripped away – and other groups catch the fallout too, as new "procedures" get implemented.
Having something not work during the development cycle is annoying for one person or a team. Having something break in production usually means people get paged and (depending on what you do) the resulting issues can have major societal aswell as economic impact.
In the ops world, this is especially visible if you go further down the stack. (from applications down the the network).
Network architecture moves at a toad's pace compared to webdevelopment, which is a good thing considering breaking the network will usually break every other system inside a IT department/landscape.
Re: DevOps is broken
#356Earlier quoted context omitted.
"Sysadmin" got rebranded as "DevOps", because "techsupport" got rebranded as "sysadmin".
Yerp. As a former *nix admin, around the time that "DevOps" became a term, I read it as "system administrator, who also now has to fix developer code." Which, honestly, was already part of the job at a lot of places I've worked, owed to the age old problem of people who "test" something on their weird personal desktop environment, then hand it off and shrug off any questions with "well, it works on my desktop". That…
This reminds me of a joke my networking collegues used to tell to the new hires.
Welcome to the networking team, where we are responsible for the network, aswell as anything that runs on the network because developers never bothered to pay attention in their networking class.
Re: DevOps is broken
#357Earlier quoted context omitted.
To grossly oversimplify, there are essentially two views of DevOps. 1.) What's probably the traditional view which is breaking down the walls between devs and ops, developers carrying pagers, etc. I.e. at least in an idealized world, there are no devs and ops--only DevOps. 2.) As you suggest (and which probably more closely matches how "DevOps" works especially in larger organizations), an internal (or external) oper…
3) The way I first heard it described years ago, bringing developer practices into ops: version control, testing, code reviews, continuous integration, etc
In my opinion, this last subset just doesn't work well for a lot of branches of operations.
Sure, it might work if you run stuff in AWS and have an operations team managing that, But what if your team is responsible for things like Storage Arrays, networking equipment?
Doing continious integration and code review on some of these is hard if not impossible
Re: DevOps is broken
#358Earlier quoted context omitted.
I totally don't want to do operations work. I've done some, and it feels like reading an arcane text in another language. I've seen the thing I want before, so I know there exists a magical YAML incantation that brings it about but I have no idea how to even start looking for it. It devolves to an extremely slow feedback loop of "did that work? No." I've never found anything that explained how I'm supposed to create…
Can't the exact same argument be made for code, though? "That didn't work, and the traceback (if I read it) isn't very helpful. Guess I'll try something else I found on SO." You learn ops by doing it, preferably in an environment where when you inevitably do it wrong, it doesn't break prod.
Starting in development requires a laptop. Starting with operations requires a datacenter worth of hardware and applications.
Re: DevOps is broken
#359Over the last ten years, the market has tried to kill off the hardware, systems, network and security people, and mostly succeeded. As a result, it's relatively easy to find someone who advertises as "full stack devops" who has never actually operated any infrastructure more complex than a LAMP webserver cluster. And it's hard to find a senior sysadmin who has enough years of experience to understand and troubleshoot…
In my experience, people who want to do interesting work on networking and systems. (Think, building large scale networks and systems with high resillience) dont want to work for smaller companies anymore.
They either work at:
A) highly specialized companies which fit their niche. (ISP's or IXP's for instance).
B) do consulting and project based work for a lot of companies who have very specific requirements. (Think, building a identity provider system for a country etc).
Small scale complexity has been disappearing because everyone just throws hardware at the problem instead of thinking about how to architecture their infra "correctly".
Why optimize your OS's scheduler parameters to get more performance from your filesystem when you have nearly free VC money and a budget to burn on resources in AWS?
Re: DevOps is broken
#360Earlier quoted context omitted.
I think that was not mentality. Maybe after years of working that way it turned out into mentality. That was employee utilization approach where you hire 1 DBA and he runs all DB stuff because hiring DBA for each team does not make financially sense as there is not enough day to day work for DBA specialist on a project/product. Other stuff is that DBA/SysAdmins have to have access to customer - company data so you st…
Good things happen when developers are involved in Ops. Most developers would prefer to develop and not focus so much on Ops, and so they take the steps to automate the Ops as much as possible and essentially make the problem go away. Dedicated Ops staff won't do that because that would put them out of work.
I highly doubt ops will ever go away considering someone has to think about maintaining stability in a production environment. This is usually a different way of thinking a lot of developers are simply not aligned to do.