Embed this image on your site:
<a href="http://www.appdynamics.com/blog/2011/12/20/the-12-days-of-devops" title="AppDynamics Application Performance Management"><br /> <img src="http://www.appdynamics.com/blog/wp-content/uploads/2011/12/12_days_of_devops1.png" alt="12 Days of DevOps" /></a><br /> <br/>Source: <a href="http://www.appdynamics.com" title="AppDynamics Application Performance Management Tools">AppDynamics: Application Monitoring Company</a><br/>

Agile & DevOps, apm, Application Performance Management, DevOps, Web Operations, WebOps

One of my colleagues this week was consolidating the results from our recent Application Performance Management survey, and one interesting finding was that 40% of customers have at least one release cycle a month. Out of those respondents, one third experience a Severity-1 incident each month as well. That’s a pretty compelling pair of statistics, and they might explain the continued frustration and conflict between development and operations teams. It’s also perhaps the reason why this DevOps underground movement can no longer be ignored (even by Gartner). There is no doubt development organizations have become agile, but does deploying this frequent change make the business more or less agile? For example, if one in three releases creates a Severity-1 incident, then surely agile development becomes a risk to the business. We’re at the point where Operations either has to start managing change better or simply restrict the amount of change that can occur.

So why are Sev 1 incidents so common? Based on my experiences and customer interaction, I’d strongly argue that testing in development isn’t enough. At the very least, it’s certainly not an insurance policy for deploying an application in production. When a Formula 1 team designs a car in a wind tunnel and tests it on a simulator pre-season, they don’t assume that the performance they see in test will mirror the results they see in a race. Yet, that is pretty much what happens today in the application development lifecycle. Development teams build and test their apps in pre-production before handing it off to operations for deployment in production, and they assume everything will work just fine. This is probably the worst assumption IT has made over the last decade, because development and production environments differ significantly. It’s also a lame excuse for any development team to use when a production issue occurs: “Well it ran fine in test so you must have deployed it wrong.” Yes people make mistakes occasionally, but if one in every three releases has an issue, deployment error may not be the sole reason. If development never get to see how their baby runs in production, they’ll never learn how to build robust, scalable, and high-performance applications.

Read the Full Post…

apm, appdynamics, appdynamics lite, application monitoring, CloudTest, HP LoadRunner, Load Runner, Load Testing, Production Monitoring, Production Testing, SOASTA

On Wednesday I delivered a keynote at WJAX in Munich. Everything went really well, but I was a little shocked at the response I got when I asked the audience “How many of you monitor the performance of your apps in production?” As I scanned the audience, I counted 9 out of ~950 developers had put their hands up, meaning about 1% had visibility of how their applications actually performed in production. I know what you’re thinking: “But isn’t application performance in production the responsibility of Operations?”  Well, it is and it isn’t. Most organizations think that when an application has an issue, it’s related to the infrastructure it runs on. That’s like saying when a car crashes, it’s because a part failed on the car whereas in actual fact most accidents are caused by the driver. Yes, hardware fails occasionally, but application logic and configuration drives how infrastructure resource is used, which is why most issues today occur when new code is deployed in production.

Read the Full Post…

apm, appdynamics, appdynamics lite, AppDynamics Pro, application monitoring, Application Performance Management, MTTR, Performance Bottlenecks, Production Monitoring, Slow Application, WJAX

The majority of us in IT are specialists, with the exception of a few VPs of engineering who are “special” in their own “special” world of being “special.” What I mean by this is that no single person has the skills or experience to do everything well in IT. IT is too big for me to explain or summarize in a few words, other than it requires a lot of different people with different skills to make it tick along. Despite applications being the living breathing entities of the business, a large portion of folk in IT have little context of how applications are built, how they execute, and how they consume resource across the IT infrastructure. Many people simply don’t care as their responsibilities are completely void of anything application related. That’s fine–but the reality is that everyone in IT should have one eye on the business. The whole reason IT exists is so the business can be more competitive and make more money. If this happens, IT gets more budget and is allowed to innovate more. IT and the business need each other to survive, which is why when applications slow down or break, both parties bitch at each other.

Operations need better visibility

Unfortunately for both the business and IT, the people (Operations) who manage the performance and availability of applications in production aren’t application experts. They are also not stupid either; their skills sets are wide and broad across many technologies and platforms that underpin applications. They manage a lot of things that application developers take for granted, like networks, databases, storage and virtualization. While Operations monitor the health of these infrastructure components, they often get bombarded with crap from the business when end users and business transactions are being impacted by slow performance, despite all system monitoring showing everything is fine. This lack of understanding between the Business and Operations is because both parties see things from different perspectives.

Read the Full Post…

apm, appdynamics, application monitoring, Application Performance Management, BTM, Business Transactions, CA Wily, Compuware, DevOps, Dynatrace, HP BAC, IBM Tivoli, Nastel, OpNet, OpTier

Six months ago I did something really stupid. I foolishly jumped on the social media bandwagon, thinking I could become the first super hero to claim online greatness. Sadly, the only meteoric rise has been the disk space quota for my email server inbox–all thanks to the billion notifications I now get daily from LinkedIn, Facebook and Twitter. For all I know I could have been poked by He-Man, tweeted by Krusty the Clown or propositioned by Batman to join forces on LinkedIn. Sadly, the amount of crap I get these days from trigger-happy social media apps means I simply ignore and delete 99.9% of messages without ever reading them.

Read the Full Post…

Alert Storming, apm, Application Performance Management, BTM, Business Transaction Management, Business Transactions, Dynamic Baselining, MTTR, Performance Monitoring, Static vs Dynamics baselines, Systems Monitoring

We’re pretty lucky these days to work and play with lots of cool stuff. In a consumer world of HD TVs, Mac books, iPhones, Droids, Angry Birds, Face books and tweets, life is rarely boring. Working in IT is the same. We’ve got clouds, NoSQL, agile, SOA, ria, pythons, scalas, rubies, and lots of ideas and technologies to play with every week. If only our friends and relatives outside of IT could figure out what the hell we’re all excited about, and the simple fact that most of us aren’t millionaires.

Read the Full Post…

Agile & DevOps, Agile methodology, Agile Ops, Business Transactions, cloud computing, Development, DevOps

After Velocity came DevOpsDays in Mountain View. I was hoping to give my feet and liver a rest after two consecutive days at Velocity. When I woke up at 7:30 a.m. the next day my body was throwing lots of OutOfEnergyExceptions, and it did cross my mind whether another 2 day event on Dev and Ops might be overkill. I got out of bed, hopped on a Caltrain, and made it to the DevOpsDay just in time for John’s “State of Union” speech.

John gave a great intro into how the DevOps movement started and its progress since inception back in 2009. Within just two years, Gartner is now recognizing the movement and its relevance within IT. John then talked about agile companies like FlickR who were doing a wacky 10 deployments a day back in 2009—and more recently WealthFront, who are now up to 50-100 deployments a day. It’s becoming clear Agile Development is driving the need for Agile Infrastructure and Operations. However, whilst the Cloud concept helps organizations become more agile, the idea that Ops will simply go away or be taken over by Dev is just nonsense (John put it a bit more bluntly than that, which was well received). The Business and Dev still need Ops, no matter what.

Read the Full Post…

Agile & DevOps, Agile Ops, CAMS, cloud, DevOps, devopsdays

My favorite TV channel at the moment is Speed TV. Last week we had the Monaco Formula 1 Grand Prix where RedBull (fizzy drinks company) beat Ferrari – the most prestigious name in motorsport history! Formula 1 is all about finding performance through innovation and change. F1 teams have up to a hundred engineers working flat out on every aspect of the car from aero to engine maps hoping to find a few tenths of a second to out-qualify, race and beat the competition.

The development of a F1 car is relentless with testing sessions only allowed during pre-season in order to reduce costs. Teams can only test new ideas and car updates at race weekends when they’re head to head with competitors, and limited to just 6 hours of track time. There is no such thing as a test environment, teams can’t just reboot or replace their car when a driver hits a wall or engine blows up. A component failure or crash means less track time to monitor and find the optimal car setup. They basically operate in a live production environment. With some teams bringing up to 35 different car updates for every race, it’s down to the engineers and support teams to continuously monitor and figure out which updates deliver the most improvement, pace and reliability. Not finishing a race or being slow has a massive impact on prize money and sponsorship loyalty.

Read the Full Post…

Agile & DevOps, apm, Application Performance Management, BTM, Business Transactions, Change Management, DevOps

Read the Full Post…

Agile & DevOps, Agile Ops, apm, Application Performance Management, DevOps, ITIL, ITSM, Operations

I recently had a chance to visit the webcast “This Week in Cloud Computing” and share some of my thoughts about cloud trends and application performance management. One thread of the conversation that I found particularly interesting was the discussion of agility in cloud computing. Although this theme comes up from time to time, most discussions I hear on cloud computing focus on cost-cutting and security.

These are extremely important concerns, of course — security in particular can be seen as a prerequisite of any sound cloud computing strategy. But there’s a “forest for the trees” risk in focusing too much on cloud computing pitfalls in lieu of recognizing its benefits, of which agility is certainly a major component.

We’re seeing with our own customers the need to be even more agile than before, of scrums becoming common and engineering stand-ups becoming a way of life. Any process change that helps speed up the application deployment chain is more than just a “nice to have;” it’s a sea change in the ability of companies to deliver value to their end users.

Bernard Golden makes some interesting points about two types of cloud computing agility in this discussion on CIO – definitely worth a read if you’re interested in the topic.

In case you missed the live webcast last week, here’s the video:

APM Thought Leadership, application development, cloud computing, hybrid clouds, public clouds