EDITOR’S NOTE THE OPS TAKEOVER OF DEVOPS TOOLS

BYPASSING OBSTACLES TO DEVOPS SUCCESS

DEVOPS OVERHAULS APP DEV SCRIPTS

DevOps Tools for Workload ManagementBridging the gap between Dev and Ops will help both sides operate more efficiently and in a manner that will benefit the entire business.

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT2

EDITOR’SNOTE

Breaking Down Silos With Converged Infrastructure

The term DevOps implies the proverbial merger of developers and operations staff into one entity, at least with regard to certain functions. However, this isn’t always the case. For applications to work effectively, and soft-ware development to occur more naturally, the bridge between Dev and Ops needs to be cemented. This is especially important during the selection of DevOps tools, as both sides need to have significant input regarding the specific feature sets.

Now that operations has carved out more of a role for itself within the DevOps partnership, sharing tools and across-the-board collabora-tion should ensure efficiency across IT.

In the first part of this handbook, Mer-edith Courtemanche, site editor for

SearchDataCenter, speaks to the need for this interdepartmental communication. She high-lights the differences between DevOps tool sets and how each team can offer distinct input that will benefit the organization as a whole.

Next, Stephen Bigelow, senior technology editor at TechTarget, explains how to prepare IT groups for DevOps, helping to avoid cul-ture shock. Finally, John Treadway, head of products and software at Cloud Technology Partners, deconstructs the application lifecycle and offers insights to help IT with the difficult design phase. n

Patrick HammondAssociate Features Editor

Data Center and Virtualization Group, TechTarget

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT3

OPS TAKEOVER

The Ops Takeover of DevOps Tools

DevOps has traditionally favored developers, but with tool updates and partner-ships between vendors, operations is moving further up the stack. Some IT professionals have made some simple, yet pointed observa-tions about this transition.

Havoc can ensue if applications don’t func-tion the way that they should, said Colin Bris-son, manager of the IT operations center at PJM Interconnection. The company runs a day-ahead power market in the northeastern U.S. If its application doesn’t close out buying for all customers at the same time, the market isn’t fair.

“You have to know when these applications are having problems,” Brisson said, adding that one can’t discover all the problems in develop-ment. Wait until six major programs are run-ning at once on the same infrastructure and complex interactions occur, he noted.

There are plenty of ways to get developers

to think like IT operations managers—add-ing them to the on-call list for the 2:00 a.m. app launch ought to do the trick—but sharing tools between both sides of the house will keep everyone on the same page throughout the respective application’s lifecycle.

THE RIGHT TOOLS

Sharing tools isn’t as easy as it sounds—“release,” “deploy” and “automation” all mean completely different things on each side of the wall. “Between Dev and Ops there’s a whole language barrier, not a dialect,” said Ronni Colville, a Gartner analyst, during the 2014 IT Infrastructure & Operations Management Summit.

Workload automation and streamlined management are essential to fast-changing business applications, so choosing the right DevOps tools is as important to application

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT4

OPS TAKEOVER

performance as the underlying hardware.However, this important decision is dif-

ficult in part because tool feature sets are not one size fits all. You’re not simply installing DevOps. “Understand the unique context that each tool provides at each stage of the appli-cation lifecycle,” Colville said. Look for a tool that can adapt from development and testing through production.

THE APP LIFECYCLE

At the beginning of the application lifecycle, developers reign supreme. Then the focus turns to pre-production deployment tasks, and later it shifts to monitoring the production systems that host the software. If the app’s value grows, production usage—how the app works, how it helps the company grow and what changes best serve the architecture—becomes the focal point.

For applications to scale and update eas-ily, the development phase needs baked-in automation. Chef, a long-standing DevOps workflow management tool, is now integrated with the containerization platform Docker

to turn app updates into automated image provisioning.

Docker containerization replaces the tradi-tional package installation step of application deployment and updates with a methodology that rapidly exchanges switches from develop-ment to production. Container hosts are light-weight virtual machines with isolated runtime and shared kernels.

Chef automates the creation of a Docker image based on existing server templates. The image lives in a repository, similar to fellow open-source tool Git, so the DevOps team can choose where and when it is deployed. The team can make bidirectional configuration changes, if, for example, the database server’s address isn’t included in the initial image.

Teams rely on tools such as Chef or competi-tor Puppet to automate the conversation as code is shuttling back and forth between devel-opers and production operators.

Another vendor, JumpCloud, is bringing its code automation platform to this exchange, allowing the IT team to use any available scripting language. This opens applications up to operations staffers who speak a different

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT5

OPS TAKEOVER

language than developers, according to Jump-Cloud executives.

Log-based DevOps tools are also bringing operations further up the chain into develop-ment. Tools like Splunk and Logentries, along with various open-source options, can track log events and parse the data to help with analysis and troubleshooting. This provides different teams with a shared language to facilitate con-versation about the code. Teams can funnel in additional data from sources including server or app performance monitoring tools.

The goal is for applications and operations teams to see the performance impact of a code update or to troubleshoot a utilization problem with configuration changes at the app or lower levels, as dictated by the situation.

Logentries recently updated its dashboards with annotations, enabling different members of IT to include contextual information and knowledge within a log event.

“Log an event description and resolution, and that intelligence will save another group four hours of work,” said Trevor Parsons, chief sci-entist at the company.

Because different tools offer better features at the development, quality assurance, test, pre-production and production stages, don’t be averse to investing in a mix of DevOps tools for one IT shop. Applications follow varied lifecycles, and cloud-based applications may necessitate a different tool set for DevOps than those hosted on physical or virtual machines in house. —Meredith Courtemanche

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT6

CRITICAL COMPONENTS

Bypassing Obstacles to DevOps Success

The convergence of software develop-ment and IT operations teams into the singular entity of DevOps promises more responsive software development, but traditional organi-zational barriers and inadequate tools threaten the success of the effort.

More and more companies have moved toward the DevOps approach to get incremen-tal software updates and patches into the hands of users faster and with less hassle than tradi-tional software update cycles.

There is continued pressure to accelerate software releases to give organizations a com-petitive advantage.

“It’s how fast can you enter a new market or roll out a new platform,” said Colin Fletcher, research director at Gartner Inc. during a ses-sion at Gartner’s IT Infrastructure and Opera-tions Management Summit 2014 in Orlando, Florida. Fletcher cited the pressures of com-peting in new markets, accommodating new

computing platforms, and adding new product features or capabilities.

Traditional software development is a man-ual process that moves each product iteration, from code to testing to release, across areas

of the organization that are often siloed. Even though DevOps is ideally supposed to reduce barriers between developers, testers and other operational personnel, each organization struc-tures its DevOps effort differently.

Developers and operations personnel see release management in very different ways, according to Ronni Colville, a Gartner analyst. Developers see releases as code, functionality

Companies have moved toward the DevOps approach to quickly get incremental software updates and patches into the hands of users.

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT7

CRITICAL COMPONENTS

and capability. Operations, however, sees releases as a process or activity focused on moving code to recipients. Taken together, there are plenty of opportunities to drop steps or miscommunicate.

AVOID DEVOPS CULTURE SHOCK

Cultural change is critical for successful long-term adoption of DevOps. With this change, an organization can develop the ability to release applications effectively. The first step is to establish a definition of DevOps that facilitates collaboration between development and operations, which encourages the latter to adopt software development methods and use a cloud infrastructure to physically test and deploy the code.

Any remaining traditional silos for develop-ment, testing, quality assurance (QA), inte-gration, pre-production and production must come down—each silo slows the development cycle and can introduce unexpected problems.

Both development and operations teams can benefit from increased collaboration. For example, consult developers when discussing

operations problem-solving or post-mortem release assessments. Conversely, loop in opera-tions personnel in developer planning sessions. A combination of disciplines can improve working relationships and make the DevOps process more effective.

Such cultural change is not easy; it requires shared organizational metrics. This way, devel-opers and operations personnel measure per-formance using the same criteria. Cultivating a team attitude helps staffers focus on a single shared purpose rather than a narrow depart-mental goal. This may involve rotating jobs or sharing knowledge.

Gartner’s Colville urged adopters to try things—test creative new approaches to prob-lems, take prudent risks and learn from their mistakes.

The cultural divide between operations and developers posed a serious challenge for Bob Jones University.

“We didn’t have happy customers,” said Terry Worley, senior manager of IT operations at the university in Greenville, South Carolina. “I had to take operations and developers and get them to work together better. But I realized

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT8

CRITICAL COMPONENTS

that culture is a beast, and I can either sit in the chair or go slay it.”

The cultural changes have proven worthwhile for Worley, who noted that, after two projects using a revamped DevOps paradigm, develop-ers did not want to go back to the traditional model of software development.

DEVOPS REQUIRES A FULLY STOCKED TOOLBOX

Cultural implications aside, organizations must rely on a variety of DevOps tools. For example, developers will use tools to write code, QA testers will use tools for release deployment, and the environment will require cloud pro-visioning tools to move the new code to pre-production and production systems. This isn’t a problem, Fletcher said, but it’s important to consider how the various tools interconnect and support the software’s lifecycle.

There are numerous vendors already in the application release automation space. Vendors

on the operations side include BMC Software, CA Technologies Inc. and XebiaLabs Inc. The developer side is represented by vendors such as IBM, Electric Cloud Inc. and Serena Software Inc.

There are also emerging vendors that spe-cialize in developer workflow and build-and-release tools including Atlassian, CollabNet Inc., Rally Software, ThoughtWorks Inc. and OpenMake Software Inc. When considering these emerging vendors, remember that acqui-sitions might affect future product availability and roadmaps—adopt new app-release automa-tion products with caution. —Stephen Bigelow

Worley noted that after two projects using a revamped DevOps paradigm, developers did not want to go back to the traditional model of software development.

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT9

DEVOPS OVERHAUL

DevOps Overhauls App Dev Scripts

A DevOps overhaul for application devel-opment and maintenance will pay off in app resiliency and performance. Better app perfor-mance can’t begin with the operations team, however.

The application lifecycle starts with defining purpose, scope and high-level constructs. This definition is refined into a software design that includes both architecture and user experience components. The engineering team then devel-ops the app based on the initial design. The operations team (in a traditional sense) takes the finished program to deploy and operate on the enterprise’s IT infrastructure.

Along the way, the development teams tell the operations teams what is coming. A com-plex negotiation occurs over deployment archi-tectures, service-level agreements and other factors. Once the software is deployed, the traditional lifecycle model makes operations responsible for it.

All applications have a basic lifecycle, from idea to development through maintenance. Integrating development and operations func-tions—DevOps—affects the way IT works in the enterprise, reshaping each stage of the application lifecycle.

DEFINE WITH AN EYE ON OPERATIONS

In a product-centric culture, the application concept is a spin on the market and product requirements documents (MRD/PRD). MRD/PRD-style docs rarely give any weight to opera-tions; they are more focused on the feature, function and benefit statements of the applica-tion than on a holistic view of operations. With DevOps, however, any app definition that does not fully embrace operations is incomplete.

The design phase focuses on systems archi-tecture and user experience. In a DevOps world, design integrates the deployment

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT10

DEVOPS OVERHAUL

automation, performance management, moni-toring and other aspects of operations.

A concept of design for operations is cru-cial. Design all components of the system to be manageable, recoverable and operated at scale. An application’s design is not complete without a continuous delivery and operations model. Define the roles at this phase, specifi-cally making the development team responsible for operations integration from the start.

The key design principles come from cloud-native operations: extensive use of services, infrastructure awareness, self-healing and recovery, and distribution of data and storage, among others.

Application functionality should be deliv-ered and operated as services. This goes beyond storage, compute, networking, database and so on. Account lookup? Service. Balance request? Service. Inventory update? All service.

DEVELOP OPS-READY CODE

During development, sprints include opera-tions components. Developers cannot check in code that is not operations-ready for quality

assurance. Logging frameworks, resiliency hooks and other features are integrated into the code. Emerging operations and related services, such as Netflix open-source software, will be essential to a continuous integration and development model.

To support the rapid iteration and continu-ous deployment model, develop functional-ities as fine-grained services that are loosely coupled through APIs and messaging middle-ware. Code failures must have a minimal “blast radius” so they do not harm the rest of the system.

Proper cloud-native coding follows the prin-ciples laid out during the design phase. Auto-mated testing then catches code that doesn’t adhere to these DevOps standards.

All of the operations scripting for deploy- ment, management and related functions

Application functionality should be delivered and operated as ser-vices—this goes beyond storage, compute, networking or database.

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT11

DEVOPS OVERHAUL

should be delivered during development. It’s not acceptable to ship code and then make the operations team responsible for automating its deployment. Operations code is the responsi-bility of application developers.

DEPLOY DYNAMICALLY

In a traditional application model, deploy- ment is infrequent and planned well in advance, emphasizing total control. In a modern Dev- Ops model, successful deployment is equally important, but the resulting plan is very differ-ent. Developers test code themselves and check it in; the code progresses quickly through auto-mated unit, systems and integration tests.

Passed code deploys at various predefined windows, which could occur multiple times per day. Any code that is ready is then deployed. This is where the fine-grained services and iso-lation implemented during development really pay dividends. The failure of a small service can have a big effect on the application, but rolling back to previously stable code is a lot easier if the service is compact and self-contained.

OPERATE WITH SHARED RESPONSIBILITY

Without DevOps, operations teams work in infrastructure silos and applications. There are storage, virtualization, networking and server management teams, and there are ops teams that surround complete applications and systems.

The new model is to organize operations staffers with their development counterparts in a model that is focused on services—think back to our design phase. Each team member still needs expertise in key technologies, but this becomes a matrix model to distrib-ute core skills where they are needed. Teams are responsible for service-level agreements because the apps rely heavily on these services.

DevOps is often a difficult transition for IT teams. Try using new incentives to align indi-viduals from very different perspectives and experiences. You can’t make people change from an “us versus them” mentality to being jointly responsible for success or failure of entire systems and services without proper planning, communication and alignment.

—John Treadway

HOME

EDITOR’S NOTE

THE OPS TAKEOVER

OF DEVOPS TOOLS

BYPASSING OBSTACLES

TO DEVOPS SUCCESS

DEVOPS OVERHAULS

APP DEV SCRIPTS

DEVOPS TOOLS FOR WORKLOAD MANAGEMENT12

ABOUT THE

AUTHORS

MEREDITH COURTEMANCHE is site editor for SearchData-Center. She edits tips and other content for the site, writes news stories and creates editorial guides. Meredith joined TechTarget in 2012 from PennWell, where she covered the semiconductor manufacturing industry for more than five years. She holds a B.A. in English from Boston University.

STEPHEN J. BIGELOW is senior technology editor in the Data Center and Virtualization Media Group. He has more than 20 years of technical writing experience in the PC/technology industry. He holds a bachelor of science degree in electrical engineering, along with CompTIA A+, Network+, Security+ and Server+ certifications and has written hundreds of articles and more than 15 feature books on computer troubleshooting.

JOHN TREADWAY leads the products and software busi-ness at Cloud Technology Partners. He first encountered shared resource pools playing computer games on an IBM mainframe using teletype terminals, he later became an expert on on-demand, elastic, metered and shared resource pools and provisioning via cloud computing. Treadway is based in the Boston area.

DevOps Tools for Workload Management is a SearchDataCenter.com e-publication.

Margie Semilof | Editorial Director

Phil Sweeney | Managing Editor

Eugene Demaitre | Associate Managing Editor

Patrick Hammond | Associate Features Editor

Linda Koury | Director of Online Design

Neva Maniscalco | Graphic Designer

Rebecca Kitchens | Publisher rkitchens@techtarget.com

TechTarget 275 Grove Street, Newton, MA 02466

www.techtarget.com

© 2014 TechTarget Inc. No part of this publication may be transmitted or re-produced in any form or by any means without written permission from the publisher. TechTarget reprints are available through The YGS Group.

About TechTarget: TechTarget publishes media for information technology professionals. More than 100 focused websites enable quick access to a deep store of news, advice and analysis about the technologies, products and pro-cesses crucial to your job. Our live and virtual events give you direct access to independent expert commentary and advice. At IT Knowledge Exchange, our social community, you can get advice and share solutions with peers and experts.

COVER ART: TCMAKE/THINKSTOCK