DevOps has a mixed reputation. On the one hand, it is most often lauded as a positive cultural and technical movement that can facilitate IT infrastructure automation, help transform network practices in sync with SDN and NFV adoption and ultimately break down the traditional silos that separate developers and system operators. On the other, it can be perceived by some as basically a path toward more work for everyone, as well as an organizational shift with an unclear impact on security. How do you ensure that DevOps becomes a net positive for all teams?
Business agility and IT infrastructure automation: The fundamental DevOps challenges
One way to grasp the overall difficulty inherent in implementing successful DevOps is to compare today's enterprises with the Web-scale organizations that they're imitating. By aiming for DevOps innovation, a company that may still rely heavily on dedicated servers is essentially trying to move "at the speed of Netflix," as David F. Carr recently noted for Forbes.
Naturally, this ambition runs into some significant obstacles. For starters, sustainable automation practices are often missing, with teams instead beholden to previous script-based processes that neither scale nor empower the non-programmers on infrastructure and operations teams. Bottlenecks then emerge as everyone waits on programmer availability, compromising the ability to collaborate and continuously deploy as part of a would-be DevOps culture.
DevOps is indeed cultural and emphasizes shared goals across the organization, but it also fundamentally requires infrastructure automation to realize these goals. Pushing new code each day in the mold of an Amazon or a Facebook simply is not realistic without tools in place like QualiSystems CloudShell, which uses straightforward object-based design to automate multi-generational heterogeneous infrastructure environments and enlist both programmers and non-programmers.
"[D]igital businesses … need to put [software] into production faster, compressing the cycle of testing, staging and deploying software, as well as provisioning additional server and network resources as needed to keep it performing well," explained Carr. "Technologies such as virtualization simplify some of this, but automation and business process discipline are required to make it go faster."
Ensuring sustainable automation is just part of making DevOps work for everyone. Another component is instituting DevOps in a way that can overcome skepticism from both line-of-business employees, developers and ops teams. There are quite a few challenges on this front:
- Metrics for evaluating developer performance may change, plus engineers may have to engage more with other departments.
- Marketers, executives and others outside of IT may find more of their time tied up in discussing unfamiliar technical matters.
- Operations may be in for a huge change as the periodic releases of waterfall environments give way to much more frequent activity.
Skeptical attitudes and culture change challenges can lead to the creation of new silos or the unwitting reinforcement of old ones. Overcoming them requires strong tools as well as a culture that can move past common misconceptions about DevOps.
Shelving DevOps myth to enable better implementation
Writing for opensource.com, former Tripwire CTO Gene Kim looked at six common myths about DevOps, including the notion that DevOps only works for certain types of organizations (namely startups) and the idea that DevOps is strictly about infrastructure-as-code. DevOps has potential, but sometimes it does not pan out as initially intended because of these misconceptions, which fuels anxieties among employees.
For example, DevOps can be misinterpreted as NoOps, i.e., operations disappear entirely as developers take on more responsibilities. The reality is usually quite different. Many operations activities instead become self-service and automated, allowing them to be performed without prolonged wait times or traditional departmental siloing.
DevOps should also not be mistaken as a replacement for either agile methodology or the IT infrastructure library set of practices. DevOps is more like a continuation of agile and a complement to ITIL. Moreover, it shouldn't be put into its own silo as something that is only for working with open source software or virtual and cloud infrastructure. It may start with those projects, but needs to go mainstream to have the profound impact that it promises.
"DevOps can be misinterpreted as NoOps."
Successful DevOps can address a full range of infrastructure, as well as environments that feature applications outside of the LAMP stack most frequently associated with the DevOps movement. One of the risks with DevOps is creating new silos (i.e., between different types of applications and infrastructure) while trying to eliminate old ones. A solution like QualiSystems CloudShell enables DevOps for organizations with any type of infrastructure. All stakeholders, from developers to security auditors, can access the same environments to drive high-quality application lifecycles.
The takeaway: Perceptions of DevOps are diverse and evolving. It may be seen as a boon to organizational agility, a threat to stable processes or a creator of new silos, depending on perspective. As more organizations look to accelerate their application lifecycles, more work will need to be done on clearing up misconceptions about DevOps and ensuring that proper automation solutions are in place for all types of infrastructure.