Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
DevOps is about being more efficient. It’s about breaking down silos and removing traditional business obstacles that get in the way of just getting things done. It’s about enabling teams and individuals to collaborate more seamlessly.
None of that, however, means that DevOps is about turning your IT into some sort of “Wild West” anarchy, where anyone and everyone can just push code to production. That would be insanity.
One of the primary catalysts that started the DevOps movement was the frustration of developers trying to deal with an operational bottleneck. As developers evolved from the old-school Waterfall development method to the much faster-paced Agile, developers were able create better software more quickly. That simply resulted in a “hurry up and wait” scenario, though, because the Operations and IT infrastructure side of the house couldn’t keep up.
Fast forward a bit and DevOps was born. Since its inception, however, there has been confusion about what exactly DevOps is or isn’t. That might be a function—at least in part—of the fact that there was no “inception” of DevOps; nobody developed a thing and then rolled it out to the world with the announcement, “This is DevOps.” DevOps was an evolution that occurred organically and out of necessity. It meant different things to different organizations and was implemented in ways that were largely subjective and often not called anything in particular. Organizations were simply struggling to address challenges and coming up with solutions that worked.
Suppressing the Anarchy
Although traditional IT operations were the roadblock that sparked the DevOps movement, DevOps doesn’t mean developers get to simply do their own thing. I’ve worked in the trenches as an IT admin at a dotcom startup—I’ve experienced firsthand the disastrous fallout of a developer pushing untested code onto a production server, and I’ve witnessed the wrath of executive leadership when that happens and the proverbial “stuff” hits the fan. It’s not pretty.
No, DevOps does not mean eliminating Operations from the equation and functioning as an IT anarchy. You’ll note that DevOps is a very obvious portmanteau of developers and operations—implying that operations is half of the DevOps solution. DevOps is about developers working more closely and cooperatively with Operations—not developers bypassing IT Operations.
There are two components to successful DevOps: culture and continuousness. First, organizations need to shed the traditional mindset of separate siloed teams and departments and let individuals focus on working together in whatever way makes the most sense for efficiency and effectiveness. Empowering individuals to do what’s necessary to collaborate and get things done is a big part of DevOps.
The other component is continuousness. When developers adopted Agile and started producing code faster, they discovered that Operations was a bottleneck. When developers and Operations started working together more seamlessly, new bottlenecks were identified, and solutions were developed to automate as much of those tasks and processes as possible.
The ultimate goal of DevOps is continuous delivery—to continuously deliver new solutions and features. Rather than a lawless void where developers just push code out onto production servers willy-nilly, organizations adopt continuous development, continuous testing, continuous deployment, continuous monitoring and other tools that enable their teams and those developing solutions to do so with as little friction as possible.
