3 Reasons Why APM is Important for Cloud Computing « US English

3 Reasons Why APM is Important for Cloud Computing


Everyone loves talking about the weather but when it comes to taking the temperature of cloud infrastructures too many businesses throw caution to the wind. If your organization only recently started investigating cloud computing, you may not yet understand how much money you can save by provisioning just the right amount of compute power to meet demand. In this blog, I'll talk about how cloud computing is creating new opportunities for application performance monitoring (APM). I'll give you three reasons why APM is something enterprises on the cloud can't live without and I'll talk specifically about how Riverbed is providing new APM capabilities for the Microsoft Azure cloud platform with SteelCentral AppInternals.

Why does APM matter in the cloud? 

I'm focusing this post on Riverbed AppInternals and Microsoft Azure, but lets ask this question in a vendor-agnostic way. Why do you need APM for cloud computing, in general?  

Reason #1: to “right-size” your scale

Elasticity is one of the most important benefits that cloud computing provides consumers. The ability to add or remove resources rapidly enables application developers to closely match resource capacity to workload demand. However, doing that efficiently is hard. Usage-based pricing incentivizes us to avoid overprovisioning resources. At the same time, the risk of losing revenue due to frustrated users incentivizes us to overprovision resources. This dichotomy provides an opportunity for APM.

APM can help you maintain the right balance between cloud compute capacity and customer demand. You don’t want to waste resources by over provisioning compute power for your applications, nor do you want to lose potential revenue from users not served, or worse, users who abandon your site after experiencing poor performance. APM provides the feedback you need in order to maintain a proper balance of resources provisioned with resources required to deliver satisfactory user experience. 

Reason #2: to mitigate the risk of unpredictable performance

Another important factor that makes APM essential to cloud computing relates to performance predictability, or rather, its lack thereof. 

Performance unpredictability is one of the biggest obstacles to cloud computing. Although virtual machines (VMs) can share CPUs surprisingly well, slight pauses in a VM’s access to CPU are common even when the hypervisor is not over-subscribed. Performance is especially unpredictable for disk and network I/O where VMs contend for capacity on shared physical hardware. This contention can impact application performance in seemingly random and unreproducible ways, but good APM tools can give you the information you need to detect these anomalies and take corrective action.

Reason #3: to verify service level agreements (SLAs) from your cloud vendor

The ability to multiplex workloads from different organizations on a shared infrastructure is one of the most important capabilities that enable cloud providers to make a profit. While that “sharing” represents an opportunity for them, it represents a risk for the consumer. However, verifying the capacity and utilization of cloud resources with monitoring tools can mitigate that risk. If you’re paying a premium for top shelf compute power, wouldn’t you like to know that your cloud provider is delivering what you’ve purchased? APM tools can give you the information you need to hold cloud vendors accountable for the service levels they’ve agreed to provide. 

There are many more reasons why APM is useful, but managing elasticity, unpredictable performance, and cloud SLAs are three reasons why APM is especially pertinent for cloud computing.

What is AppInternals?

SteelCentral AppInternals is Riverbed’s flagship APM product. It collects performance data from agents installed on application servers hosting Java and/or .NET services. Those agents upload their data to the AppInternals analysis server which provides a web interface where users can perform analysis. For every AppInternals deployment, the following two tasks must occur:

1. The analysis server must be deployed in a place where agents can connect to it.
2. Agents must be installed on the servers hosting the services to be monitored.

The analysis server should be installed before any agents, so lets talk about the analysis server first. The analysis server is distributed as a VM and is available on the Azure marketplace. Once purchased, users will see the analysis server listed in the same way any virtual machine appears in their Azure account. The following figure shows what the AppInternals offer looks like in the Azure marketplace. 

Once the analysis server has been provisioned, you can download AppInternals agents from the Configure menu, as shown below:

The agent installation is easy. All you have to specify is the fully qualified hostname (FQDN) or address of an analysis server. Once the agent installation completes, the analysis server will start gathering performance data for the agent’s host operating system. Also the agent will start looking for any Java or .NET applications that are running on the system. To instrument an application, you must enable the “Instrument” and “Harvest” options for the application where it is shown in the agent list on the analysis server. This configuration is performed in a dialog such as the one shown for a Java process in the following figure:

Up to this point, we’ve made no mention of where AppInternals agents can be installed. Be it on-premise, in the cloud, or on the moon, as long as the agent can connect to the analysis server, it can be installed anywhere.There is one caveat, though. AppInternals agents must be installed on an operating system (OS). Any physical or virtualized host that runs a supported OS (currently Windows, Linux, Solaris, or IBM AIX) is eligible to run an agent. As long as you can access an OS with the privileges necessary to install software, you can install an agent.

Where is it advantageous to use AppInternals in Azure? 

Azure offers several ways to host web applications:

  1. Azure Virtual Machines – also known as “Azure IaaS”
  2. Azure Cloud Services – also known as “Azure PaaS.” The next generation of this offering is called Azure Service Fabric.
  3. Azure Web Apps – also known as “Azure App Service” and formerly known as “Azure Web Sites.” I like to think of this as a SaaS based offering for IIS (call it “IIS-as-a-Service”).

The following figure helps illustrate the management responsibilities in these offerings: 

It’s easy to get bogged down in details when describing the differences between these Azure offerings, but I’m going to just summarize them as they relate to their compatibility with AppInternals agents.

Azure IaaS: You can provision Windows and Linux VMs from the Azure Marketplace. After they’re provisioned, Azure provides you complete administrative control to do what you want within your VM. You are responsible for managing the OS and all the software running on it. Microsoft manages the virtualization layer, storage, and networking. You are allowed to configure certain aspects of those layers, such as where storage should be located and what TCP ports should be open. Obviously, since you have complete administrative control over the OS, you can install AppInternals agents on VMs in Azure IaaS.

Azure Cloud Services: Also referred to as “Azure PaaS,” this Azure product is designed to provide software developers a platform to deploy and run their application. The user experience with Azure Cloud Services starts in an IDE such as Visual Studio, where developers can deploy their code to an application server such as IIS running on VMs managed by Microsoft in Azure. Said VMs are provisioned only when a developer publishes their cloud service project to Azure from an IDE. There is no expectation that users would need to change the default configuration of these VMs but full administrative control is provided for running arbitrary startup scripts during the provisioning process, or connecting with remote desktop after provisioning completes. Both of these options make it possible to install 3rd party software, such as AppInternals agents. The preferred technique to perform an agent installation is through a cloud service startup script, which I’ll describe in a future blog post.

Service Fabric: This is the next generation of Azure PaaS. It will retain the same access to OS resources as Azure Cloud Services, so it will still be possible to instrument applications with AppInternals agents. We haven’t yet explored this topic thoroughly, but you can expect to hear more from us on it soon.

Azure Web Apps: I like to think of this as IIS-as-a-Service. In this platform you can easily deploy web apps to IIS and even configure your IIS instance, but you’re not allowed to access the OS. The OS is multi-tenant, meaning anyone with that level of access could potentially interfere with application instances belonging to someone else. Therefore, AppInternals agents cannot be used to monitor Azure Web Apps. However, AppInternals can be used to monitor Azure Web Apps with a mechanism called “JavaScript injection” which is designed primarily for end-user experience monitoring. I will not be ellaborating on this technique in this post because I want to focus on agent-based instrumentation which provides both end-user experience monitoring as well as back-end transaction tracing.

How much does AppInternals cost? 

The are four important things to know about the AppInternals pricing model:

1. AppInternals is priced per agent and licensed with a monthly or a permanent subscription. Pricing estimates should be requested through,

2. AppInternals targets business users who need the capabilities that only an enterprise-grade APM product can provide, and it’s priced competitively with similar APM products on the market. Enterprise-grade APM is not “cheap” by consumer standards, but it's a good investment for businesses where performance is non-optional.
AppInternals provides one of the most flexible licensing models in the industry. A lot of APM vendors nickel and dime you for modules that, in our opinion, offer critical functionality, such as end-user-experience monitoring, application mapping, and business-focused analytics. AppInternals provides full-blown APM functionality by default.

3. There’s no limit to how many agents you can install. You’re only charged for the number of agents whose data you consume. So you can deploy agents broadly but only license the subset you need for your immediate APM needs. This could be useful, for example, in cases where you don’t want to dedicate licenses for a staging or test environment because your APM needs there only last as long as your testing efforts. This flexibility also aligns nicely with the elasticity of cloud computing where the number of servers you need to monitor can change frequently.

4. AppInternals is offered as a Bring-Your-Own-License (BYOL) product in Azure. When AppInternals is purchased through the Azure marketplace, they’re essentially just purchasing a VM from Microsoft that contains the analysis server preconfigured with a temporary license. The associated compute costs will be billed to the customer's Azure account, but the AppInternals license must be purchased directly from Riverbed.

Azure pricing details can be found here:


Riverbed has formed a large part of its core identity around optimization for Microsoft technologies. Riverbed’s strong partnership with Microsoft secures its position as a leading provider of performance visibility and optimization in the Azure ecosystem. As Azure continuous to evolve you can expect that Riverbed will continue to enjoy first-mover advantage in this space.

If you'd like to learn more about AppInternals, I encourage you request "Instant Access" to a free AppInternals trial by visiting