Cloud Application Performance Monitoring

How to Build a Successful Application Performance Monitoring Strategy When Moving to the Cloud

Cloud adoption is increasing at a rapid pace. The eG Innovations & DevOps Institute APM survey indicates that 88% of organizations are using at least one form of cloud technology. Organizations move to the cloud for agility – they can deploy and have applications running in the cloud in minutes. Cloud computing also offers options for high availability, automated backups, and such.

When applications are migrated to the cloud, it isn’t the cloud service provider’s (CSP’s) responsibility to monitor the application service and the cloud provider’s built-in monitoring tools are unlikely to be sufficient. In our new eBook, we’ve covered the limitations of CSP SLAs and native monitoring tooling that will help you understand the gaps and what you need to do to proactively monitor and troubleshoot application uptime and services.

What Cloud Service Provider SLAs Actually Offer (and Don’t!)

Let’s take a quick look at the service levels that the popular cloud providers offer:

• 

  Amazon’s Compute Service Level Agreement is available here. Note that Amazon’s SLA commitment is around “Uptime”. Uptime is computed as the time when the instance does not have external connectivity.

  The focus of the SLA is on the connectivity of the compute instance, not about your application. Also, the SLA focuses on availability, not on performance – i.e., even for connectivity, there is no response time guarantee. At the end of the day, you/your IT admin is still responsible for any application issues. Note also that what you get in return for an SLA violation is a service credit. This may not compensate for the loss of goodwill or revenue loss that you may suffer in the event of an incident.

  The SLA guarantees for a managed service like AWS RDS is no different. See the AWS RDS SLA here. Again, SLA commitment is based on Uptime, which means all connection requests to an RDS instance must have failed. As in the case of compute instances, Amazon only guarantees instance availability, not performance.

• Microsoft Azure’s SLAs are available here. For compute instances, SLAs are defined based on “Connectivity”, which is very similar to how AWS defines their SLA.

  The situation with Azure’s database-as-a-service option is similar.

• Citrix offers a Citrix cloud service, where you can host the control plane of your Citrix deployment in their cloud. Citrix’s SLA for their cloud service is available here. As with the other cloud providers, the SLA is based on the percentage of time in a month that users can access their applications.

Another unsaid aspect of SLAs is that they are measured by the service provider, using their tools and mechanisms.

Debunk the Top Myths of Cloud Performance Monitoring

By now, you’ve probably understood that just moving to the cloud doesn’t mean that the performance of your applications is guaranteed. This and other common myths of cloud performance monitoring are covered in our white paper “Top 6 Myths of Cloud Performance Monitoring”.

We’ve also addressed the complexity of setting up, assessing the licensing cost, and the limitations of native cloud monitoring tools like Azure Monitor and Amazon CloudWatch in our earlier blog posts.

The white paper also provides a detailed comparison of CloudWatch’s capabilities with a specialized monitoring solution like eG Enterprise.

Related Reading