What is the Impact of PaaS on APM?
by October 21, 2014

Filed under: Cloud Computing, Industry Insights

In theory, since PaaS applications can be built using common standards and tools, it should be the same for building capabilities to monitor those applications. With less customization there should be easier monitoring, right? Well, if the content of the article, “Study: PaaS Market to Top $6.94B by 2018,” written by Chris Talbot in Talkin’ Cloud holds true, companies would actually want to closely assess whether their APM tools will pass muster in a PaaS environment. Here’s why:

1. PaaS platforms tend to specialize in a certain programming language, so if an APM solution doesn’t monitor that language, it can’t help anyone inside of that PaaS environment. If the support is not as good as a competitor’s there, they’re really not going to be able to compete within that environment, even if they do the integration work. However, if an APM solution does support that language, and supports it well, any insight it adds that’s specific to that PaaS environment will be extremely useful.

2. PaaS platforms have a lot of abstractions and hidden layers, so there are areas in those environments in which a monitoring solution won’t be able to capture insight:

    • Routing: Heroku’s routing system is one of those areas, yet it’s very important to monitor its performance, as illustrated in the article, Taming of the Queue.
    • Machine Configuration: Another area that an APM solution might not be able to monitor is the configuration of file synchronization because it can’t get full access to the machine. It may have access to the programming language that’s running inside of it, but it doesn’t have access to everything happening on the servers.
    • Proprietary Extensions: A PaaS environment may have components that are proprietary — custom versions of the server and custom extensions to a language. There’s some secrecy with PaaS providers regarding their components because that’s how they’re able to scale out that environment and not worry about competitors. Therefore, an APM vendor won’t be able to monitor those components unless it can work with the PaaS provider.
    • Multi-tenant Services: Many PaaS environments contain shared services, which can be a problem for certain kinds of monitoring tools. Multi-tenant database instances are fairly common. If the monitoring tool agent needs to talk to the database to get data out of it and it is multi-tenant, the tool may not have the access to be able to do that. If it doesn’t have another way of getting that database information in that PaaS environment, it’s never going to be able to provide database metrics.
    • External Services: A PaaS environment also tends to use a number of external APIs, another area in which a monitoring tool could miss data. Developers choose PaaS because it’s convenient, and they turn to an API because the servers and the PaaS tend to be smaller and less powerful — it’s a good way to offload the work from them. If an APM solution doesn’t have the ability to monitor APIs, or its ability is not very strong, then that’s going to be a weak point in a PaaS environment.

The case for monitoring your PaaS

There is a compelling case for internal monitoring if you’re running on top of a PaaS. Each of the individual services on the PaaS are built and scaled by the platform, but the application itself isn’t their responsibility. No matter how much you standardize, there will always be performance issues you need to monitor and you need a tool to do that.

PaaS providers also have their own complexity, internally. They’ll have multiple services — an account system and a web GUI for billing the PaaS, another web GUI system to manage configured add-ons, and a service to manage the configuration on the PaaS servers. Even if the servers are running, if new configuration settings can’t be pushed to them, there’s going to be a service degradation. The company might even use a service to access its performance data. There are lots of services in the PaaS ecosystem that it makes sense to monitor, so there’s the internal use case of keeping all the servers running but also optimizing all the infrastructure pieces that make the PaaS so easy to use.

Next generation of PaaS

Looking forward, the trend has been for PaaS servers to become smaller and smaller, yet you do need to monitor all those servers. If your company’s monitoring tool is not oriented around supporting many small environments, it could be less cost-effective or it could exhibit scaling problems. Also, individual servers are a lot more ephemeral than they used to be. They may only exist for hours or even less than an hour instead of for days as they once did. As a result, if your monitoring tool is oriented around the idea of a server existing for a long time, you may not actually be able to cope very well with an environment where servers just disappear and reappear without anyone ever explicitly saying that.

No matter how you slice it, every application is constantly evolving, requiring careful planning to scale effectively. PaaS providers can help on, but it doesn’t mean monitoring doesn’t have its place.

Get TraceView on Heroku

Sign up for your free account, and start monitoring Ruby on Heroku in less than 5 minutes Get TraceView