I'm not a programmer, but I played one on TV before (j/k). I see the term DevOps being slung around more than ever now. I tried to hit up popular web sites for a quick rundown (Wikipedia), but I'm still a little lost. When I read the description, it seemed more like the community of programmers lost their way and "DevOps" is just the current buzzword/catchphrase for reigning them in and chaining the rowers to the galley oars instead of letting them roam free on the deck.
Does anyone have a good public Internet source that could explain how DevOps is different from normal programming project management?
Thank you. The RackSpace video you linked did clear up a lot of what I was thinking.
This is what I found from my CISSP notes which is marked as “good” as an explanation what DevOps is:
I understand how RackSpace is offering DevOps as a suite of tools to support development.
At first I thought that William's (@Badfilemagic) comments were overly snarky. I can certainly see in this video how the whole DevOps concept can be implemented extraordinarily poorly, resulting in the scenario William described.
After some thought, I understand why we need a DevOps buzzword to describe people that can do this. People with a blend of good programming, good systems maintenance, and good project management skills are not quite Unicorns (but darn close), have a LOT of very diverse skill to upkeep. I can imagine a person in this position spending a quarter to half their work time just doing skills upkeep rather than contributing to production.
I can also imagine conventional programmers, conventional maintainers, and conventional project managers who are good at their main job but not even mediocre at these other areas slapping DevOps on their business card, dragging the perception (and value) of the whole concept down. Which I think was what was contributing to William's comments.
Thank you for the references! I appreciate the feedback!
DevOps is a growing trend with companies moving away from legacy SDLC practices towards Agile development.
There is no single implementation, or a standard set of rules but the basic tenets are the reduction in size for code releases, coupled with automation of static, unit and dynamic testing to provide a reduced time to market for the code.
Because of the loose definition, or the unique needs of organizations, especially large, older institutions or organizations it is hard to pin down how to implement DevOps, and a cynical view as pointed out by badfilemagic is that more is being required of fewer people, and that really stems from a poor implementation.
Most companies that find success with DevOps have full-stack teams, or small teams that own, deploy and manage code that incorporates a wide variety of disciplines, which is difficult to achieve in large organizations, or those that are highly siloed and therefore less able to, or slower to realize change.
I personally have a role to manage our DevSecOps practices and ensure our policies and standards adapt to the changes being implemented in our company and that incorporates our security architecture, engineering and compliance practices as well. DevOps is a means to automate to increase production speed, but quality needs to be maintained and from a Risk perspective, the compliance, audit and security initiatives have to be implemented as well.
Industry research bears out that companies that adopt DevOps or DevSecOps are most successful, due to the enhanced competitiveness and shorter times to market - which makes DevOps very attractive to upper management and without understanding the required culture change and company impacting adjustments that are required it can leave a bad taste in the mouth of those who resist the change.
DevOps/DevSecOps is not bad or good but another way to approach creating software and managing operations.
At least I prefaced mine with "cynically"
DevOps, like agile, has its place. However, its place is not everywhere and trying to shoehorn it in everywhere has, in my experience, lead to more pain than progress.
I like aspects such as leveraging automation where possible, continuous integration, etc. There is also a lot of cargo-cult voodoo associated with it, but that's true of practically everything. Working in the "I ship a physical product" space again, I just like to grab the bits that can help increase product quality when executed correctly and then get on with my day. I have no "ops" responsibilties beyond making sure my own Jenkins server is running, and that's the way I like it
I totally get it.
At least I prefaced mine with "cynically"
There were moments watching the intro video that I cringed in the expectations that are being placed on people. I mean, why don't we really "cut the fat" and just have the production users do their own development and maintain their own server farms and networks in addition to being accountants, warehouse workers, etc.?
Thank you for your rundown.
I agree that DevOps or DevSecOps as a concept is sound. In fact, I don’t really see this as a new concept. It seems to be the same (a) Object Oriented Programming that I learned in the 1990’s; (b) Requirements to document and archive your code for later reuse or debugging that I learned in the 1990’s; (c) Project/Change Management that I learned in the 1990’s; except now we add a SharePoint-esc. repository for code to be posted and a virtualized environment coupled with “installer packages” (ala MSI-esc files).
It’s not very spooky. But because we’ve created a “buzzword” for it, I can see it being extraordinarily abused and poorly implemented in a rush to adopt something “new fangled".