2015 was a big year for the DevOps movement and the growing family of projects and technologies that support it. From the launch of Kubernetes 1.0 by Google and its partners last summer, to the burying of the hatchet between Docker and CoreOS (the two of them once pushed rival container formats, but reached common ground at DockerCon 2015), there was plenty of DevOps-related technical progress to go around last year. Moreover, many testing suites received crucial integrations with software development platforms such as Microsoft Visual Studio, in addition to support for languages like Python. This all lead Madison Moore of SD Times to proclaim that 2015 was when "testing [caught] up with DevOps."
The sheer amount of resources now pouring into the DevOps community - including the efforts of huge open source initiatives as well as the dollars and engineering of some of the world's most innovative tech firms - means that the overall capabilities of DevOps tools should continue to improve in the years ahead. Indeed, solutions such as QualiSystems CloudShell and TestShell ensure the resource sharing, object-based automation and self-service interfaces needed to enable DevOps innovation.
Still, there is uncertainty about how successful many IT organizations will ultimately be with their DevOps initiatives. For all the new developments in areas like containers, continuous integration and automated testing, there are still technological challenges to DevOps. For example - managing and deploying complex environments for dev and test is often given second chair to production deployment and orchestration. Sandboxing platforms like Quali's Cloudshell are addressing this but organizations still need to take a holistic look at DevOps tooling. There are also organizational and cultural divides that remain to be bridged. Underscoring this point, a 2015 survey by InfoQ asked more than 70 IT professionals to determine whether a list of practices were associated with DevOps, and found that none of the items received a majority of all responses. Basically, there is still little agreement on what "DevOps" really means.
First thing's first: DevOps is not the same as agile development, the movement with a similar set of terminology that often pops up in DevOps discussions. Agile is a process designed to break free of the constraints imposed by waterfall methodologies and thus achieve superior responsiveness and speed across projects. However, its lofty goals are often hard to realize because of the limited availability of infrastructure environments caused by lengthy provisioning times, resource hoarding and fragile script-based automation.
"[M]any organizational efforts to move to agile development are hampered by poor infrastructure availability; while individual developers can work on their own machines, inevitably there comes a time when a production-like environment must be stood up to evaluate integration and allow more robust testing," explained Bernard Golden in a December 2015 piece for CIO. "This process requires machines to be provisioned, and obtaining them can often take weeks or months. So even agile development qua agile development is challenged when attempted in a traditional infrastructure operations approach."
So DevOps needs to account for these particular technical requirements around infrastructure, in addition to the general silos that separate many devtest and operations teams, even under ideal infrastructure situations. Golden touched upon this last point in his article, noting that manual processes are still the norm when it comes to dealing with whatever code has been handed off by the development and testing group. How can the implementation of DevOps address issues like this one and go beyond the limitations of typical agile development?
To offer a basic definition, we can say that DevOps is about delivering and maintaining applications at speed, via automation of any infrastructure adjustments along with collaboration between devtest and operations. We can also say that it is something to work toward, rather than something to work through. That is, DevOps is not a proverbial switch that can be flipped. Continuing with the electrical metaphor, it requires you to lay out the "wiring" first, such as your collaborative processes, your infrastructure-as-a-service clouds and your environment-as-a-service solutions, before you're likely to see results.
Unlike politics or music, DevOps doesn't gain all that much from grassroots movements. Initiated from the ground up, it may work in a few experimental contexts but it likely will not overcome the significant inertia of doing things the same way they've always been done, i.e., with manual processes that do not scale well.
"DevOps is not a switch that can just be flipped."
Instead, success depends on getting buy-in from senior managers and team leaders. Having a sustainable path to success with DevOps is the key here. This means not creating new unmanageable silos - e.g., "The DevOps Department" - within the organization, and not setting unrealistic goals, such as expecting your issues with legacy infrastructure to go away overnight. Again, DevOps is more the goal than the actual process, which is dependent on what tools and practices you utilize along the way.
"A fundamental reason that DevOps is trickier to introduce than other technologies is that it fuses cultural shifts with operations and development," Rajesh Sethu, director of DevOps at Replicon, told TechBeacon in late 2015. "Upending the business culture - especially with large companies with well-established processes - is not something that can be instantly transformed at the people, process and information levels."
A cloud sandboxing platform like Quali's CloudShell can help you make a sustainable transition to DevOps. You can address all types of infrastructure, from legacy and physical assets to virtual and cloud ones, and enable the IaaS and EaaS needed for getting the environments you need on demand.
The takeaway: DevOps had a big year in 2015, but challenges remain in settling on a clear definition and mapping out a sustainable path to implementation. Technical and cultural requirements both have to be considered and then addressed through collaboration, communication and automation solutions.