The Pain of Not Doing DevOps

For planning new software projects and maintaining existing deployments, DevOps helps organizations creates stronger ties between all stakeholders throughout the development lifecycle. So it’s no surprise that DevOps is rapidly gaining popularity around the world. In the most recent Global Development Survey from Evans Data, 72% of developers reported working in a formal DevOps environment, ranging from specific development operations interactions to enterprise-wide implementation. DevOps practices may vary by organization, of course (for a quick overview, check out our AppDynamics primer).

In my experience, organizations that fail to embrace DevOps do so at considerable risk. Not long ago, a major real estate developer reached out to AppDynamics for help. The company’s .NET installation was having problems with a third-party web asset management library, which had specific write-to-disk configuration requirements.

These requirements were configured properly in the development environment, but not in production. And because because Dev was siloed off from Prod—with no process for keeping these environments in sync—the company was unaware of the oversight.

This end result: ongoing performance problems in production. And because IIS auto-restart settings recycle the application pool after a time interval, the company was unable to identify the root cause of ongoing application instance crashes.

Finding the Cause

The company contacted AppDynamics, asking if we could figure out why the application kept crashing. We instrumented their system, which hadn’t run APM software before. Upon reviewing the AppDynamics system logs, we immediately found the source of the problem: the application didn’t have permission to write to disk in the production environment.

This discovery spurred the company to undertake a lengthy internal testing and environment comparison process, which uncovered numerous configuration differences between Dev and Prod.

Lessons Learned

On a foundational level, a dysfunctional culture was largely responsible for the company’s production woes.

For instance, there was a lot of friction—including major arguments at times—between various stakeholders, including management, operations and development. This was a classic case of “code being thrown over the wall” from Dev to Prod. Communication between these factions was so poor, in fact, that a contractor was the primary liaison between Dev, Ops and management.

In addition, there was a loss of tribal knowledge whenever a technical practitioner left the company. When AppD arrived on the scene, none of the Devs knew anything about the troublesome third-party tool, nor how it was being used. Even the aforementioned contractor—the sole link between the siloed factions—was unaware of the problematic utility and the critical role it played.

Avoiding Pain through DevOps

Communication and knowledge-transfer between teams is critical. Each environment—Dev, Prod, and so on—should be as similar as possible for continuous integration and continuous deployment (CI/CD). Major configuration differences between environments often leads to negative outcomes.

A key tenet of DevOps is to standardize your environments. If you build code on one Dev’s machine, it should run everywhere the exact same way.

The software industry is moving in this direction. “Today, most developers state that some portion of their development team includes operations engineers.” the Evans Data study found. “The movement toward DevOps has not only impacted stakeholders’ roles, it has also influenced development team composition.”

Implementing DevOps practices, combined with a solid APM solution, will enable your organization to avoid pain and gain deeper insights into the performance of your code.

Learn more about how AppDynamics can help your own organization on its DevOps journey.

Sean Stanford is part of AppDynamics Global Services team, which is dedicated to helping enterprises realize the value of business and application performance monitoring. AppDynamics’ Global Services’ consultants, architects, and project managers are experts in unlocking the cross-stack intelligence needed to improve business outcomes and increase organizational efficiency.

Why Metrics Must Guide Your DevOps Initiative

Metrics-oriented thinking is key to continuous improvement – and a core tenant of any agile or DevOps philosophy. Metrics are factual and once agreed upon, these facts are used to drive discussions and methods. They also allow for a collaborative effort to execute decisions that contribute towards business outcomes.

DevOps, although becoming a commonly used job title, is not a role or person and there is no playbook or rule set to follow. Instead, DevOps is a philosophy which spans people, process, and technology. The goal is releasing better software more rapidly, and keeping said software up and running by joining development and operational responsibilities together. Additionally, DevOps aims to improve business outcomes, but there are challenges in selecting the right metrics and collecting the metric data. Continuous improvement requires continuous change, measurement, and iteration. What’s more, the agreed-upon metrics drive this cycle, but also create insights for the broader organization.

 

Data-Driven DevOps

A successful DevOps transformation focuses on a couple areas. To start, a culture change is needed between development and operations teams. Another core tenant of DevOps is measurement. In order to accomplish a true DevOps transformation, it’s important to measure the current situation and regularly review metrics which indicate improvement or degradation. One of the core tenants of DevOps is measurement, and using said measurements as facts when driving decision making. These metrics should span several areas which may have been considered disjointed in the past.

To help DevOps teams think of possible metrics and how these metrics relate to key initiatives, Gartner recently released this useful metrics pyramid for DevOps:

Many of these metrics span development, operations, and most importantly – the business. They measure efficiency, quality, and velocity. However, Gartner points out that the hardest part is often defining what we can collect, take action upon, audit, and use to drive a lifecycle. The second challenge (which Gartner does not discuss), is how these metrics should be linked together to offer meaningful insights. If the metrics do not allow linkage between a release and business performance, attribution gaps remain. And unfortunately, many enterprises today analyze metrics that have a lack of linkage or relationship between them.

To help with these relationships, context is critical. Without context, metrics can be open to interpretation, especially as you move up the Gartner pyramid. And this is precisely where AppDynamics can step in and help.

Based on our measurement technology, AppDynamics can link metrics together to allow you to attribute earnings or cash flow with a release or change that represents an incremental improvement in the application. We represent these within Business iQ, our event-based analytics system for the highly valuable data we extract.

Additionally, AppDynamics provides metrics to drive visibility inside the application without creating an additional burden for developers. In fact, with automated instrumentation as part of AppDynamics APM, metric data is produced consistently and comprehensively across all teams. This is extremely beneficial as many teams have different ways of collecting data, which can traditionally lead to inconsistencies. But with AppDynamics, consistent measurements are always obtained from the application components and desired business outcomes of the application.

Learn more about how Business iQ can accelerate your data-driven DevOps initiative.

Moving the DevOps Needle in Enterprise Organizations

DevOps has proven itself across many smaller organizations but large enterprises are usually slow to change. It can be a daunting task even identifying where to make changes since there are so many processes and organizational silos to get in the way. As a veteran employee of small, medium, and large enterprises I have figured out ways to drive organizational change based upon getting results. In this presentation I will describe my methods for creating change within and across organizations and provide specific examples of how to begin a meaningful shift towards making DevOps a standard practice within your organization. I’ll detail some of the roadblocks to making DevOps a reality and explain how to overcome these obstacles.


[slideshare id=26955993&doc=devopsdays-movingthedevopsneedle-final-131007174831-phpapp01]

AppJam 2012: Accelerating DevOps Culture at Edmunds.com

John Martin, Senior Director, Production Engineering, Edmunds.com
Collaboration between Dev and Ops is a critical part of how Edmunds.com manages its 30 critical web application. Development requires hard data from Operations so they can fully understand how to improve application performance. In this session John will discuss the key drivers for DevOps at Edmunds.com,  how Dev and Ops collaborate using AppDynamics to solve production incidents, and his top 5 tips for implementing a DevOps culture in your organization.

Slides:

[slideshare id=15678365&doc=edmundsfinal-121217201143-phpapp01]