Slashdot Mirror
Most Organizations Are Not Fully Embracing DevOps (betanews.com)
An anonymous reader shares a report: Although many businesses have begun moving to DevOps-style processes, eight out of 10 respondents to a new survey say they still have separate teams for managing infrastructure/operations and development. The study by managed cloud specialist 2nd Watch of more than 1,000 IT professionals indicates that a majority of companies have yet to fully commit to the DevOps process. 78 percent of respondents say that separate teams are still managing infrastructure/operations and application development. Some organizations surveyed are using infrastructure-as-code tools, automation or even CI/CD pipelines, but those techniques alone do not define DevOps.
Most of our infrastructure/ops guys are in-house, but most of our development we send across the ocean.
Equivalent of saying marketing and business operations need to embrace each other as one. Yes there should be synergy and commonality, however they are different fundamental areas of expertise. Dev Ops should favor cooperation and collaboration not one person to do it all.
... a developer should be modifying production code?
Hulk SMASH Celiac Disease
Why do they HAVE to commit to DevOps methodology?
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I've literally never seen DevOps implemented in a way that's actually beneficial.
It's consistently just a way for bad management to cut budgets by getting devs to do ops work badly, or ops to do dev work badly.
Even where that's not the case, it usually just ends up being a way for ops to fob their work off onto dev whilst not giving them the tools to actually do it like giving them the admin access they need to install/configure something wasting everyone's time.
I've even seen agile work and be beneficial more times than I've ever seen devops to be a beneficial thing. Like agile, it's just another fucking cult of nonsense most of the time.
Devs and Ops already have way too much to learn, that's why they're specialists in their fields. If you get devs having to learn how to manage networks and servers it just means that's a whole bunch less framework they're able to learn away from being able to do full stack. Similarly ops have way too much to learn in terms of software and hardware configuration to be able to learn to program properly. If both fields were simple jobs with fuck all to learn then maybe there'd be benefit to it, but forcing each other to learn more than they already have to in their respective fields is a guaranteed path to failure.
"Dev-Ops" is just another buzzword for "do more with less people".
Dilbert already covered this
and this story is correct in that we haven't completely embraced DevOps. Our dev and DevOps teams use Agile so there's a ridiculous two week minimum delay for any fix since you have to add the JIRA issue to a new sprint before you can fix it. Agile doesn't work well with things that must be fixed for customers. Even worse is since most of our developers are on four scrum teams, they have four stand-ups per day where they need to talk about what they've accomplished and what they commit to doing before the next stand-up. Actually getting work done has suffered since you need to do something superficial each day for four times each day.
Most organizations are fucking clown shoes. Upper management thinks that the best people to manage software engineers is by promoting program managers into people management roles. The inmates are running the asylum. Most organizations are a disaster that only looks good on paper to the bean counters.
Unless you want to avoid a #METOO tweet about your groping hands!
Since there's no accepted definition for what "devops" really is, and no part of it is new anyway, who cares? Other than companies which want to charge consulting fees for making you buzzword compliant, that is... which is the true purpose of stories like this, to create a fear of missing out among clueless managers.
The OP and article imply that this IS a problem.
It's not.
The only reason why it's not working is because you. It's your fault.
Fortunately, we can hire consultants to help you.
---- The above post was generated by the Turing Institute. Maybe.
Lets do it with Rust React Electron AI and CloudBlockchain and dont forget to follow me on le Reddit Discord.
Ok - so here's the thing. Developers should have a firm understanding of OS maintenance, firewalls, networking, security, and all that good stuff. Operators should know how to code. I wouldn't personally hire a developer whose workstation was a disaster area, and I wouldn't hire an prod-level operator who didn't know, at least in passing, a few languages.
But this whole "devops" thing is kind of a joke when you get to the enterprise level. The goals of developers and operators are simply different, and the stakes are way too high to encourage those who write the code to also run the code.
On the other hand, if you're a small team / company slapping together a simple web site, multitasking may simply be a necessity.
A government is a body of people notably ungoverned - AC
Is the ones who decree a switch to an agile development process, but still want waterfall style year+ schedules.
Am I the only one to whom This whole thread seems somewhat like reading a transcript of the Mad Hatter's Tea Party?
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
Most orgs are barely keeping the lights on as it is and simply do not have enough horses to pull those wagons.
"Tempers are wearing thin. Let's just hope some robot doesn't kill everybody." --Bender
When I interview for a job and management thinks that "DevOps" means you are doing development AND operations.
Nope.jpg
Sure, operations does development; but I do not work on your dev team developing your application. People in "devops" are admins who know how to code and script; they automate the pipeline between dev and operations. If you dont know this and are management in "devops" then you should be fired.
Public companies that are audited for Sarbanes Oxley compliance have to show separation of duties when it comes to changing systems that are material to the business. The easiest way of conforming is not allowing people who develop code to deploy it into production. That is the biggest obstacle to going full DevOps in public companies.
Having developers as operators leads to problem. Can I simply say Sarbanes-Oxley and see how many internal legal and HR departments will go screaming at any fool who things that combining operations with development a good idea. ROFLMAO. This is how it use to be years ago. There are GOOD reasons why we got rid of it.
Given how eager corporations are to hire the least expensive people, it would be surprising if they embraced paying for people with both developer and operator skills.
And "buy one, get one free" just doesn't work here.
We've hired nearly four hundred developers since I was hired. None of them have access to QA environments much less staging or production. Those unexperienced devs have made some improvements, but mostly they just screw things up. I wish I got paid as much as some of them.
Devops has it's place for in house development where produciton and infrastructure are linked. There it is an effective and efficient way to go from Dev to test and into production.
What does my head in is the number of vendors that we see that try to bring their devops mentaility in house for the applications that they provide. They expect that we have to mirror their development environment which is often an untested disaster over and over again.
My org doesn't even have Ops. We make stuff. You have to buy the stuff and carry it into your data center and plug in a hundred cables before it does anything. The CUSTOMER does that. Not me. Customers don't like it when randoms from the equipment provider start rewiring the data center. (duh)
So my multi-billion dollar software outfit definitely isn't doing what this article says, and never will, because their vision of Ops is really limited. (seems to be for web sites?)
On the other hand, we have an awesome tool chain with hundreds of engrs comitting thousands of commits per week all to master, with 4-tier regressions for every check-in, and it WORKS.
Keeping that shit running is what we call Ops. Keeping the build farm going so you can spank out a couple custom Linux kernels in 10 minutes, etc. is Ops.
So yeah, do don't do "DevOps" like this article says, because we don't do Ops. But we do. Just not the way they imagine it.
Usually bullshit like this catches on and we're all worse off for it, so wow, cool. I've mostly avoided these guys - basically scam artists selling something not needed.
If the IT department has more then 20 people, it is foolish to use DevOps.
Good to see there are still 20% of the companies NOT managed by idiots chasing fads.
I build the train, I drive the train. Occasionally it breaks and I fix the train.
davecb@spamcop.net
That's why DevOps works best with The Cloud. Let them deal with all the hardware. You deal with the software.
DevOps much like security is a process.
https://docs.microsoft.com/en-us/dotnet/standard/containerized-lifecycle-architecture/docker-application-lifecycle/containers-foundation-for-devops-collaboration
Coming from a UNIX background back in the day, I've never cottoned to "devops". The whole thing is gay. A programmer should code, and the sysadmin should do his job. Now? If you're a sysadmin and you write some Python or Perl or whatever, suddenly you're a "developer". Hardly. In the real world, I stick with the UNIX mantra that has served me well for 20 years: "A program should do one thing well." Coders should code. Sysadmins build and maintain servers and other resources. The two don't mix real well. I can do it all, but I prefer sysadmin duties. I often write shell scripts to get something done, but I'm only leveraging the tools the OS already provides. I'm not a developer. I will not work for a place that tells me I have to code full time. That's not what I do. Likewise, I don't want the developer in our shop tinkering with my servers. He has no clue what to do outside of running prototype code on the development servers. Do one thing well.
Why is this post even posted. DevOps is dead.
3 Options:
1. Take a developer, and halve his productivity as they now have to be "ops"
2. Take a developer, and halve the quality of the code, because "uptime" matters, not performance
3. Take an operations guy, and have him write crappy code
Cross-training is ok, but ops should be ops, and dev should be dev.
I know plenty of developers, and even more operations / administration people.
The skillset for one is not necessarily applicable to the other.
Some of the best developers I know, I wouldn't trust them to set up a basic PC for me, I've seen the mess they made of theirs. Some of the best operations people I know can't write code that's anywhere near the quality of a full time developer, but they can definitely set up a secure firewall, or configure a bunch of servers to work reliably.
Specialist Mac support for creative pros, Melbourne
As a developer, I "get it" that writing code to roll up VMs, firewalls, and so on results in repeatable software. But honestly, it's boring. I hate writing code to create Amazon EC2 instances on the fly, etc. I wish I had an Ops staff to handle these tasks.
When the only tool you have is a hammer, everything looks like a nail.
If you're a programmer, you naturally want to use programming to configure systems. But that's not always the best way to do it. There are other, better tools for general-purpose system setup.
If you have to configure lots of systems in exactly the same, or similar ways, DevOps might be good. But for systems that are one-offs (and there are a lot of them), not so much. The benefits of automation isn't worth the cost in these cases.
DevOps steps on too many other toes. At Kauli the DevOps team deleted the test teams work to create automated test envs for developers to insure DevOps remained in control.
Devops Devopping devops, only LUDDITES don't devop their devops!
> Automagically usually means no peer review
We used the setting in GitHub to automatically require peer review before a change can be merged. That's the only reason we now have peer review consistently. It was spotty until we made it an automatic requirement.
DevOps initial aim was indeed to have Dev and Ops working hand in hand using the same workflows and development techniques. The article is spot on. Unfortunately, "DevOps" engineer nowadays is more often the new name for "Sysadmin who does some automation". The "I do some Puppet, I am DevOps" syndrome.
I see so many people complaining about devops and I don't understand why? "Herp Derp developers writing code in production" - no dumbass, that has nothing to do with devops. Devops is just your ops guys using developer tools to streamline testing and deployment.
Tools like Docker, where your entire platform is defined and described in a configuration file. All the required firewall ports are clearly stated, the number of replicas of each deployed service is clearly stated, the build process is clearly stated. The whole thing is just so fucking ops friendly it has nothing to do with developers writing production code. If you don't even know this much what the fuck are you even doing in this business anyway? Get out you archaic pieces of shit.
We don't have ops, and we hired a "devops person" (which is stupid and defeats the whole idea of devops) and they have neither a developer or an ops background so when they're not breaking things, or manually tweaking server settings (which they will forget about) they are trying to learn automation and config management in the hopes of one day reaching sanity. Never mind that we already had an existing configuration management system working everywhere, but it was "too hard" and so it was abandoned for the hopes of this person learning a new shiny one while everything is on fire.
Does anybody agree on what devops actually is?I have worked both as developer and as system administrator for many years, and I can see the need for somebody who knows both functions well. Developers often don't really know how their code is used in practice, and leave out things like good logging and debugging options, good, technical documentation, good monitoring interfaces etc, and sysadmin staff normally don't know much about how code is written and built. This results in poor or even hostile relations between the two branches of the organisation, and that is where you need the devops person: somebody who really knows both sides well, who can earn the respect of both groups and can guide the cooperation between them. Or, that is what I think devops is all about.
Unfortunately, to most if not all managers, devops sounds like something, where you introduce "automation, whatever that means", hire people with the skillset (and importantly, the price) of 1st level supporters + a bit of python coding, and then expect them to be able to understand development in full, because of "automation, ...". Remarkably, this doesn't seem to work as expected - perhaps what they need is to find somebody who has at least 10 years experience with the latest tools.
You know, it is sad, really - devops could be such a useful role, and it could benefit the organisation a lot, but only if managements begin to take it seriously, starting with the price tag: if you expect people to master two difficult skillsets, you can't get away with paying less than either.
DevOps is not about devs doing ops work, it's not about a dev installing a server, setting up firewall rules by hand with iptables and managing the disks on the server. It's about enabling devs to do their work without depending on ops, among other things. The whole devops movement is based on the CLAMS model, where the 'C' stands for Culture, and it is an important part, because without a change in mindset, you will mostly never succeed on implementing devops. It's also the most difficult thing to do, changing peoples mindset takes a long time.
On a long enough timeline, the survival rate for everyone drops to zero.
The article talks about having clean automated processes to handle builds and deploys and that many company still do it manually. That part is right, it should be as automated as possible.
The second part though, where DevOps and App Dev should be one team is wrong. In many organizations that I've worked there was a compliance requirement for a true separation of duties. Developers could alter code and check changes into GIT. They could fire off Jenkins jobs to build/deploy to Dev environments only. They could put in merge requests to bring branches into the mainline.
Senior level development staff - architects, sr developers - would review and approve the merges and the changes would merge to the production build lines.
At that point only DevOps could trigger the builds and deployments into upper level lifecycles. If QA detected problems, the development team would use the monitoring tools like Splunk or ELK to review logs and identify issues, the did not have physical access to the QA boxes.
So the two points need to be separated out, automation is right path, combined teams is not necessarily correct, depending on type of business.
Oh noes! Whatever shall we do?!
Sounds like the marketing ramp up to a lucrative round of “DevOps and Why You Can’t Live Without It” consulting gigs.
Most don't need to. DevOps is this newfangled thing that happens when you've got your pipeline optimized so far that a handful of experts can code, deploy, upgrade and maintain your appstack all at the same time, while sipping lattes and playing a round of foosball inbetween. When orgs have gone "all cloud", then DevOps is a thing that basically happens automatically. But don't expect a regular old-school company going there. It's avantgarde startups doing this, and they, in the end, might end up replacing the classic companies - see the bets on fintech stuff as an example.
It would be silly to expect than 150 year old insurance company to get what DevOps even means without knowing the context, let alone implement it correctly (along with the move to cloud) and ditch all the heads that get lost in the transition. It's way more likely that CloudInsuranceCompany Inc. will come along and eventually replace them as a company in whole. ... Probably even funded by the same investors that made money off the classic company.
Outside of an organisation going all-cloud from the get-go, DevOps is little more than a fad and a buzzword that gets thrown around. Sort of like this "Agile" sillyness where 3000+ headcount orgs suddenly want to go "AGILE!" and implement Scrum across the board right down to the cleaning crew.
My two Eurocents.
We suffer more in our imagination than in reality. - Seneca
Anybody who has worked in any real software company with real projects and real life infrastructure knows that you have to keep the live environment and the test environment totally separate and the development team can't have any influence on the live environment in any way. Faster and more deployments on live systems only means more chances for failures and bugs. If you need rapid changes to the live system then obviously you haven't designed and planned the project before hand. Any automatic deployment to live system without any manual supervision is a disaster waiting to happen.
Handling outage on production caused by code defect:
2 support people @ 0.5 hour
2 ops people @ 1 hour
1 developer @ 1 hour
1 mid-manager @ 0.5 hour
1 exec @ 0.5 hour (to keep asking what's going on)
Total: 5 man hours during the incident.
The after incident review is roughly the same, including preparation time.
Grand total: 10 man hours
Peer review: 1 developer @ 0.25 hours
Where I'm from, 0.25 is less than 10.
Peer review is one of the best ways of "gaining speed and reduce people needed".
That would be serverless (yeah an oxymoron).
https://www.martinfowler.com/articles/serverless.html
https://thenewstack.io/tag/serverless/
Because there is always one best way to do things, regardless of scale or domain!
I guess part of it comes from HR evaluating interested candidates at a job fair, wanting new graduates' skills to scale from trade school/university scale and domain to enterprise scale and domain. If some best practice can be shown to work at small and large scales, trade schools and universities ought to be teaching it.
what is ill conceive and what has that to do with my demand that developers have basic knowledge about installing/administrating a linux box?
The fact that you can't easily find a PC warranted to run GNU/Linux in North American showrooms. Buy an Android device or Chromebook, and you get Linux but no GNU (at least until Crostini becomes stable). Buy a Windows 10 PC and install WSL, and you get GNU but no Linux. Instead, one ends up playing hardware support roulette if buying a laptop or losing the ability to use it while riding transit if building a desktop from parts.
But then it wouldn't have made it onto Slashdot.
Still, I always enjoy seeing Ops guys talking in acronyms and trying to explain things.
"See, the CGR/UPX used to do the job of the BYX/KbW but now everyone uses GTFO."
It's like watching two '80s valley girls talking to each other. Fer sure!
strcat("Dev", "Ops");
I agree CONSISTENT style is more important than any specific style choice. Whether you want to coddle your braces or not, pick one and stick to it.
On our team, we have a Git hook that runs an appropriate *-tidy, so when code os committed it's automatically formatted according to our team's standard for whichever language, which is generally the same as what most people use in that language. Write code using any formatting you want - it'll be automatically be made consistent before other people need to read it.
Nothing more. No wonder it has so many frauds who love it
Because the worst possible situation, for everyone, is that the file has a random mix of PascalCase, camelCase,.lowercase, and under_scores. Every time you use an identifier you have to look at which casing is used for each identifier. Choosing ANY formatting style is better than not choosing one. Better for everyone.
What the fuck is devops? Cmon editors, do your damn job!
Yes, the developers absolutely should be on the support team answering phones and talking to customers while they code.
As a matter of fact, they should be running database backup jobs while they're at it. If anyone feels they lost a post or something, they should go back into their code and change some lines and test it on production to get that post back.
Have you accepted DevOps as your personal lord and savior today?
The DevOps buzzword exists to sell Microsoft products, training and certification.
The concepts of DevOps predate Microsoft's buzzword sales pitch by 20+ years.
Sarbanes Ox regulated financial software at USA firms would not be able to shorten the code push from developer desktop - QA - UAT - Pre-Prod - Production deployment cycle due to regulations.
The regulated software encompasses nearly all of the accounting and financial software used at large corporations and systems feeding into those financial systems.
Microsoft's marketing material, sales material, and technical marketing material (blogs, white papers, how to, etc. conveniently ignores any form of Sarbanes Ox regulations and business data retention policies (outside of brief mentions in SQL Server and Exchange admin documentation).
Vendors have a vested interest in churning new software and forcing upgrades to be on the 'latest and greatest' to make money for the company and consultants.
Fact: Data retention/Sabanes Ox covered systems get much longer support life cycles from MS than do other systems. .net Core 2.x released recently has a 3 year support lifecycle.
SQL Server 2005 and 2008 have 10+ year support lifecycles,
Vendors are pushing for forced upgrades, short support lifecycles and products that are perpetually in beta.
Business document retention regs in the USA are 7 years which is half of the support lifecycle of many core Microsoft development tools and open source libraries that MS brings into a project.
Sure it can be that. This is true of a lot of things. The building blocks may exist on their own, often under different names in different orgs and then somebody comes along, unifies it under one name, publishes a paper or talks at conferences or whatever and suddenly everyone uses the one name.
As people have said on a good dev team there would usually be a "Unix gnome" to translate. That same org may have had automated deployments at least in some teams. Now that DevOps is a word they realize what they've been doing can be called "DevOps" and they do and they might add the "missing" pieces too.
that solves every problem. Big companies wouldn't be able to manage 100s of DevOps teams. Plus DevOps and DBs is still a complete mess, Big Data and DevOps still need to figure stuff out. That 50 year banking system doesn't need to be made DevOps.