Mobile: DevOps for IT shops. Minus the upheaval For those languishing in the doldrums of traditional IT, DevOps-style development offers hope. Or would, if you weren’t too scared to try it. After all, as I’ve recently noted, there are all sorts of reasons to run screaming from DevOps. Your company is regulated! Your CIO is a jerk! Only startups can operate like that! None …
The dev part is where a thing get made for someone who needs it. Emphasis on the word need.
The ops part is where the processes of an "ecosystem" interpose.
Devops is one of the labels used in the long history of efforts to re-assign blame for failure, and I doubt this overall trend will die anytime soon, unfortunately.
Why don't you bugger off, Matt? It is Friday, nearly wine-o-clock and the last thing I need is your bullish, alpha-male DevOps buzzword bollocks to start my weekend. And guess what Matt? Your article reads exactly the same as all the DevOps articles that have come before; a load of twaddle that is basically fur coat and no knickers and of no use to anybody. I bet your company has job titles like "Thought leader" and "Evangelista" (the latter I heard on an OpenStack video). Please leave us alone. I am going home now to drink red wine and eat calamari. Yup! Red wine with seafood. People tell me it lacks class, but I suspect you, Matt, would call it "disruptive". Enjoy your weekend.
Agree with Bibbit's remarks there, mainly because the article is so heavily anti-IT-dept that I am thinking there is no understanding of how anything actually works and that you do this swish-swish-swish on your tablet and it automatically appears as a completed fully functional thing.
It is becoming increasingly clear that this whole 'DevOps' thing is entirely sponsored by cloud service providers whose number one enemy are IT departments. They seem to be (successfully?) convincing Devs that 'Ops' consists of nothing more than a pointy-clicky thing with 'make it so, yes/no/cancel' on it with nobody anywhere behind the scenes having to do anything because it's all automated, just needs a monkey to plug it in and we have loads of those.
Disclaimer : I have spent time on both Dev and Ops sides of this and while there's always plenty of sniping in either direction there's definitely a concerted 'anti' effort going on with these.
The problem is our dickhead CIOs lap up the rhetoric spouted by this twat and his ilk...
The real problem with "DevOps" is that it empowers developers who are - to be blunt - not engineers. They know how to code in a few fancy high-level frameworks, but things like security, reliability, resilience, performance, backups, DR, business continuity - they all get forgotten. Until it's in "production" having bypassed the traditional checks and balances, and then good old Ops/SysAdmins have to pick up the fucking pieces and actually make it work to an acceptable standard.
Additionally, if it's running on public cloud, the Devs' answer to performance issues is to just say "oh, throw more resource at it, it's designed to scale horizontally on public cloud", and you then point out that at the resource levels they require (because they can't interpret AWS instance sizing and pricing models properly), the product will be horrifically loss-making, and the company will be bankrupt in 6 months... And then the bastards have the cheek to call you and your colleagues "negative", rather than realists...
TL;DR - most Devs aren't competent enough to be trusted with "DevOps"
yep, while a large number of our devs couldn't code their way out of a wet paper bag anyway, even the good ones think nothing of scaling and throughput, or what happens if something goes wrong.
A recent project, they saw no issues at all with putting 80 transactions a second through code with only 1 processing thread, and a 60 second timeout on a backend service call. Even on a good day the backend is never going to respond in an 80th of a second.
I think thats the whole point of DevOps. To get devs to be part of ops and not a "throw it over the wall" mentality.
When devs have to think about deployments, updates, failover, load balancing etc etc the software they produce is quite different and much more ops friendly.
The definition of DevOps is a tough one though as there seems to be multiple versions. here is the flow.
1. Before DevOps - Dev and Ops and two separate entities, little if any collaboration (imagine as two circles not overlapping)
2. DevOps version1 - Dev and Ops working more closely and actively trying to improve the process. i.e collaboration. (imagine as two circles with a 20% overlap)
2. DevOps version2 - Dev and Ops in one multifunctional team but with clear distinct defined roles. (imagine as two circles with 80% overlap)
3. DevOps version3 - Dev and Ops are the responsibility of the same team which are essentially developers with more ops responsibility. Or you could call them Ops who also develop. (Image as either 2 circles with 100% overlap or one circle) This means the one team have full control and responsibility over the software. Doing things like using new tools etc can be done much more quickly and apps that are painful to deploy or maintain are changed quickly as its you that are affected by it.
We have some apps that are pre DevOps some apps that are version1 and some that are version3.
Also this is just my take on the whole thing so I may be wrong :)
I thought the point of DevOps was to split teams up not by their function, but rather by the projects they will be working on. So, everybody working on Project X will be sitting relatively close to each other, likewise with Project Y.
This may give individuals a better idea of what someone else working on the project is doing, instead of assuming they're crap at what they do. The person may also realise the quality of work they produce and how it affects those who receive it, and change their own working pattern accordingly so to produce better output. The problem with this is if two people are doing the same thing but on different projects, and therefore sitting in different teams, when one learns something that could have potentially benefited from this, they won't.
At least, that's my understanding.
Reds guards are coming in town, bringing the Words to follow... I thought we learned that from the 20th century: don't trust ideologies. Seems Hegel was right after all, we do not learn from history.
Devops seems to me to be the way large organizations try to mimic what make (most of) SME strong: the DYI spirit, the spread of knowledge (Devs knowing about servers and networks, IT knowing about development at least through scripting), and having people sticking together.
DevOps is what happens when the developer that wrote the shit code is the only one that has the login to the cloud services so he has to push multiple fixes per day because there are mutliple bugs because everybody is to rushed to do anything right. That, and nobody else understands all the super complex configuration settings that need to be changed so he has to push it from some custom script on his desktop (that eventually gets uploaded to a Jenkins server as a proof of concept that goes into production). I know, I'm that guy! DevOps isn't new, it's what you do when there aren't enough damn people on the team. This is the same reason I now have to call virtualized servers "a private cloud".
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
