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.