How to get your ops folks to understand agility (make them read this, for starters)

Agility is the key to success in today’s busy, mobile-first application world. It’s no longer a matter of spending months developing an application and rolling out the red carpet for one major release. The reality is that apps must be released quickly and iterated frequently so one can learn from user feedback and meet business expectations.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":711848,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Many of us are familiar with agile development, a system of processes and tools that ensures the efficient development of high-quality apps. But that’s only half of the story. Once development is ready to release an application, how do we support the next stages of the release process with equally agile operations?

Agile delivery

The basis of agile delivery is when development and operations teams actively collaborate to seamlessly build and manage an application throughout its lifecycle. Several businesses have already proven just how far this approach can carry them. NYSE Euronext, in the midst of its merger, reduced their two-year web development cycle into an iterative, two-week production cycle by adopting agile delivery. They were able to release 40 new business-critical apps in 18 months as a result.

Pinterest credits release automation and DevOps smarts with being able to successfully support its 5,124 percent explosion in growth last year. Facebook releases apps twice a day and processes up to 300 changes per day for one billion users, perhaps representing the pinnacle of agile achievement.

A crisis of collaboration

However, although they are striving for more frequent releases, most companies don’t yet have the processes and tools to support agile delivery. Development and ops teams still grapple with ongoing misunderstandings because they don’t have shared visibility and accountability for an application’s success once released into production. In fact, collaboration issues are still so serious that the leading causes of application failure can be traced back to them. These include failed software upgrades, the inability to scale to meet unforeseen demand, resource exhaustion and configuration errors, according to research from Carnegie Mellon University.

All of these issues have lead to a phenomenon of blamestorming between development and operations teams. Seventy five percent of ops teams admit that development perceives them as a roadblock, or only somewhat supportive of agile development, while 72 percent of ops professionals say that development is not supportive of their goals.

Three steps to agile delivery

As big as this challenge may seem, it is not insurmountable. The solution involves bringing down the invisible wall that has traditionally separated development and operations. In its place, build a bridge of automation and collaborative workflow, the foundational components to agile delivery. This involves establishing tools and processes that maximize shared visibility and transparency, while diminishing the likelihood of errors through handoffs, as well as maintaining the security and control of the production of the production environment.

I’ve seen companies succeed when they started with three components and then built up their agile delivery from there. These components are automation, shared visibility and troubleshooting.

Automation

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":711848,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Automating deployments reduces the chance of error when development teams pass code and instructions to ops. In an ideal world, developers can specify the exact components that are needed for their app in a self-contained package that incorporates all of the necessary application prerequisites. The automation process enables all of these requirements to be applied as part of the application’s release package.

In the case where an application encounters significant errors, the other key element to automate is a rollback capability. Here, what a team needs is a controlled change process where the option exists to revert to a previous version with all of its associated extensions and configurations. Ideally, this process can be applied from the operations side in a simple series of clicks.

Shared visibility

Shared visibility provides the foundation for collaboration once an application has successfully moved into production. This enables a developer to know whether his app is performing or behaving in a different manner in production than it did in the dev/test environment. Without this insight, the operations team may be unaware of unusual application behavior and impending challenges.
However, there is also a question of control. The key is to find a way to give developers access to the information they need for troubleshooting and to understand an app’s behavior, without giving them hands-on access to the production systems (think “read only” visibility without the ability to change settings).

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":711848,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Troubleshooting

The third crucial area is troubleshooting. This is the most common cause of blamestorming between dev and ops teams.

The key here is that developers need access to production debugging information in a controlled manner, and a troubleshooting toolset so they can understand what happened on the production system. Ideally, with the visibility mentioned above, a developer can actually see why an error occurred, and avoid unnecessary experimentation to try and replicate the error.

This means going beyond ops sharing screenshots of application error pages, and finding a way to record major errors in an application’s code execution for later analysis by the developer.

[aditude-amp id="medium3" targeting='{"env":"staging","page_type":"article","post_id":711848,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"dev,","session":"C"}']

Agility that goes beyond development

Organizations that embrace agile development while relying on disconnected operations processes are making the painful discovery that much of the value gained from agile development is negated. Today’s iterative development approach requires special attention to the operations and delivery side of applications. Once a business starts with these three foundational elements, they can build and refine their agile delivery even further, placing a focus on advanced application monitoring and continuous performance and scale, which I’ll discuss in my next post.

Andi Gutmans is CEO and co-founder of Zend Technologies. Founded in 1999, Zend was instrumental in establishing PHP. Today, Zend helps others create and implement back-end infrastructure for mobile and web applications. Zend Server and Zend Studio are deployed at more than 40,000 companies worldwide.