Video DevOps: Threat or Menace? (Video) 65
Alan Zeichick: I'm Alan Zeichick. I am principal analyst of Camden Associates. Before that, I was the founding editor of Software Development Times and I've been kicking around the software development and networking in IT space as a technology analyst for about 30 years, and before that as a systems analyst.
Robin Miller: Thirty years. So, you're still practicing, right?
Alan Zeichick: Oh, I keep practicing. Someday, I'll get it right. And yeah, I started out in the mainframe era, IBM 370s. That was my life. And when those little PCs came out in 1981, I thought, gosh they're just so darn cute. But wow, they've gotten pretty powerful since then.
Robin Miller: Okay. So, here we are now. And one of the hot things and all of the hot stuff for hot, hot people talk hotly about is DevOps. DevOps, threat or menace? Which is it, Alan?
Alan Zeichick: Oh, it’s both. DevOps is funny. It evolved or one of the ways it evolved is that companies wanted to start developing in the cloud and deploying in the cloud. Not necessarily both, they might want to develop in the cloud, deploy in the datacenter or vice versa. Their traditional op-staff didn't understand the cloud, you know things like Amazon Web Services or Google, or so on, and Azure. And so, the dev people started to try to deal with those services themselves and they often made a really bad job of it. They didn't understand security, didn't understand reliability, scalability. It was perhaps okay when they were strictly developing software. When they wanted to start deploying, it was a disaster.
So, the DevOps discipline started in good part in that direction, trying to bring the ops people into kind of be the grownups in the room, to deal with – to deal with the twenty-something developers who are really, really great at Scrum, but didn't know anything about old secure logins. And ever since then, it became kind of the hot topic that the thinking that the dev people and the ops people should be all working together all the time, kind of like a peanut butter cup, you get your chocolate, you've got your peanut butter. Let's put them all together and wow, no more silos, everything will be just kumbaya, that's where it all started.
Robin Miller: It also sounds a little bit you're saying that you have the grownups from the business side, keeping an eye on, babysitting the young, unruly developers. Yeah.
Alan Zeichick: That's a big part of it. The operations apartments, the data center people, the people that we usually call IT and the developers are IT also, but for some reason, they don't usually get lumped into that. the traditional IT people are by their very nature very conservative. They emphasize and they care about stability most of all. What they dread is a crash or a breach. They know that they're responsible for keeping the entire business running. Security is huge, reliability, scalability. They’re basically like the manufacturing part of the information technology. They have to keep up working. And so they're often quite scared by what they see coming out of the developer department.
Now in the old model, the developer people would take the almost finished or finished application, throw it over the wall to IT, who would then run it in a lab, make sure it was safe before putting it into their data center. In the new cloud model of course, that is not the case. And so the stuff is out there running again. Amazon or Azure or Rackspace, whatever it might be and what happens is the Dev people throw the keys to that over the wall to the ops people and say if you’re baby now, good luck with that. And again that just scares the IT people. They don’t know if it's secure, they don't know about the license agreements, cost negotiations, IT people are the masters of negotiating service contracts. I mean, that's what they do.
Robin Miller: No, no, I'm just laughing, it’s true.
Alan Zeichick: Services or to buy data backup, awesome. Developers don't know how to do that, they used to do licensing either using free software or buying a license on Visual Studio or something or maybe buying a license to a library for UI widgets and meanwhile they're signing up for these contracts, yeah, with all these same companies and the IT people just start screaming and say, we’ve been locked into some new mission critical application that the CEO loves when he saw the demo and says I want everyone in the company using this. And you signed a contract for this, so that's again the DevOps to have the operations people be the grownups in the room and hopefully get to have a little bit of say, now the DevOps has evolved past the cloud and is often included into applications that are going to be deployed in the data center or even mobile apps which go into an app store, they don't touch the IT departments in any way, except for maybe backend services, and open APIs.
But still the IT people want to have some say, they want to have a seat at the table. The challenge is they don't want to sit in that seat all the time, that goes back to your threat or menace. The DevOps vision is that the ops people and the dev people are all sitting around and you've got testers and you've got, you know, server technicians and the guy who runs the firewall and the person who negotiates contracts and they’re sitting around doing two-week sprints because they are on scrumshop. No, there's nothing that someone in IT wants to know about this application until it's almost finished. They do not want to see that this week's scrum is add a drop down menu that allows users to sort the columns in the spreadsheet. They don't want to see that. They're not engaged.
And so the theory is good that they should all be sitting at the same table all the time, ops people do not want to be going to two weeks sprint meetings. They don't want to be sitting there looking at milestone reports. They just want to say show us when you get to something that affect us, again like contract terms, picking a vendor, looking at licenses, looking at service level agreements, looking at how it’s going to tie into APIs that are hosted in our data center. Log in, this is going to be integrated into our management platform. Let's say the company has a single sign-in. The dev people probably don't know a whole lot about that. They just kind of assume it'll work by magic. The ops people manage single sign-ons. They’ve got to scramble around to make it work and make sure that it meets hard requirements if you're in a really big company and you’re going to deal with HIPAA or other concerns, it’s the ops people that are on the line, not the developers. So they want to have that seat at the table but they don't want to sit in it all the time.
Robin Miller: But if they're going to have the single sign-on and some of the security stuff, especially if they're working, dealing with HIPAA and such and privacy, isn’t it a good idea to have the ops people at least somewhat involved at the very beginning, security baked in, single sign-ons, security baked in instead of an add-on. That's what I'm thinking and I've heard this a lot. So, don't you want the ops people there at the beginning?
Alan Zeichick: You do, you want them at key stages, you certainly want them looking at requirements, remember a lot of agile doesn't really have written requirements. It's all this kind of what are we going to build next. And what’s the stakeholder asking us to implement next. So yes, that's what makes DevOps a great idea. The problem is that so – that it is in the beginning stages so dev focused, so the ops guys aren’t engaged. And also the ops people by their very nature are firefighters, they are solving problems, they work on trouble tickets, they are doing migrations, upgrades, bringing a new office online, upgrading the fiber, moving to a new _____8:47 to a cloud provider.
They are really busy dealing with the fire of the day. They don't have time to go sit in a regular meeting where perhaps only 5% of the content has to do with things that apply to operations. So that is one of the big challenges with DevOps is keeping the ops people engaged and also another big difference is developers are used to working in teams. You've got architects, you've got UI designer, you’ve got testers, you’ve got coders, you’ve got documentation people, ha-ha, in theory.
Ops people work as they used to say with the armies, an army of one. You've got the networking guy. You've got the firewall guy. You've got the guy in purchasing. You've got the lady over in troubleshooting, you’ve got end-user support. So it's not like you can have one representative of ops who could just sit in on that DevOps meeting or be part of the developer project, unless you are a big enough company that you could allocate permanent resources from ops to do that, but even there I’m not sure it works because that person will be by the very nature not connected to the day-to-day operations of let's say doing the migration to Windows 10 that might be all encompassing for that IT department right now.
So, as opposed to the developer team which is a team that’s coherent and they're all showing up to these meetings every week, they're all going to the code reviews. They're all going to the milestone meetings. It is the culture, it’s not just the cultures, but just the entire way they work is different, IT people don't work in teams. They might escalate something they can't handle, but they usually go out and they deal with things. They're very specialized and they deal with their own particular problem, which again is kind of weird for DevOps.
What about the cloud? (Score:3, Informative)
Re: What about the cloud? (Score:1)
I just assumed it was a way of differentiating the old IT guy who wrote hundreds of unmaintainable scripts to support his or her complicated web of ad hoc infrastructure from the new guy who understands sane development practices.
The old guy stopped learning IT in the 1990s. The new guy understands when you want to run your app in a docker container.
Bullspit (Score:5, Insightful)
DevOps is a specialization which used to be part of standard system administration. Developing custom tools to do custom tasks, in this case related to "Ops" (another specialty that used to be standard sysadmin territory). The term is a great dummy term, but really does not distinguish someone's ability to manage servers and infrastructure.
You seem to be the 'new guy' who preaches that everything should be run in a generic docker container, complaining about the 'old guy' who wants none. Meanwhile, most of the people worth their salt understand that sometimes generic works and sometimes it doesn't. If there was some magic perfect layout everyone would be using it. Instead, we have a huge array of both hardware and software being used in the market. Knowing a dictionary of buzz words does not make you good, and usually indicates just the opposite.
Re: (Score:2)
Re: (Score:2)
DevOps is a specialization which used to be part of standard system administration. Developing custom tools to do custom tasks, in this case related to "Ops" (another specialty that used to be standard sysadmin territory). The term is a great dummy term, but really does not distinguish someone's ability to manage servers and infrastructure.
Not in my job it's not. We're all full-time software engineers, and none of us have any sort of ops, sys-admin, or any other sort of "IT" background. Just as we don't have any QA people, and none of us has a QA background. We write, test, operate, and maintain the product the company sells.
It doesn't work as well as dispensing with QA did. If you're writing good tests, the only value QA adds is early customer feedback, but if you're running a web service that you can change when you want to, you can res
Re: (Score:2)
Re: (Score:2)
Or you take professional responsibility for adequate testing. No one need "matrix monkeys" any more, and when it comes to writing automated tests, software developers can develop that software just fine. What you miss is the "this works, but it's stupid" bugs. Those are a big deal in old-school, shrinkwrap software with multi-year release cycles, but if we do something stupid we hear about it the next week and deploy the fix the following week. If we have a blatant functional bug that escapes testing, t
Re: (Score:2)
Heh, I think this tweet is apropos:
https://twitter.com/NeckbeardH... [twitter.com]
2003: "I replaced you with a set of very small shell scripts."
2013: "I replaced your scripts with a six-figure enterprise DevOps platform."
I worked through some large companies trying to do this transition. They were literally trying to transition from a BOSS (bunch 'o shell scripts) repository to OpsCode Chef. The idea was that there were previously lots of Developer groups, throwing shit at a separate Operations group, and having us System Engineers in the middle trying to coordinate it all while also keeping the Systems Architects and other disparate managers happy. At
Re: (Score:3)
And on the same subject, hey, how about that moron Harold II, for not deploying his F-14 Tomcats at the Battle of Hastings? What a maroon, eh? Right up there with Pheidippides for not just pulling out his cell phone to call Athens.
You understand, of course, that the "old guy" wrote that mess of unmaintainable scripts out of necessity? And he quite likely hasn't just let his skill
Re: (Score:2)
I just assumed it was a way of differentiating the old IT guy who wrote hundreds of unmaintainable scripts to support his or her complicated web of ad hoc infrastructure from the new guy who understands sane development practices.
Yes, and no.
The 'new guy' is finding a way to take all of that scripting, making it consistent and maintainable, then using it in a way to automate the shit out of as much as possible.
Many of the results are apparent even now - CI/CD that can (in competently-run cases) remove the need for outage/go-live windows just because somebody wants to patch something or add a feature. Need 30 new servers to bolster the web farm? No problem - less than 30 minutes later, there they are - running and identically configu
Re: (Score:2)
Re: (Score:2)
DevOps is like SpecOps for IT guys, you know the elite operators that played lots of Call of Duty.
Re: (Score:1)
"DevOps" is not one guy. It's bringing the right people together at the right times. During development you'll need to bring in one Op from every speciality, until they no longer need be involved. There are stages to this also: requirements phase, development deliveries, environment installations, support during testing & QA, troubleshooting, production deployments, troubleshooting, upgrades, etc. Coordinating IT people is too alien for most PMs, so one designated sysadmin from IT best suited to such wo
Meaningless Bullshit (Score:5, Insightful)
Devops has also been used to give them impression that system administration can be abstracted away as some kind of quasi-cloud-development thingy. That is not the case nor will it ever be so.
Re: (Score:2)
Maybe I'm in the minority here but in most of the shops I've worked in over the decades where the IT dept did a lot of programming most of the folks did both dev and ops although nobody called it devops back then. A pure-sysadmin in a large organization is basically a computer janitor. Without some dev skills you're not going to be able to automate anything hence you're going to be reduced to doing the chump work that somebody with dev skills has already automated. Literally "I will replace you with a small
Re: (Score:2)
There have always been two sorts of sysadmins.
There are the guys who love the hardware, and the guys who love the scripting. Most admins did both, of course, but you could usually tell which side they tended to come down on.
Now that the hardware has been abstracted away in the cloud, the need for hardware admins in businesses who use cloud apps is much less, but the need for automation is now through the roof.
You still need the guys who like playing with the OS and the hardware to work in data centers and
Re: (Score:2)
A pure-sysadmin in a large organization is basically a computer janitor who cleans up after the technological elephants..
FTFY
Re: (Score:3)
Devops isn't "ops people who code", it's "fire all the ops people, and make your software devs do that ops stuff too". It works about as well as you'd imagine - lots of automation, but the lack of real ops experience (and desire to do that for a living) really shows. And yes, you'd be on call - it's not devops if someone else has to wake up if you break it. That's the whole point, really - one team that has to live with the results of their choices. It's less than ideal, but better than any approach tha
Re: (Score:2)
Well, this is a fine place to interject my opinion - for what it's worth... I'm not an authority (obviously) but I did manage to get things done and was successful at it.
First, this is absolutely horrific - not the subject but the process of watching this video. I've never watched a /. video before - I've read transcripts. This required so much effort to allow so many things in uMatrix that it was absurd. Between Disconnect and uMatrix I wasn't sure that I'd ever see the video. There were nearly 1000 reques
Re: (Score:1)
Re: (Score:2)
You write complete nonsense, the jobs a typical our day DevOps does did not exist ten years ago, definitely not twenty years ago.
So using this new term to describe those jobs is completely legit.
If you simply don't know what the difference between an operator, a developer and a DevOp is: read a book and stop insulting your colleagues who work in that area.
For starters: a dev op is not a systems administrator, however knowing a bit about system administration, noteable: more than the common developer, distin
DevOps my understanding (Score:4, Informative)
Hi! Happy Tuesday
My understanding is that DevOps was coined by a manager at Etsy who recruited developers for managing IOPs and other costs in the Amazon cloud via software designed to do just that. DevOps meant someone who was saavy enough to write system level code.
Somewhere along the way this notion got morphed into being the system administrator and the developer.
DevOps:
1. Developers optimizing Amazon and other cloud environment costs by using application code specialized to manage system administration aspects of the cloud; including managing switches, spinning up VMs, etc.
2. Developers with system administration responsibilities.
The reality is that Etsy moved off of Amazon to an in-house data center and left us with a messy legacy of a term, DevOps. :-)
Re: (Score:2)
This is going to sound insanely douchey (and I apologize in advance) but everything you have said is 100% wrong. At no point has Etsy ever run in AWS.
The only thing I can think of that might have had you confused is that John Allspaw (now CTO at Etsy) and Paul Hammond, presented at an early Velocity conference about work at Flickr:
https://www.youtube.com/watch?... [youtube.com]
That talk was pretty seminal in the DevOps community but in no way has any bearing on anything you said.
Dear Dice (Score:1)
No, I will not take part in your survey of whether DevOps is a thing.
IT people don't work in teams (Score:2)
>> IT people don't work in teams
So..that's the heart of DevOps according to this guy? More meetings?
DevOps, bad buzzword but good idea (Score:2)
In my experience, the term DevOps is thrown around by two types of companies:
- Startups who use it to tout their agility and fast deployment
- Large company CIOs who want to get rid of their sysadmins or abstract all the complexity away into the cloud
What I do like about it is the fact that, when done right, it forces developers to know a little about the environments their creations will need to run reliably in. As a systems guy, my experience has been that developers don't really understand how stuff they
Re: (Score:2)
The problem is that DevOps is used the same way Agile is (1) -- a magic bullet that will fix the problem of expensive sysadmins (2), expensive QA (3), production outages (4) and delays in deployment all at once(5).
1) does not exist, everybody knows that. And if 'agile' does not work for you, most people involved in it in that organization are incompetent
2) except: dev ops are not sys admins, hence they don't help in that area
3) QA is expenisve, and DevOps are supposed to help to automate stuff the develope
DevOps = ?? (Score:3)
Re: (Score:1)
I think you are close, but I have to disagree with a point you make. You want SAs in the loop to **develop** the environments and tuning: we want infrastructure as code where sysadmins document their wisdom and make it reproducible everywhere (in dev, staging, test, etc.): not by hand in only in production. Otherwise, we end up with deltas between development and production, which is a gap that can cause trouble and problems to creep up only in production.
This is where we start to close the loop on infrastr
Re: (Score:1)
I think you are close, but I have to disagree with a point you make. You want SAs in the loop to **develop** the environments and tuning: we want infrastructure as code where sysadmins document their wisdom and make it reproducible everywhere (in dev, staging, test, etc.): not by hand in only in production. Otherwise, we end up with deltas between development and production, which is a gap that can cause trouble and problems to creep up only in production.
This is where we start to close the loop on infrastructure and software engineering by instrumenting our code with metrics, performing forensic analysis with logs, and tracking health/uptime/performance with monitors. Otherwise, yes - handing off production to the system administrators to do their dark magick is the old way and it is NOT the DevOps way.
DevOps allows us to approach the problem where tuning and troubleshooting on your laptop or in production should be, as much as possible, a shared exercise with shared tools.
I'll go one further.
I'm a sysadmin and a devop, but at the end of the day, they build the app and I'm expected to keep it up. Devs will do crazy shit to get it to work (at all), but don't want to have to be responsible to keep it up after day 1, and that crap can't be trusted in production. So I do this:
I let them build it any crazy way they want, and I require them to document the process they used to set it up. If I can't reproduce it based on the docs they provide, it goes back to them. Once they have a
Comment removed (Score:3)
Re: (Score:1)
It sounds like you have many ingredients of DevOps in your experience, but none of the benefits because they seem to be a drag on your efficiency. You may be in the middle of a journey that you've yet to realize how to raise the state of the art in your own work, your team, and your software development organization.
My definition of DevOps is: DevOps is the process of removing all friction between the developer and customer value.
You need to treat friction as technical debt: file a bug and work on it!
Re: (Score:2)
Re: (Score:2)
My definition of DevOps is: DevOps is the process of removing all friction between the developer and customer value.
You need to treat friction as technical debt: file a bug and work on it!
Quoted for visibility.
Re: (Score:2)
Another c
Garbage IN Garbage OPS (Score:1)
Really? Lets add Special to the word Special DevOPS, there NOW I feel really important!
I FEEL the NEEED for a CERTIFICATE! YES! A 'Special DevOPS' Certification
Woo Hoo! Now I can really write code! Just look at my piece of paper, it says I can!!
Idiots.
And I'm an idiot for responding.
umm (Score:2)
So he is full of it. DevOps is not about ops engaging with devs. It's about making all devs part of ops. It's a model which existed in commercial banks and other places which could afford to overpay (a lot) to have people do work a few notches below the pay grade they are paid. But it's high stress and snail-pace progress. It reduces specialization which, by definition, makes experience less valuable. It puts all of the testing burden on the developers and removes testing specialists. In the most ext
Re: (Score:2)
DevOps is a culturally rendered term (Score:1)
There is so much misunderstanding because there is not a universal, static definition of DevOps that everyone can point to and say "that is DevOps" or "you are doing it wrong!" This is because DevOps is ultimately defined by the capacity of the people who practice it and I think we can see (already in these postings) that many people do not have the capacity to define it.
The history of DevOps begins with the people who coined it: Patrick Debois and Andrew Clay Shafer's first discussion about Agile Engineeri
If not "devops" then what? (Score:1)
What the? (Score:1)
I travel the country installing automation software, training people, and doing this whole "devops" thing (gad, I hate that word). I post here for info, not cred and I post here to tell what I see from the trenches. I also post anonymously because the bit $company I do this for wouldn't like to have my (highly visible in devops cicles) name plastered around, as it affects them too. (