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.
Crossing the divide from Dev-Ops to DevOps:
At the heart of the divide between Dev and Ops are the very different needs and constraints of each organization. Traditionally their day-to-day lives are very different. So are their war stories. And so are the metrics that are traditionally used to judge Dev and Ops. Predictably, the two organizations can end up internally competing with one another over (among other things) resources and IT automation tool selection. Part of the driving force behind the DevOps movement is to reduce this unproductive internal competition. Even with the increased levels of trust and communication that DevOps fosters, IT Operations teams will still have different criteria for IT automation than their colleagues in Dev.
My company is considering implementing (or has just implemented) an open source configuration management tool. That’s great for Dev. But as far as I can tell my job, and my team’s job, is about to get a LOT harder
~ VP IT Operations
Dev loves Open Source:
Take configuration and release automation as example. Like so many other areas of enterprise software, many developers naturally gravitate to open source options. It’s no wonder that 90% of code in modern applications is open source – after all, open source provides developers with
- Immediate gratification: Just Google it! Choose the right key words to describe your situation and you might find a good match.
- Community: Don’t reinvent! Find out what have others done. Opinions and suggestions might be plentiful across your favorite user groups. Maybe someone has solid sounding advice. Maybe someone even has specific settings or scripts that they have used. If so, you might be in luck.
- Free: Enough said.
But while Dev is drawn to prebuilt open source components that they can then modify,
Ops has completely different needs including scale, stability, support, security and speed.
Let’s look at each of these in turn:
- Scale: It’s great that the code works in Dev and in Test. In Operations, I need it to work everywhere, all the time. And we need to add 10s of thousands of servers with no new resources.
- Stability: Don’t force me to rebuild my infrastructure to be stable in a production environment.
- Support: Someone, somewhere needs to be on the hook for this software, with enforceable SLAs. This cannot be left to chance. I need a phone number. Now.
- Security: Failure is not an option. Our financial future and reputation is on the line. We cannot allow our customers to become vulnerable due to security issues. According to a study by Forrester Research, consider:
- “One out of every 16 downloads of open source component requests are for a component with a known vulnerability.”*
- “31% of companies have had or suspect a breach in an open source component, gaining control over open source risks is essential to improving security.”*
- Speed: We need quick time to market and low total cost of ownership that comes from quick learning curves.
In the context of configuration and release automation, can we satisfy both Dev and Ops?
Yes. Here’s why:
A new generation of application configuration automation solutions have been introduced in recent years. (To be transparent my company, OrcaConfig is one of these). These solutions cater to Ops’ need for fully supported, central, secure control, ecosystem visibility, workflow automation and compliance enforcement – all at enterprise scale and without relying on open source, community driven scripts.
But what about Dev’s needs?
I will answer a question with two questions.
- Does Dev need open source?
- Or do they want the benefit that open source often brings?
If those sound like product requirements document (PRD) type questions, they should. In an era with tightening constraints on budgets and headcount, selecting the wrong tool based on incorrect assumptions is a major self-inflicted wound.
These next generation DevOps solutions provide Dev with application-centric modeling (after all it is all about the application), templated workflows (immediate gratification) and versioned full stack configurations (time and money savings) while providing accountable, knowledgeable support (community is great. Community and support is even better.)
While there are no silver bullets in the drive to DevOps success, my hope is that we can dispense with the open source “requirement” and instead focus on needs and results.
