For those who follow both the application performance management (APM) marketplace and tech blogs closely, there’s been much discussion recently on the importance of APM vendors providing SaaS (software-as-a-service) based solutions. Advocates of SaaS APM focused on ease of deployment. Opponents argued about customers’ willingness to let their application performance data leave the premises. Now that some time has passed, and passions have cooled, let’s take a look at this in detail.
First of all, when building a SaaS solution there are a number of items from a software perspective that are important:
- Handle High Volume – If you are going to supply a SaaS solution, you have to be able to cope with volume. This can’t always be logically separated. For example, if a customer has a high traffic application. Also, you don’t want to have to buy lots of hardware. Making the best use of the tin is a critical property to have.
- Segregate Data and Users – With lots of tenants, separation is clearly a key item to have. You can’t allow users to see data from other customers. This is a consideration from the ground up.
- Simple, Repeatable Deployment – Your SaaS solution will get a lot of use, and if it doesn’t then something is wrong. To ramp up to several monitored nodes, deployment of any collection technology needs to be simple, reliable and repeatable.
- Isolated Configuration – With a multi tenant setup, each needs to be able to have their own configuration, be it transaction naming, SLAs, or alert profiles. None of these can be generic across the deployment on the SaaS side.
I expect there is nothing new in the above for anyone reading, as they are obvious things a SaaS solution has to have to be viable. But lets look at this from a different side. What if we are deploying an APM solution on-premise, in a large organization? For instance, a large bank, manufacturer or a conglomerate. What do they need to deploy APM?
If you are a large organization, then you will not only have numerous applications, but several departments, divisions, and teams. A vast corporate hierarchy. To make APM effective you want to deploy across as much of the organization as you can. Why wouldn’t you want to spread the benefit and let everyone have reliable applications? The most efficient way to do this is for “Global IT”, or a similarly titled group, to provide APM as a service to their internal customers, the different departments and divisions which comprise an organization. If they are to do this then there are a number of properties the solution needs to have, among many others. These are:
- Handle High Volume – If you are going to monitor hundreds of applications in your company, you have to cope with high volume. Again these can’t always be logically separated, not just because of high volume apps, but also because of interdependent apps which need to be looked at as a whole. Plus as before, no one wants to have to buy 50 servers to provide APM.
- Segregate Data and Users – While there may not be the need for complete separation of data in every case, it will still be required. Do you want a separate physical APM deployment for each division? That would work out as providing an APM service to the rest of the organization but gives a lot of headaches.
- Simple, Repeatable Deployment – Your internal customers are going to have to deploy this themselves, or you end up with 5 people in an APM team going around interviewing application owners, working with operations just to deploy and configure your solution. Clearly this isn’t desirable and it will drive up your cost of ownership significantly.
- Isolated Configuration – Everyone is different, even though their paycheck comes from the same bank account. All applications will require their own settings, SLAs and alerts to go to different places. If you can’t easily keep these separate and allow users to manage these themselves you have given yourself a lot of work.
So while the discussions we have seen about security concerns with sending data off-site and the importance of having something customers can use without deploying back-end APM infrastructure are all valid, there are others to consider. A lot of the features which make a SaaS application viable are also critical for large enterprise deployments. Items which make it possible for large deployments also make it easier for the smaller deployments too. Everyone wants simple and repeatable deployments for example. So while we may hear much clamoring about the need for SaaS-based APM, is it really that different from what we already have with large scale APM deployments?