TAG | appdynamics lite
A new year, a new iPhone and a new quarter. What else is new? How about a new company?
Last month I was fortunate enough to join a stellar marketing team at one of the fastest growing enterprise software startups in the bay area. The company you ask? AppDynamics, and did I mention we’re also the leading next generation Application Performance Management (APM) provider for modern architectures in distributed, cloud, virtualized and on-premise environments? We exceeded our targets for 2011 achieving an astonishing 400% growth in bookings. Not too shabby for being the new kid on the block in a competitive market already inundated with vendors. You have old school APM tools from megavendors like CA, HP and Compuware (was dynaTrace). Then you have the new school breed such as New Relic and AppDynamics. In fact, Gartner’s MQ lists over twenty vendors. So with such a crowded market why did I even consider such a move?
Well there’s a laundry list of reasons, but here are the top ones that come to mind.
1. Business Innovation. This is another kind of BI not just Business Intelligence. It’s really a breath of fresh air to be working with an organization that is not only obsessed with pumping out insanely great technology every few quarters or so, but also open to embracing innovative approaches to every discipline of the business including creative marketing and sales strategies. Often times enterprise software companies unabashedly attempt to cloak themselves in slideware selling a “vision” or an enterprise solution poles apart from reality. Unfortunately when it comes down to an actual evaluation, you end up having to attend a dozen meetings just to see an applicable demo, a one week to two month proof-of-concept followed by throwing millions of dollars at consulting and implementation services, which segues to my next point.
2. Ease-of-Use. This simple yet powerful concept has been repeatedly neglected or intentionally ignored by many enterprise software companies. Luckily, the Leaders of the New School such as Apple, Salesforce, Box, etc. (not Busta Rhymes group) have changed the way end users value an intuitive user interface and design. At AppDynamics, we’ve adopted a similar mindshare. “Easy” is the new world order in this industry because the managers, engineers and folks in IT operations are encountering enough complexity as it is with these modern architectures. I doubt the last thing that they want is another tool to further complicate their lives causing more frustration on the job. At the end of the day everyone is a consumer – the least common denominator – who wants to use software that helps us demystify our lives and makes us successful at our jobs (unless you’re a sadist).
Software that is easy to install, implement and use can have a tremendous impact on the bottom-line of a business. Suppose you end up rolling out a new system but end up having to spend a chunk of company change on implementation and training costs. What impact does that have on your productivity and ultimately your company’s bottom-line? Here’s an example from Avon’s Q3, 2011 earnings transcript,
“Despite extensive pre-implementation testing, we had greater than anticipated implementation challenges in the go-live. Significantly higher business complexity in this market contributed to a greater than expected level of disruption, as I said, when we went to the go-live environment.”
Many vendors make enterprise deployments akin to embarking on an IT version of manifest destiny. I’m sure you can think of a few applications in your own IT toolbox that fit the bill where at some point you ended up asking yourself, “Why can’t this be as easy as [fill in the blank with some consumer app]?” Fig. 2. See empathetic frustrated user to your left.
That was compelling enough for me to join AppDynamics. We truly understand the business significance as to why software ought to be easy 360 degrees around especially in production. I’m not saying that the work designers and developers have to do to achieve this “Easy” goal is easy in itself. I have an unrequited love for the folks in engineering who possess the talent and perseverance in coding applications, but that doesn’t excuse a vendor from selling you a dream and then leaving you stranded to implement a nightmare all because there wasn’t enough emphasis on ease-of-use.
3. Application Performance. This one is near and dear to my heart and arguably the main reason for me to join AppDynamics. It takes me back to the challenging days and sleepless nights I endured while working on a massive global PDM implementation at LG Electronics jointly with Dassault Systemes. The year was 2008. Skynet hadn’t become self-aware yet. App Man was just A Man in the throes and woes of IT operations, and half way around the world over in Seoul, Korea I was
managing juggling recurring performance issues on a weekly basis with our PMO having to answer to the beck and call of the LGE CIO. The project’s launch date had been delayed due to various complications with the implementation (that’s a whole other story). Any ideas what one of those might have entailed? If you guessed “performance”, congratulations! You’ve won! Download your free copy AppDynamics Lite.
Every week new customizations were being released from R&D back in the states, PS in Korea and SI’s sitting on the other side of the room. You could call it Agile development’s nemesis, frAgile development. The dynamic nature of our java-based environment only introduced more challenges to the performance team who were heads-down trying to reverse engineer someone else’s code and refactor it using APM tools that just didn’t provide us with the full visibility we needed to comprehensively profile and diagnose application performance issues (using JenniferSoft). In fact, one of the consultants on our team ended up creating his own profiler to expose these blind spots, but what we really needed was a next-generation APM tool that would visually map and connect the dots for us like the one below.
Then we ran into another stumbling block after we completed migrating legacy data to a new “production” environment. When the time came to retest the entire set of performance use cases in this new environment we experienced all kinds of performance regressions. Since everyone was collaborating so well with each other for over the past two years, we all cheerfully marched forward without any finger pointing as to what the root cause was. Ok, so it wasn’t that utopian. Fortunately, because of everyone’s undying commitment and personal sacrifices, the project went live successfully in mid 2010 with over 2,000 users visiting the system per day. In hindsight, we could have easily saved a month’s worth had we used a better tool thereby eliminating the usual suspects.
From that experience I’ve come to appreciate and understand how business-critical managing application performance is for any company. Now I am on a mission to spread the word of AppDynamics to help companies manage rapidly evolving, distributed environments.
Buckle up 2012, we’re just getting started.Link to this post:
When I joined AppDynamics less than a year ago, we were situated in a 6,000 sq ft “cozy” office on 2nd and Brannan. On my first day I was greeted with a MacBook Pro and was asked to find a spare desk amongst the boxes and carnage of a typical startup environment. To my left was a relentless engineering and UI team, and to my right was a fired up sales and marketing team, and a quietly confident Founder and CEO, Jyoti Bansal who made all of this happen. Across the office was a shiny gold bell mounted on the wall, which rang every time AppDynamics closed a new customer. In the last year I can honestly say that shiny bell hasn’t stopped ringing, and is the biggest adrenaline boost one can get while working.
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.
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.