Stop, look, listen: Don't be 2016's DevOps roadkill – here's how to survive
Harnessing software to topple bricks and mortar
Search the term “DevOps” online and you get a plethora of stuff. The problem is not lack of content – the problem is sifting the wheat from the chaff.
Navigating your way through can be both daunting and confusing. This in turn makes it a challenge to know where and how to get started.
Those purveying DevOps need to offer a message that’s nuanced and that provides flexible but proven methodologies with greater general support to address a broader range of application scenarios.
For those of us consuming those messages, we need to adopt the lessons of the Green Cross Code: stop, look and listen.
What is DevOps?
The need for this caution is important, given DevOps has such a broad and relative definition, and because of the different reception “DevOps” receives.
It’s good to start with an attempt to establish “What is DevOps?” In my view, it’s the concatenation of two role functions and workflow processes (Development and Operations) to ensure the stable, speedy and continually reliable release of software applications or functionality out into the field (or into production).
Of course, there is more to it than that. But as is the way in the software industry, there are a few competing definitions – dependent on the scope of focus people want it to cover. Some view the boundaries of DevOps to go beyond the development and operations processes to address wider business engagement.
The danger here, however, is that the scope of DevOps then encroaches on a broader business operational policy, such as that of a digital transformation strategy.
The reality is that DevOps is an important cog in a wider business operational wheel – not the wheel itself. This separation of concern is crucial to ensure there is clarity of focus within the IT organisation and the business at large.
Some see DevOps as a developer-focused initiative that has more to do with a developer’s ability to understand and use Application Programming Interfaces (APIs) for cloud- and Virtual Private Server-based computing. This view ignores the need to improve the deployment of applications in either traditional on-premises or modern cloud-based environments, or even a mix of the two.
There are those who are wary and skeptical of the DevOps phenomena: seeing it as a marketing or consulting ploy rather than an evolution of processes and an improved approach to deploying software from development into production at speed and with greater frequency and control.
Others have had bad experiences and battle scars from poor DevOps implementation and direction.
At the positive end of the scale, there are the advocates of DevOps buoyed by the pace of software delivered by the new age market disruptors in the guise of Amazon, Google, Facebook, AirBnB, Uber et al.
Despite the cynics, the underlying ethos is clear: improving the handover of software between the development and operations process through greater levels of automation, collaboration and shared or contained services, has its positives. It raises the prospect for faster and more frequent delivery of stable software.
Through this, Amazon and its cohorts have shown the level of disruption that has toppled many a traditional bricks and mortar-based organisation. The rules of the software delivery game have changed and it’s right that everyone looks to learn the new order of play if they want to survive in a more digitally operated world.
It would be wrong to assume that the successes of Amazon and others is entirely down to their technology and process support, but getting to grips with DevOps (no matter the application environment) has been a crucial part of their success.
Somewhere along the spectrum of experiences and thought processes lies a reality for DevOps for everybody else. Finding your place on that spectrum means finding a way to deliver applications at speed and with a frequency that not only suits your organisational culture and business model, but also the expectation of the market.
What DevOps can mean for you in 2016
Simply put, DevOps does have the potential to let you improve the control and stability in your application’s deployment phase – no matter what the operating platform: on-premises, fully cloud-based, or hybrid (in all the variations that the term might cover).
This in turn should let you adapt better to changing market forces and new ideas and innovations – software, after all, is one of the cornerstones of the digital economy.
When going to DevOps, while you shouldn’t try to “boil the ocean” you can keep in mind and address some important considerations such as a focus on: methodology (e.g. Agile), workflow orchestration and process governance (traceability/audits); appropriate levels of automation support and agile and collaborative practices.
You should also recognise the inhibitive factors such as complexity, risk tolerance, culture, and disparity in the environments of development, test and production. A detailed account of these and other drivers and inhibitors can be read in our CIC Guide to Continuous Delivery Realization and Enterprise DevOps Realities.
The good news is that there exist a number of solid tools, supporting technologies and strategies to help guide your DevOps journey and roadmap. Some companies’ tools are widely acknowledged, and others less so. A survey study we conducted on Developer dynamics in October 2015 highlighted support for a broad range of tools, suggesting that there is no obvious, de-facto leader in this space.
In addition, many of the leading software vendors now have in place various customer engagement centers underpinned with “design thinking”-type strategies to help those with the budgets and relationships to hone in on their DevOps needs.
IBM has gone a little further in delivering an accessible online facility to help direct key stakeholders in their DevOps goals with its Bluemix Garage methodology.
APIs, cloud computing, container technology (e.g. Docker) and micro services can all ensure an effective DevOps approach. However, without also backing their use with strong implementation processes (e.g. continuous delivery and deployment), methodology and application or workload scenario support, their benefits will be diminished.
Just remember - stay alert and follow the Green Cross Code: stop, look and listen - don't go charging across this particular road. Of all the words you’ll encounter, let this trio be the cornerstone for assessing your starting point and what will be required to "achieve" DevOps rather than becoming a casulty. ®