Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Web Operations: Feature Flags to Turn Off Failing Parts of Infrastructure

DZone's Guide to

Web Operations: Feature Flags to Turn Off Failing Parts of Infrastructure

· DevOps Zone ·
Free Resource

Best practices for getting to continuous deployment faster and with dramatic results in reduced outage minutes, development costs, and QA testing cycles. Brought to you by Rainforest QA.

On most of the projects I’ve worked on over the last couple of years we’ve made use of feature toggles that we used to turn pending features on and off while they were still being built but while reading Web Operations I came across another usage.

In the chapter titled ‘Dev and Ops Collaboration and Cooperation’ Paul Hammond suggests the following:

Eventually some of your infrastructure will fail in an unexpected way. When that happens, you’ll want the ability to disable just the features that rely on it, and keep the rest of the site running. Feature flags make this possible.

We’d mainly use this approach to disable peripheral functionality such as the ability to comment on a site whose main purpose is to deliver news.

From what I understand this means we’d permanently have if statements (or some equivalent) in the appropriate places in our code base which could be dynamically toggled if we start experiencing problems.

This differs slightly from the feature toggle approach we’ve used because those toggles would eventually be removed when the feature was running successfully in production.

Hammond goes on to suggest using feature flags for any external services that we rely on e.g. Flickr relies on the Yahoo address book, del.icio.us and last.fm but can gracefully disable that functionality if needs be.

He also points out that it’s useful to think hard about what features are absolutely core to serving your site e.g. Flickr can disable photo uploads but still allow people to continue viewing photos.

Overall this sounds like a pretty neat idea and apart from the slight complexity of having the conditionals in the code I can’t really think of any reasons why you wouldn’t want to do it. Happy to hear opposing views though!




Discover how to optimize your DevOps workflows with our on-demand QA solution, brought to you in partnership with Rainforest QA.

Topics:

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}