CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Stackify Blog, Aruna Ravichandran, Plutora Blog, Dalibor Siroky, PagerDuty Blog

Related Topics: Agile Software Development, Continuous Integration, DevOps Journal

Blog Post

App Downtime Costs More Than You Think by @Datical | @DevOpsSummit [#DevOps]

Even more reason to adopt DevOps and Continuous Delivery

Application Downtime Costs More Than You'd Think

Alan Shimel, editor at DevOps.com, wrote an article today discussing the findings from a study conducted by IDC, sponsored by AppDynamics, on the cost of application downtime within the Fortune 1000 (see article here).  Bottom line up front, IDC estimates that application downtime costs the collective Fortune 1000 an average of $1.25 to $2.5 billion per year.  More granularly, IDC estimates the average hourly cost of an infrastructure failure at $100,000/hr., and puts the hourly cost for the failure of a critical application between $500,000 to $1 million.

I remember seeing some figures cited by Gartner that estimated the cost of application downtime around $42,000/hr. back at the beginning of the century.  If accurate, and there's no reason to believe it wasn't, it implies that mistakes or misfortune in IT are getting more expensive for the business to cover.  The Gartner research was published in 2003, which means that during the 11-yr. period between studies the Compound Annual Growth Rate (CAGR) of the cost of application downtime has risen at a rate of 29.96% per year.  By way of comparison, the US GDP, a broad indicator of economic growth, grew at a rate of 3.84% per year over the same period.

Now, statistics are ‘damned lies,' and I'm sure questions can and should be raised around sample size and methodologies used in these studies.  Shimel himself points out a couple of factors which could have significant impact on the results of this latest study.  First, the average sample size of respondents answering each question on the survey was around 50, which is a decent amount in statistics, but far from a ‘smoking gun.'  Another factor he points out is that the study was sponsored by AppDynamics, who has a stellar reputation and is one of the fastest growing companies in IT, but who also happens to produce software for monitoring for things like infrastructure and application failure.

But statistics aside, this problem is getting worse, and fast.  Even allowing for some mistakes in the calculations and methods, we're talking orders of magnitude worse.  Seeing these statistics helps me understand why the business has steadily been applying more pressure on IT to deliver faster and reduce operating costs.  It also helps me understand where DevOps came from, borne out of a need to address the concerns of the business, and why it's so beneficial for companies who choose to adopt.  In fact, DevOps adoption was another topic in the study.

IDC reported that of the respondents, 43% reported they were practicing DevOps currently, while another 40% reported they planned on adopting DevOps "soon."  According to Shimel, "That 83% number is in line with another recent survey by CA that showed an 88% number."  For the large scale enterprise, the biggest initiatives that are driving DevOps adoption are Automation (60%) and Continuous Delivery (50%), with Continuous Integration, Automated testing, and Application monitoring/management not very far behind.

But, while IT is in fact responding to the needs of the business, there are definitely some factors which inhibit IT's adoption of DevOps.  The biggest reasons cited are Cultural inhibitors (56.7%), Fragmented processes (43.3%), and a lack of executive support (26.7%).  These are not new impediments to DevOps, or change for that matter.  But one statistic that I haven't seen before was the effect of tools adoption on the success of a DevOps implementation:

"There was another interesting metric in the study that bears noting as well. It is about companies who try to use their existing tool sets in a DevOps setting. There is something like an 80% failure rate for companies who try to adapt their existing tools for DevOps practices.  That screams out something that many a man already knows, "you need the right tool to do the job right."  The moral of that story is if you are going DevOps you damn better be buying some DevOps specific tools to get the job done right."

In research sponsored here at Datical, we've found that just under two-thirds of application changes require some modification to the application's database schema, making the database component an important, and often overlooked, aspect of application management.  In a study with 61 respondents from the Global 2000, we found that about a third of companies experience application performance issues due to the database 3 or more times per year, and 56% reported an MTTR of an hour or more to resolve a database issue.  When it comes to troubleshooting, respondents collectively reported they spend an average of 38% of their time investigating the database.  So it would appear that the database is one of the ‘usual suspects' when it comes to application downtime.

Datical DB was created specifically to support Agile development and DevOps practices for deploying database changes in a safe and reliable manner.  It provides context and granular level detail around the state of the database at each step along the deployment pipeline, making it incredibly easy to understand what changes have been run, which still need to be run, and which can be ignored.  It creates a data model for the database, which opens up some capabilities which other database automation tools just aren't able to achieve.  For example, DBAs can simulate proposed changes against a target environment before deploying those changes, drastically reducing the potential for deployment errors while assisting in troubleshooting the database.  With a customizable Rules Engine, DBA teams can hard code their unique corporate, technical and regulatory policies into the deployment process, providing a level of governance that further reduces the risk of application downtime.

If you'd like to learn more, come join a webinar we're hosting next Wednesday, Feb. 18th, from 12:00 - 1:00 pm EST, titled "Continuous Delivery for the Database: Best Practices." We'll discuss the common challenges DBA teams face in supporting increased release velocity, and how to bridge the technology gap between Continuous Delivery automation and manual database deployments.  We'll cap things off by showing you what a typical Continuous Delivery pipeline looks like, and demonstrate how to build an automated database deployment pipeline using Datical DB.

More Stories By Rex Morrow

Rex is the Marketing Director at Datical, a venture-backed software company whose solution, Datical DB, manages and simplifies database schema change management in support of high velocity application releases. Prior to Datical, Rex co-founded Texas Venture Labs, a startup accelerator at the University of Texas, and received his MBA from the McCombs School of Business. Before graduate school, Rex served as a Captain in the U.S. Army, and was awarded two bronze stars during combat deployments in Iraq.