The software application development story does not of course stop with programmers. Quite apart from the fact that there are end users, customers and operators (or call them what you will) at the final section of the app food chain; there is the requirement analysis stage before development ... and the testing (and even regression and penetration testing) stages that must take place during the first elements of project iteration.
We must also pay lip service (or more appropriately, reverence) to the fundamentally crucial "operations" layer, which oversees maintenance, monitoring and management as well as application performance to tune the engine once it’s running.
Throwing it over the wall...
The traditional problem with operations is that developers are often said to get their software “build” to a serviceable enough level and then (as the expression goes) just “throw it over the wall to operations”. The operations team is then left holding the baby and fails to get the ongoing support it needs.
So this perennially recurring issue has ultimately led to the rise of so-called DevOps, a hybrid function described by a correspondingly hybrid term to denote a role that embraces and caters for the interdependence of these disciplines and their symbiotic reliance upon one another.
With relation to cloud computing, DevOps takes on special significance as not only are applications over the wall, but one might argue that the entire IT infrastructure is permanently over the wall and ‘one virtualised step further away’ from the desktop from the start. As such, OpenStack has reportedly taken steps to extend the design process overseeing application builds so that data centre infrastructure and operations considerations become a more natural part of the total application lifecycle management process.
Release management specialist Serena Software’s David Hurwitz talks volubly on this subject and says that DevOps crosses over with the cloud because running services on demand necessitates having a 24x7 process management mentality in place from first base.
“For web-based organisations that deliver everything to customers via the Internet, this approach is second nature to them. However, for companies with private or hybrid cloud strategies in place, bridging the gap between the development team and the operations function can be more difficult. However, with better integration and process management, services can be delivered back out to the organisation in faster time, which should be IT's ultimate goal,” said Hurwitz.
The fact is that when we get to the cloud, linking development and operations involves looking at the whole process for deploying services out to the business – and this can include new software, updating applications or spinning up new virtual machines that meet business demands. Hurwitz suggests that each of these requests can therefore cross over between internal development and ITSM resources, external service providers or a mix of these.
Automation equals DevOps power
"DevOps is not just a technology problem - first and foremost, it demand closer working bonds being formed across teams to facilitate better understanding of common goals. What can help achieve this, alongside greater collaboration, is better ‘automation’ of work from demand through to deployment. This also helps organisations improve visibility of their requests and how they are being managed,” he added.
So are cloud-based application automation controls a gateway to hosted DevOps nirvana, or is this still only just part of the story?
Much of the challenge here (historically speaking) has arisen due to the “overabundance of resources” afforded to developers building applications in a vacuum ie not exposed to the vagaries and inconsistencies of real-time connections and input/output delays. If DevOps is to maintain its integrity as an upstanding cloud citizen, then can it still provide the development-to-implementation feedback loops, measuring and monitoring functions that it would do if applied effectively inside more terrestrial deployments?
According to Quocirca analyst Clive Longbottom, getting this right means applications should be based on the same environment as the DevOps environment in question.
“This is so even if it is kept ‘nominally separate’ through using different virtual environments. At least all that is generally required is to move a virtual image from one place to another, which can be relatively easily automated -- and this is far better than moving code from one physical environment to another, ensuring that it is then provisioned correctly and having to continually check the run time against the development environment to see what version of code each side is running,” he said.
Technical tools of the trade
Longbottom suggests that technical project portfolio tools work well in this environment. This creates a scenario where the technical teams find it easier to work as a team; development and patch priorities are more closely and easily identified; business issues can be shown to be true to the development team.
While hosting specialist cloud vendors may have found that a substantial degree of DevOps has been a prerequisite for successful operations for some time now, there is every argument to suggest that companies lower down the cloud migration curve are also logically less adept at DevOps as a whole.
Whether this is due to greater intrinsic levels of automation and IT orchestration in cloud, more forward-looking agile practices being employed by highly virtualised organisations or by some semi-coincidental best practice which originates at the architectural stage is hard to say.
Senior VP of marketing at Eucalyptus Systems David Butler doesn’t sit on the fence and asserts that DevOps and cloud are like a marriage made in automation heaven. “DevOps is all about automation at all levels of the application development and IT operations lifecycle management processes including the infrastructure, the operating configurations and the lifecycle management processes. Cloud computing is all about transforming IT into provider of automated, elastic services including the infrastructure, platforms, and the applications. Both are designed to free IT from extreme complexity, lack of agility, and the overall lack of collaboration between development and operations people and processes.”
Butler points to DevOps tools such as Opscode Chef and Electric Cloud, which he says offer IT the ability to automate configurations and code transformations by coding all the development and operational life cycles and therefore removing complex system administration burdens associated with development, testing, operating and maintaining code.
At the risk of sounding like we are concocting a marketing tagline here: you can’t do on-demand IT orchestration without a conductor and a musical score to follow if you want apps plus hardware and network plugs and switches to hum along in unison.
So cloud DevOps is a very real situation, it’s a very real entity and it’s a very real and potentially effective means of shouldering some of the architectural and core administrative/management functions that now need to be executed. After all, today’s cheesy-termed portmanteau terminology is tomorrow’s de facto industry standard - as they say.
