DEVOPSdigest

DEVOPSdigest asked experts from across the industry – including consultants, analysts, organizations, users and the leading vendors – for their opinions on the best way to foster collaboration between Dev and Ops. Part 7, the final installment, covers IT Operations tools.

Start with The Best Way for Dev and Ops to Collaborate - Part 1

Start with The Best Way for Dev and Ops to Collaborate - Part 2

Start with The Best Way for Dev and Ops to Collaborate - Part 3

Start with The Best Way for Dev and Ops to Collaborate - Part 4

Start with The Best Way for Dev and Ops to Collaborate - Part 5

Start with The Best Way for Dev and Ops to Collaborate - Part 6

SHARED LANGUAGE AND TOOLS AROUND PERFORMANCE

It's critical for developers and operators to speak a common language about the performance of their applications. We often see DevOps teams use performance analysis tools to "greenlight" apps before they go into production. That way, developers can make sure they won't break things in production, and if operators do see issues in production, they can easily work with developers to troubleshoot using the very same tools. Having a shared language and tools around performance dramatically improves DevOps collaboration, especially when performance is complex, such as in multi-tenant Big Data systems.
Chad Carson
Co-Founder of Pepperdata(link is external)

MONITORING

"CAMS" (Culture, Automation, Measurement and Sharing) has persisted as the DevOps mantra. A good monitoring/performance measurement strategy (a big part of the M) is key in bringing Dev and Ops teams together in solving problems at design and run time. What are attributes of a good monitoring strategy: 1. Agreeable. Have a general agreement on what KPIs matter, how they should be gathered and what to do with the data. Monitoring should not be used for deflecting blame but to unite the team on common goals. 2. Accessible. All of monitoring data is at everyone's disposal. In absence of accessibility you end up with war rooms, with chieftains clinging to their weapons (monitoring silos) 3. Integrated. Every aspect of the system and application have to be built to allow measurement. Monitoring as an afterthought usually fails at scale.
Peco Karayanev
Sr. Product Manager, Riverbed(link is external)

Do a Google image search for "DevOps" and you'll see dozens of models describing the components that make up a continuous delivery cycle. You'll also notice "monitoring" in all of them. The whole point of continuous delivery is that successively smaller, and therefore faster, releases reduce the amount of code change between versions. Reduced change equals reduced risk. However, as release cycles get faster they require near immediate feedback to know if the release was successful or not. In addition, development and production environments are becoming ever more dynamic, so this feedback must come from equally dynamic monitoring. Monitoring that tells both Development and IT Operations how well the service is performing and its availability profile. Baking pre-defined monitoring criteria into an application will allow Operations teams to implement accurate monitor on Day One, and provide that real-time feedback loop to their Development counterparts. Put simply: Including monitoring standards into the Development criteria for a service allows monitoring to become the feedback mechanism that makes the process continuous.
Adam Bacia
Staff Product Marketing Manager, Zenoss(link is external)

APM

Leveraging Application Performance Management (APM) integrates OPS & DEV teams by seamlessly pinpointing and communicating the root cause of production issues, meaning faster time-to-resolution. APM tools allow your OPS & DEV teams to effectively speak the same language when it comes to production issues in the wild. Being able to drill down further into application issues allows OPS to identify the root cause of errors and communicate those directly to DEV teams.
Doug McAfee
Solution Engineer, Apica(link is external)

NETWORK MANAGEMENT TOOLS

With the growth of cloud computing and software-defined networking, it's increasingly important for development and network teams to work closely together. Whether it's troubleshooting slow applications or optimizing the network to support new ways of application access, breaking down IT silos is a must. In fact, a recent survey at NetBrain revealed that 45 percent of network engineers cited the lack of collaboration and coordination across teams as the number one challenge when troubleshooting network problems. To overcome this challenge, critical steps include gaining end-to-end network visibility and automating knowledge-sharing across teams. When everyone has the same view of what's happening on the network and level of information at their fingertips, communication flows more quickly and a richer culture of collaboration ensues.
Grant Ho
SVP, NetBrain(link is external)

Developers code and test their applications in a perfect network environment. Operations deploy and manage those applications in the production network which could include private, public or hybrid networks. It is at this point that your users discover that the application isn't usable because the production network environment is different to the developer's network. Operations blame development, developers say "it works for me" and your users are frustrated. The good news is that there is an alternative approach that helps Dev and Ops to collaborate and mitigate the risk of failure. It involves using Network Emulation technology to create a virtual test network that is repeatable and controllable and has the same characteristics of the production environment. Now, the development team can build their applications in an environment that accurately reflects the real world network enabling them to identify and resolve any networked application performance issues early in the application lifecycle, so that there are no nasty surprises when Ops take delivery.
Peter White
Operations Director, iTrinegy(link is external)