Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

6 Reasons Cloud Monitoring Is Different Than Server Monitoring

DZone's Guide to

6 Reasons Cloud Monitoring Is Different Than Server Monitoring

Moving an app to the cloud means monitoring the app, not your infrastructure. There's a difference, especially when we get into serverless and FaaS.

· Cloud Zone ·
Free Resource

See why enterprise app developers love Cloud Foundry. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity.

Traditional IT monitoring has revolved around monitoring the infrastructures and servers. As you move to the cloud, it is possible that you don’t have either of those things. You could deploy your app via a service like Azure App Services and rely on Azure’s hosted Redis and SQL offerings. You could literally have access to zero servers.

In the cloud, it is even more important to monitor your actual applications and not just your servers. Application performance management solutions become even more important. Your cloud provider is responsible for monitoring the infrastructure and keeping your servers online. You still need to monitor the performance of your actual applications.

Monitoring Platform-as-a-Service (PaaS) Style App Hosting

One of the big advantages of cloud computing is the ability to deploy your applications, and the server aspects of it are completely managed. As a developer, I love only having to worry about my application.

Application deployment options like Heroku, Azure App Services, Google Cloud Engine and others potentially create some monitoring challenges. You may not have full access to the underlying servers and typical monitoring solution will not work. Some of these also provide deployment slots which are also unique from a monitoring perspective.

At Stackify, we use Azure App Services. Using them as an example, we do not have access to the server themselves. We can use the Azure KUDU console to access a pseudo file system, Event Viewer, IIS Logs, running processes, and other information. We also can’t access Windows Performance Counters. To monitor our instances we use a special WebJob as a monitoring agent instead of installing on directly on the server.

Auto Scaling in the Cloud

One of the big advantages of cloud hosting is the auto-scaling capabilities. Many companies have peak times of day or week for their applications. Outside of those peak times, they should scale their applications down to save on server expenses.

Cloud monitoring solutions have to support the autoscaling of the applications. The number of the instances of the applications could constantly be changing, and each one still needs to be monitored. The cloud monitoring must easily install as servers are created and handle scaling down.

Server Monitoring is Not Cloud Monitoring

Traditional server monitoring has revolved around if a server was up or down and what the CPU and memory usage is. Once you move to the cloud, these are details you don’t have to worry as much about or may not even have access to. You can setup auto-scaling or use a serverless architecture and it just works. Monitoring cloud applications is a little different!

Application performance monitoring is still very important. You still need to know which requests in your application are used the most and which are the slowest. APM solutions can help provide this. You also need to monitor application metrics via Windows Performance Counters, JMX MBeans, or other common metrics.

Function-as-a-Service (Faas) or Serverless Architectures

Developers are starting to take advantage of new serverless architectures. Services like AWS Lambda and Azure Functions make it easy for developers to deploy applications as individual pieces of business logic. The cloud providers can then process requests for those functions at nearly infinitely scale. They have completely abstracted away from the concept of servers.

Monitoring serverless architectures is a whole new paradigm. Cloud monitoring solutions are going to have to play catch-up when it comes to monitoring these new types of applications. The cloud providers are also going to have to build new capabilities to make the monitoring possible.

Monitoring Cloud Application Dependencies

Cloud providers provide a wide array of specialized databases, queuing, storage, and other services. Some examples from Azure are Cosmos DB, Service Bus, Table Storage, and others. For AWS it would be services like Redshift, DyanamoDB, SQS, and others. Traditional monitoring solutions were not designed to monitor the special services. You will need to monitor these via the cloud provider or via specialized cloud monitoring solutions.

No Infrastructure to Monitor

In the cloud, you don’t have to worry about monitoring traditional IT infrastructure. There are no switches, firewalls, hypervisors, SANs, or similar devices to monitor. The cloud providers are responsible for all of this under the covers. It has all been abstracted away from us, which is a beautiful thing. I just want to setup 100 servers, and I need 10 terabytes of SSD storage. I don’t care how it works!

Summary

If you have taken your app and moved it to some virtual machines in the cloud, you can probably keep monitoring your servers and applications the same way you have been. However, if you are “all in” and taking full advantages of all the Platform-as-a-Service features, you will likely need to re-think how you monitor your applications. Moving to the cloud creates new opportunities and challenges. Cloud monitoring is perhaps both!

Cloud Foundry saves app developers $100K and 10 weeks on average per development cycle. Download the 2018 User Survey for a snapshot of Cloud Foundry users’ deployments and productivity. Find out what people love about the industry standard cloud application platform.

Topics:
cloud ,cloud monitoring ,server monitoring ,faas

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}