Avoid These Common DevOps Pitfalls

Source – itbusinessedge.com

Virtually everybody is interested in doing DevOps these days, but more than that, there is tremendous pressure to do DevOps right. After all, the IT landscape is littered with technologies and initiatives that seemed to promise great things but, for one reason or another, failed to deliver.

When it comes to DevOps, the concept is solid – faster, more agile, development, lower costs, a better user experience – so the only thing that can really foul it up at this point is execution. And since DevOps requires not just a new technology but a new way of managing people and processes, there are many ways in which execution can spell the difference between success and failure.

According to The Enterprisers Project, there are 10 bad habits that organizations need to break in order to make a go of DevOps – most of them arising from the tendency to either overreach or underreach during the deployment phase. For one thing, organizations should resist the urge to achieve Netflix-style agility, particularly if the user base is not ready for continuous updates and patches. As well, failure to embed security as a core component can be a recipe for disaster. At the same time, however, DevOps will be marginal at best if organizational structure remains tied to traditional silo-based processes or if it is not accompanied by high levels of automation.

There is also a tendency to pursue an open source strategy when laying out DevOps infrastructure and architecture, says Olivier Bonsignour of software developer CAST. This is not a mistake per se, but sometimes the expectations of open systems exceed the reality, particularly when it comes to security. Open software is notoriously difficult to manage, with different versions often occupying different systems within IT infrastructure at any given time. This makes it difficult to test, leading to situations in which security can be vetted on some versions of the software but not on others, a vulnerability that hackers are all too eager to exploit.

It may also be tempting to deploy DevOps on new modular infrastructure while leaving earlier systems, such as mainframes, mired in traditional development models. This is a big mistake, according to Compuware CEO Chris O’Malley, since the vast bulk of corporate processing still takes place on mainframes and there is absolutely no reason why they cannot handle DevOps workloads as well. All that’s needed is the right software that can speak the proper syntax, which Compuware is working on under its Topaz platform. Sure, this will require changes to mainframe teams and processes, but that’s kind of what DevOps is all about.

But probably the worst thing to do regarding DevOps at this point is wait. According to new research from Redgate, while sectors like retail and IT services are out in front on DevOps, areas like government and education are falling behind. One of the biggest obstacles is a lack of awareness of the operational advantages that DevOps brings, cited by 40 percent of those deemed “laggards.” In many respects, this is the fault of DevOps systems developers, which tend to emphasize benefits to agility and flexibility over more tangible bonuses, such as improved compliance and higher worker productivity.

We are still early in the DevOps transition, so additional pitfalls are bound to surface as more organizations enter the fray. And in all likelihood, stories touting complete success will be few and far between.

The idea of DevOps leading to digital nirvana is enticing, but the complexity of enterprise architecture, and the lengthy history of technology innovations that have promised the same thing, argue strongly for keeping a level head for the time being.

Ultimately, the most effective strategy for DevOps is to start small and maintain a clear view of what success actually means to the business model.