John Vincent on DevOps – excerpt E: Security & Borrowing from Solved Problems


This is my last excerpt from John’s podcast. Some good stuff!




Tom Parish: What about security – where does that fit in with DevOps – my mind was just going crazy when I heard you talking about APIs that talk down into hardware levels and more. You got to know, that’s got to give some people some sweaty palms, you know.



John Vincent:  Well, it does and here is what I think people are starting to realize: I know some security professionals who I would say get it, and that is by automating and codifying how things should be in some sort of programmable way, you take the risk of some misconfiguration opening you up to security vulnerability, or making an attack vector, out of the picture.



Tom Parish:  Now, how would that be?



John Vincent:  So, here’s the thing: if you know that every server needs to have XYZ and it needs to be configured this way to be secure, if you’re doing it manually, you’ve introduced an issue where someone might misconfigure and now you have security risk.



So my argument is that things like configuration management actually makes things more secure and by proxy you remove the need for people to actually be on a system.  Which is, you know, closing loopholes that exist and that needed to exist because people needed to do certain things.  And we as approach this concept of ephemerality, if that’s even a word, of resources when you have a compromised server you can easily replace it and go do your investigation.



It’s not a “stop the world” kind of scenario.



Tom Parish:  I see.



John Vincent:  You know, obviously there are some best practices you want to follow there…



Tom Parish:  Let’s move into that.  I mean let’s talk about that: DevOps best practices.



John Vincent:  Well, they’re rarely best or practiced!



            So I think the primary best practice of DevOps is not one that’s specifically DevOps and that’s the whole “Mr.Gorbachev, tear down this wall!”  but, it really is, the biggest best practice you can take away from DevOps, is that you need to have your teams communicate better. Regardless of what it is [they need to communicate].


So early involvement in any initiative, you know I talked about the gap when you hand it off something and you start to discover new things and it kills agility but early involvement can actually mitigate risks. If you have your operation team involved from the get-go of an initiative and communicating regularly with developers, it kind of ties into the security question. If your security guys are involved from the get-go, they instill and they can address needs before they become a systemic problem.  And the same goes for operations.  It goes for any other department.  The earlier you get involved, the quicker problems come to life before they’re actually released.



That’s the best practice and it’s not even DevOps specific. I mean some people rightly argue that people have been doing what we have kind lumped together as DevOps, for years. And they have. It’s been primarily contained to the situation where you don’t have as many people in the company or you have such scale that you have to do it.



I think there is this middle ground now.



Tom Parish:  How much of the best practices for DevOps is the definition of DevOps.



John Vincent:  Right and it really is.  It’s you know a definition of DevOps — even just the name “DevOps” — it implies this inter-team approach to dealing with IT.  And it brings to mind cooperation.  You know that’s what I think of and I think it’s no mistake that the first sort of — I won’t call it a tenet —  but you know there is a term called CAMS that people like to use that John Willis came up with.  It’s “culture automation metrics and sharing.” And that’s kind of what DevOps is but the first one is “culture.”


TomParish:  What would change in the daily role of a sysadmin or developer.  It’s kind of full circle from where we started but let’s talk about it from that perspective.



John Vincent:  So my background is obviously system administration and operations and I think I’m not going to word it exactly right but we go from being, I guess, assembly line workers to managing the machines or managing the code that runs the applications.  That’s what you see with the system administration field lately or at least in terms of how I see it shifting is: that you step up a level.



And it’s not a one-man show or you’re doing this one task. You’re codifying your knowledge and your skills in a way that things can do that for you.  So you become more of an overseer.  I don’t know if that’s quite the right word but as far as like say QA, it’s really the same thing.  People have already gone from manual testing to automated testing and multiple tiers of testing.



A QA professional will tell you that it’s not just QA.  And you know so they went from – they made this shift from being guys who would manually test an application to using […] programmable tools that automate that.



And they actually had to do some programming around randomizing data for inserting and things like that.  So, both of those department sQA has sort of already gotten there [and] systems administration as well. They’re moving more into being programmers in the generic sense, as opposed to being developers of specific product, of their environment. 



And for developers? It really depends on the industry. WebOps — web development is completely different than desktop tools development. There are artificial barriers there that will never go away if you’re talking about off the shelf kind of software versus a Web site. I think the developers are going to start coming back to [system administration].



It’s really interesting developers and system administrators diverge from the same person, in my mind, historically. Where the original folks who managed the system, were the folks who wrote the code that ran on the system.



And then somehow we had this split.  And it was “OK we need more stuff to run on top of [that stack]” but this one person can’t be expected to know it all.  I think that developers are going to start revisiting closer ties to how the code is running at a more micro-level with the system and that requires some operations knowledge.



I think they’re getting better full stack awareness.  In the end I think that regardless of what the specific department is, everybody is shifting up the stack a bit.  You know there’s still the underlying stuff and that becomes less and less of a burden and you still need to know how it works but you know people start shifting up – their concerns start taking into account more than just their domain. 


They’re paying attention to things that they might not have cared about before.



Tom:  It seems like very much a natural evolution.



John Vincent:  And you can look at any industry and see this.  I mean it’s not just IT.  We’re just taking – we’re almost re-inventing the wheel or rediscovering stuff that other industries have done before whether it’s resilient engineering. The airline industry has this problem and they’ve investigated what causes human error and we’re doing the same thing on the IT side.  And we’re leveraging that existing knowledge base. It’s changing, whether we look at biology or manufacturing.  You know we’re taking our cues from things that are somewhat of a solved problem.

Share This Post