“DevOps” is one of the hottest trends in software because of four main things: It improves the frequency of software deployment, and works to ensure a lower failure rate for software releases. Thirdly DevOps reduces both lead time to release, and the need for manpower to make adjustments through the production phase.
All of this is great news for small and mid-sized businesses operating in the B2B space, and it’s especially great news for start-ups. These businesses typically operate on a lean budget. Because releasing functioning product to market is crucial for their survival, they need the most efficient processes to ensure there is as little wasted time and expense as possible.
DevOps seeks to tighten the methods by which modern software applications are developed and released. VentureBeat summed up DevOps first iteration with this perfect definition: “DevOps is not about specific tools. It’s about IT operations and software development working closely together to deliver software faster, with fewer errors.”
Unfortunately, not everyone is talking about the same thing; the term DevOps is being used rather inconsistently. Some businesses and industry experts refer to it as a movement, others as a culture. To some, DevOps is a job title, and to others, it’s a methodology for interdepartmental collaboration. Amidst all these confused—and sometimes conflicting—definitions, enough B2B professionals are asking the question … whatcan DevOps do for my business?
In practical terms, for businesses which implement the DevOps method, their operations and development engineers cooperate throughout the entire lifecycle of an application or software service. This means from the design phase, through its development, and into its production.
To further clarify what is meant by development (“Dev”) and operations (“Ops), The Agile Admin says, “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles. ‘Dev’ is used as shorthand for developers in particular, but really in practice it is even wider and means “all the people involved in developing the product, which can include Product QA, and other kinds of disciplines.
How it all began
To understand why DevOps is important, let’s look at where it started. The DevOps movement traces its beginnings to a time when software developers and IT operations didn’t traditionally work together. Code came from developers, and IT operations was expected to “make it work.” This disconnect became especially noticeable with the rise of the software-as-a-service (SaaS) model, the by-product of which is an increasingly savvy (and increasingly demanding) consumer.
It was around this time that a number of methodologies for software development and production reform came together in what New Relic calls “The Perfect Storm of 2009.” Think Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN and IT Service management. They were all the rage across conferences, talks and Twitter debates. As a result of this discourse, the new discipline of DevOps was born.
According to a report from Puppet Lab and IT Revolution Press, organizations that have implemented DevOps practices are “up to five times more likely to be high-performing than those that have not.” They are also, according to the report, able to deploy code multiple times a day, 30 times more often and 8,000 times faster than their peers, whose average deployment is only once a month. And their success rate is double that of their peers, and their ability to restore service twelve times faster. One of the ways these amazing successes is made possible is by reducing code-change lead times, making changes within minutes, rather than days or weeks.
As an example of DevOps in action, the Liverpool Victoria building society used Puppet, one of several tool which automates tasks that sysadmins often do manually, thereby freeing up time that can be used to work on more valuable projects.
ZD Net reports that, “Before using Puppet software, the database administration teams that manage Oracle installations “were receiving builds they couldn’t use as-is, so they had to modify them [but] once Puppet Enterprise was brought in [they found] they could move more quickly, and simply add on modules as needed.”
DevOps is a habit, not a tool
Remember, DevOps is not an app or a software service. It is more like adopting a business way of living. And unlike an app, it cannot be implemented overnight. Colin Barker writing for ZD Net says, “You can’t make everything DevOps tomorrow. Identify the projects that are most non-linear.” By starting on one project at a time, and getting development and operations to identify areas for collaboration for that first project, your B2B firm can begin to adopt a DevOps way of thinking.
Barker also discourages people from coming up with a roadmap or timeline “where you are going to be eight percent agile by this date and 10 percent by another date … it’s not going to happen that way.” Instead, think of DevOps as a habit your organization needs to get used to, rather than a goal it needs to achieve.
Of course, not everyone embraces DevOps as enthusiastically as the hype would suggest. In a November, 2014 article, B2B News Network published a DevOps primer, providing links to some helpful articles on the subject. One of these was the blog of professional programmer, Jeff Knupp, who boldly claimed that DevOps is “killing the developer.”
Knupp claims that DevOps forces developers to take on additional roles in the process of collaboration. For SMBs, this is unavoidable because of lean operating budgets. However, larger corporations appear to be embracing this revolution as well.
Knupp wags his finger at this DevOps upswing. He points out that, in larger companies where budgets aren’t as constrained, it is unfair to ask developers to perform multiple roles instead of actually developing (which is, presumably, what they love to do). Instead, they are being asked to keep up with an enormous amount of knowledge that crosses the boundaries of separate disciplines, and as a result, they could very likely to burn out. Knupp sums up his argument by insisting, “The effect of all of this is to destroy the role of ‘developer’ and replace it with a sort of “technology utility-player” … You do a disservice to everyone involved when you force your brightest people to take on additional roles.”
Despite such dissent, DevOps is gathering momentum. The fact that it attempts to keep up with the ever increasing demand of consumers for innovative and functional software product makes it an attractive concept for B2B businesses and start-ups. After all, the survival of these businesses relies on the rapid release of software that actually works.
Stephen Nelson-Smith, Technical Manager and DevOp with Atalanta Systems illustrates this technological Zeitgeist beautifully when he says, “we’re on the brink of a revolution in the software industry — a paradigm shift in which developers and sysadmins start to work together, to train each other, and ultimately to blur the boundary — welcome to the world of DevOps.
Photo via DevOpsday.org
