As the clock ticks down to the start of the DevOps Enterprise Summit 2015 (DOES15), burning questions, spirited debates, and intense market buzz swirl around this new approach to IT. Backers swear that DevOps can revolutionize a company's application development and delivery, but many potential adopters find DevOps confusing and hard to grasp. Both camps will meet at DOES15, now in its second year and scheduled for October 19-21 in San Francisco.
What's on tap for DOES15
The conference has an agenda full of promising sessions and testimonials. Hosted by DevOps expert Gene Kim, co-author of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, DOES2015 will feature speakers from companies such as Cisco, Bank of America, HP, Intel, Netflix, Raytheon, and Microsoft, as well as from DevOps consultants and specialty vendors including Puppet Labs and Chef. Session and panel topics include automation, security, containers, ITIL, DevOps culture, IT transformation, testing, continuous integration and delivery (CI/CD), monitoring, and metrics.
Sam Fell, senior director of product marketing at Electric Cloud and one of the conference organizers, says a big topic at this year's event will be how big companies can embrace DevOps at a large scale. It's easier and more straightforward for small companies and individual teams to adopt DevOps. But in a huge company with multiple hierarchies of product pipelines, each feeding into separate environments, successfully undergoing a DevOps transformation becomes much more complex, though not impossible.
"Many of the challenges that these big companies are experiencing and that we're focusing on at the conference all seem really solvable, and a lot of people have solved them already," Fell says. "They're not these big, hairy, mysterious things that you can never vanquish. It's just that addressing these challenges is hard for many big companies.
"There are so many different roadblocks at these huge companies that the cultural transformation is hard," he adds.
Target executives will talk about the company's DevOps journey, which has featured both top-down and grassroots approaches, while ING will explain how the company has harmonized ITIL with DevOps.
What should attendees pay attention to?
Chief among the issues in the DevOps world that attendees can expect to hear about in formal sessions and hallway chats: What the heck is DevOps?
"DevOps is sufficiently vague, intentionally so," says Ronni Colville, a Gartner analyst. Indeed, although DevOps has been around for about five years, it has been defined in myriad ways, and there is no pre-defined set of instructions for how to implement it.
"Every DevOps project is a snowflake, even in the same company," Colville says.
Gartner and others have outlined practices to help guide IT leaders embarking on a DevOps project. But the consensus is that due to its very nature, DevOps will never be codified as, say, ITIL, with its reams of methodology and practice details. "In DevOps there's no 50 pounds of books," Colville says, in reference to the exhaustive documentation that exists for ITIL.
So go ahead, jump in and venture forth a description
At the risk of becoming part of the problem, here's a short DevOps explanation: It's a transformation of the IT organization that eliminates the wall separating software development and operations. These staff become a single group and begin to communicate, collaborate, understand, and trust each other.
They pursue shared goals tied to business priorities so the frequency and quality of application and web services delivery increases. Tools to automate processes like code testing and infrastructure configuration should be adopted as deemed necessary to support the new way of working.
Phew. One sec, let me get out of the way. Okay, you can now start throwing darts at the previous paragraph.
This much we know: DevOps, whatever it might be, is hot, hot, hot
What's clear is this: DevOps' popularity has ballooned to what some say are near-bubble levels. This juncture in DevOps history makes DOES2015 an ideal and timely venue for those seeking clarity.
Seemingly every week, new vendors and self-appointed gurus jump on the DevOps bandwagon and join the shouting match. Investors are making big bets on vendors in this space. For example, Puppet Labs, a maker of IT automation software, has raised almost $90 million from backers, including Cisco, Google Ventures, Kleiner Perkins Caufield & Byers, and VMware.
After all, DevOps offers a growing, attractive financial opportunity to sell products, seek speaking engagements, hawk newsletters and eBooks, and promote blogs.
Gartner has said that by next year DevOps will have evolved from its current niche to become mainstream and will be used by 25 percent of Global 2000 organizations. And the market researcher expects that spending on tools used to support DevOps transformations will grow 21 percent to $2.3 billion this year compared with 2014.
Enter the frazzled and confused IT exec
As the noise around DevOps increases, more CIOs and IT executives feel pressure to learn about it and bring it to their organizations, lest they fall behind competitors.
So they dive in and start googling "DevOps." After a couple hours of intense research, they're gasping for air, drowning in an ocean of different views and definitions.
As it is, DevOps has been left "wide open as a marketing buzzword and that's part of the problem with adoption: It's too confusing at first glance. You can't get it," says Jon Hendren, community manager at ScriptRock, one of the event's sponsors.
As the number and variety of tools positioned for supporting DevOps increases, evaluating products and vendors becomes more complicated for IT execs. Colville warns that not all tools billed as "DevOps-friendly" actually are, since many vendors are applying jargon freely.
She advises identifying "pain points" that are limiting throughput and being clear on a goal, which should narrow the scope and clarify the task.
Mike Baukes, co-CEO of ScriptRock, whose product is designed to provide a single view into the configuration of a company's servers, cloud apps, and network devices, warns that many tools used for DevOps are "very complex and hard to master."
Bottom line: It's key for IT leaders to have their scam detectors set to high. "There's a lot of guys trying to sell snake oil," Hendren warns.
So where and how do you start?
Absent a specific definition and methodology, it's no surprise that different people have diverse ideas on the right way to begin a DevOps project.
Do you need to first roll out the automation tools, or is it better to focus initially on merging the "dev" and "ops" teams? Do you start small with one or two product teams, or do you aim big and attempt to transform the entire IT organization?
Should you create a separate team of experts and evangelists tasked with spreading the gospel and wisdom of DevOps among their peers, or is this a counterproductive move that creates another IT fiefdom and bottleneck? Is it time to flee IT and test the waters in marketing, finance, or rodeo-clowning?
Gartner's Colville recommends starting with an assessment of what needs fixing in the IT organization, and based on that, defining how a DevOps approach will lead to solutions. The way DevOps is defined is less important than making sure that this definition is clear to all involved and is adhered to consistently, she says.
Change the culture first, think about specific tools later
Jason DuMars, senior director of technical operations for SendGrid, who has been managing technology, operations groups, and architecture for 20 years, has seen the dark side of DevOps, and it wasn't pretty. "It looks like massive attrition, technology sprawl, unmaintainable infrastructure, configuration management rot, and does not scale," says DuMars, a DOES15 attendee.
How do you avoid creating this hell? Start with people, address processes next, and worry about tools last, even if that seems counterintuitive. "Many well-meaning managers and DevOps champions do it in reverse, and it leads to disaster every time," DuMars says.
Getting everyone involved to communicate, collaborate, respect, and trust each other is essential. "Collaborative and positive culture between engineering groups will get you more in the end than all the automation in the world," DuMars says.
Others also warn against trying to take shortcuts by throwing money at the problem.
"You can't go off and hire a guy who claims to be a DevOps specialist and expect him to magically fix the problems for you," says Jamie Begin, founder and CEO of RightBrain Networks, a DevOps consultancy. "It's a different way of thinking. The tools grow up organically around that."
Carl Caum, technical marketing manager at conference sponsor Puppet Labs, concurs. "A red flag should go off if you hear someone say: 'We have a DevOps tool,' " he says. "There's a DevOps culture and practices, which the tools help you implement. You can't write a check and get DevOps."
Focus first on web apps, don't fear failure, and get a move on
Colville recommends starting with a narrow scope, ideally focused on applying DevOps to web-based applications that are built using agile development and designed for frequent change.
These types of applications lend themselves more to DevOps than what Gartner calls "systems of record," such as ERP suites, and "systems of differentiation," such as commercial applications that have been tailored and customized for the business.
Meanwhile, Stephen Elliot, an IDC vice president, says it's crucial to have a sense of urgency. "You need to want to achieve an outcome, or it's not going to really work otherwise," he says. "Have the perspective that it's okay to fail, but it's not okay to not try. It's going to be a bumpy ride, but it's well worth the investment."
And if you're the CIO of a large company that already adopted DevOps in a few small teams successfully, don't stop, says Abner Germanow, senior director of enterprise marketing at New Relic, an application performance management vendor and also a conference sponsor. Instead, explore ways to propagate DevOps more broadly, although it's far from clear how this is accomplished at a large scale. "There are no silver bullets," he says.
At the conference, he'll be looking for examples of companies who had DevOps success with small teams, workgroups, or product groups, and have been able to expand that across their product portfolio or company wide.
What about the idea of a DevOps SWAT team?
There's little consensus on whether it's a good idea to build a dedicated DevOps team tasked with propagating the practice across the IT organization.
Josh Johnson, a senior software engineer for Adzerk, a Durham, North Carolina maker of cloud-based ad-management software, lived through the failure of that approach in several previous jobs. "In my experience, funneling 'DevOps' through a segregated group will end in heartache," he says. "But I think the reasons why go beyond simply the segregation itself."
In his first failed "DevOps" job, neither the programmers nor the operations group changed their respective cultures. "Yet we, a handful of people who were hired from outside the company, were tasked with making everyone change."
The focus was on CI, issue tracking, and supply chain management (SCM), but the DevOps team lacked the authority to change processes, although the goals were to fix problems like failed deployments and lack of organization.
Ironically, the IT team at his current employer works according to DevOps principles, although they never deliberately set out to implement that approach. The company is small, so there's no hierarchy—small teams are formed around problems as needs arise. "We all have the capability to do any maintenance, deploy any code, commit to any repository," he says. "Everyone steps up. We are devs; we are ops. But mostly we're engineers, solving problems the best way we can and loving every minute of it."
Then there are those like Puppet Labs' Caum, who was previously against having a dedicated DevOps team but has since modified his stance. "If your culture is so broken where there is no communication at all between devs and ops, it might make sense to have a DevOps team with a fresh mindset, to develop a standard new way of working, and have that team propagate it across the company," he says.
Think beyond "dev" and "ops"
Another issue on the DevOps table right now is why this approach needs to be limited to developers and to operations people. What about people in charge of security, audits, regulatory compliance, project management, and other areas?
"Don't be afraid to get the compliance, audit, and security teams involved. There's a lot of opportunity here to innovate," says IDC's Elliot. "Often those teams are an afterthought."
SendGrid's DuMars says people often view automation as a threat to control frameworks, when in fact it provides opportunities to improve them.
This can be particularly helpful for the regulatory compliance needs of large companies, according to Chef's Colin Campbell.
ScripRock's Baukes says this is an important issue for DevOps. "How do you get all these different components talking effectively, using the same language so they can make effective change and deliver value to the business?"
Zeus Kerravala, founder and principal analyst with ZK Research, says overlooking security can ultimately throw a wrench into the DevOps engine and defeat the whole purpose of its adoption. "Whether you do DevOps or not, you need to build security at every stage of the app dev process, but for DevOps it's got bigger implications because it can slow down the process," Kerravala says.
The people issue
Also important is who gets picked to be involved in DevOps, since the attitude of the team members is key. Convincing operations staff in particular may be a tough sell, since they may view DevOps as a threat to their systems and processes.
"Operations groups can be fiercely protective of their domains of ownership because they are the ones who have to wake up at 3 a.m. to fix them," says DuMars.
"Traditionally, operations is very much a preventative or protective function within an IT organization and the development aspect is a change function," says ScripRock's Baukes. "Those are very different perspectives."
Consequently, companies must devote time and effort to get reluctant IT staff, particularly in ops, to buy into the plan.
Chef's Campbell points to the issue of skills gaps and the need for retraining. "How do you transition a large IT organization with a certain set of skills to a different way of working that requires a new set of skills?"
"Making that transition happen effectively for organizations and individuals is something we need to be on top of," he says.
If this isn't handled properly, an IT organization may face a talent exodus. "The dirty truth of DevOps transformations is that many people will leave as a result, unless it is incredibly well managed," says DuMars.
Then there are those like Jason Moorehead of IP Commerce, a company that has come to love the DevOps way of working and can't picture itself ever again in a traditional IT organization with a 20-year-old methodology and a waterfall approach to software development.
"I love it, where the industry seems to be going," says Moorehead, an applications architect whose company uses products from Atlassian and Puppet Labs. "The one-team concept is the way to go."
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
