Author Archives: pkarayan

Application Performance Management in the Cloud

Cloud computing has been the buzz and hype lately and everybody is trying to understand what it is and how to use it. In this post, I wanted to explore some of the properties of “the cloud” as they pertain to Application Performance Management. If you are new to cloud offerings, here are a few good materials to get started, but I will assume the reader of this post is somewhat familiar with cloud technology.

As Spiderman would put it, “With great power comes great responsibility” … Cloud abstracts some of the infrastructure parts of your system and gives you the ability to scale up resource on demand. This doesn’t mean that your applications will magically work better or understand when they need to scale, you still need to worry about measuring and managing the performance of your applications and providing quality service to your customers. In fact, I would argue APM is several times more important to nail down in a cloud environment for several reasons:

  1. The infrastructure your apps live in is more dynamic and volatile. For example, cloud servers are VMs and resources given to them by the hypervisor are not constant, which will impact your application. Also, VMs may crash/lock up and not leave much trace of what was the cause of issues with your application.
  2. Your applications can grow bigger and more complex as they have more resources available in the cloud. This is great but it will expose bottlenecks that you didn’t anticipate. If you can’t narrow down the root cause, you can’t fix it. For this, you need scalable APM instrumentation and precise analytics.
  3. On-demand scaling is a feature that is touted by all cloud providers but it all hinges on one really hard problem that they won’t solve for you: Understanding your application performance and workload behave so that you can properly instruct the cloud scaling APIs what to do. If my performance drops do I need more machines? How many? APM instrumentation and analytics will play a key part of how you can solve the on-demand scaling problem.

So where is APM for the cloud, you ask? It is in its very humble beginnings as APM solution providers have to solve the same gnarly problems application developers and operations teams are struggling with:

  1. Cloud is dynamic and there are no fixed resources. IP addresses, hostnames, and MAC addresses change, among other things. Properly addressing, naming and connecting the machines is a challenge – both for deep instrumentation agent technology and for the apps themselves.
  2. Most vendors’ licensing agreements are based on fixed count of resources billing rather than a utility model, and are therefore difficult to use in a cloud environment. Charging a markup on the utility bill seems to be a common approach among the cloud-literate but introduces a kink in the regular budgeting process and no one wants to write a variable but sizable blank check.
  3. Well the cloud scales… a lot. The instrumentation / monitoring technology has to be low enough overhead and be able to support hundreds of machines.

On the synthetic monitoring end there are plenty of options. We selected AlertSite, a distributed synthetic monitoring SaaS provider similar to Keynote and Gomez, for simplicity but in only provides high level performance and availability numbers for SLA management and “keep the lights are on” alerting. We also rely on CloudKick, another SaaS provider, for the system monitoring part. Here is a more detailed use case on the Cloudkick implementation.

For deeper instrumentation we have worked with OPNET to deploy their AppInternals Xpert (former Opnet Panorama) solution in the Amazon EC2 cloud environment. We have already successfully deployed AppInternals Xpert on our own server infrastructure to provide deep instrumentation and analysis of our applications. The cloud version looks very promising for tackling the technical challenges introduced by the cloud, and once fully deployed, we will have a lot of capability to harness the cloud scale and performance. More on this as it unfolds…

In summary, as vendors sell you the cloud but be prepared to tackle the traditional infrastructure concerns and stick to your guns. No, the cloud is not fixing your performance problems and is not going to magically scale for you. You will need some form of APM to help you there. Be on the lookout for providers and do challenge your existing partners to think of how they can help you. The APM space in the cloud is where traditional infrastructure was in 2005 but things are getting better.

To the cloud!!! (And do keep your performance engineers on staff, they will still be saving your bacon.)


Leave a comment

Filed under Cloud

The Tenets of Hosting a Technical Workshop for Humans

How to have a successful technology workshop.  Inspired by a workshop at Velocity 2010.

  1. Name your session correctly and enter a description that is suitable and specific. Calling it “From design to deploy” and having a workshop about installing a key-value store and setting up an app are two vastly different things.
  2. If there are pre-requisites list them with the description so people can prepare (or skip your session).
  3. Don’t assume everyone  will have an Apple laptop in their hands. That runs OSX 10. That has access to local network. That runs Chrome 6 or Safari.
  4. Before you dive into configuration and install steps, explain what your software does and why we should care. Then explain what the workshop is going to do and how.
  5. Hand out some materials so people can go at their own pace.
  6. Don’t write the demo materials and code the night before you are giving a presentation at a major conference.
  7. Have an assistant to help individual folks so you don’t run from person to person like a butt monkey while everyone else twiddles their thumbs.
  8. Don’ be lazy and terse with your slides. Unless you have some really good software that is solid and works with any input on any environment, under any condition.
  9. As people are performing the steps of the workshop, follow along and display what you are doing why explaining the steps. Don’t sit around and drop smart-ass tongue-in-cheek comments about the world. Hopefully you have rehearsed and tested the steps as you present them to your audience.
  10. If you are showing snippets of code on different slides, don’t just explain how they work together and that function on page calls a method on page 3. Show the code structure and then dive into it.
  11. Don’t assume the workshop network will be the same as your home network with every host open to everyone else.
  12. Make sure the software version you are demoing is tested and stable. Or don’t tell people there are no single points of failure in your badass software.
  13. Test your demo and and the instructions that people will be performing.
  14. Have a backup plan even if it involves handing out materials and doing pen and paper exercises.
  15. Leave some materials with folks that can be handy to follow up on the workshop.
  16. Thank your audience for being patient :).
  17. When you think you are done preparing, prepare some more.

Leave a comment

Filed under Conferences, DevOps