SaaS application monitoring in cloud-native world

Application monitoring has been a No.1 priority for product companies of all stripes for some time. 

In the case of SaaS, however, that priority is magnified even more due to the easy adoption/‘shop-and-drop’ nature of software as a service applications.

Easy come; easy go.

But today, monitoring your SaaS app means confronting two major issues:

1. The many overlapping definitions and the increased number of monitoring areas/solutions 
2. The lack of observability in cloud-native technologies (which have become standard across the industry)

In this piece, we’ll take a look at these problems in depth. 

Problem 1 – there’s a LOT to monitor 

If you Google ‘SaaS monitoring’, there are a lot of words that want to jump in between. 

Some of these monitoring activities are entirely separate from each other; some mean similar things; some are subcategories of others, nested like Russian dolls.

So, let’s take a look at:

• SaaS application performance monitoring 
• SaaS uptime monitoring 
• SaaS cloud/infrastructure monitoring 
• SaaS security monitoring 
• SaaS DevOps monitoring 
• SaaS serverless/containers monitoring 

(That’s a lot of SaaS).

SaaS application performance monitoring

Application performance monitoring (APM) is the catch-all term that covers many related practices. 

It can include cloud monitoring, uptime monitoring, server and network monitoring and key business KPIs such as log-ins and log-outs and other user-based metrics.

However, security monitoring is often treated as separate.

The overall goal of application performance monitoring is to provide an overview of an application’s cloud architecture, as well as a lot of other stuff, to detect and fix end-point issues – hopefully before they impact the end user.

In recent years, APM and support have grown rapidly in scope (for both SaaS and non-SaaS applications), with new solutions and strategies hitting the market as support needs grow more complex.

So, with the first doll opened, let’s go a little deeper.

SaaS cloud/infrastructure monitoring

Cloud, infrastructure and architecture monitoring all essentially mean the same thing. Monitoring the cloud (often cloud-native) architecture components of a SaaS application to see how they impact cost, performance and user experience.

All cloud-native monitoring work (container and serverless monitoring) also falls into this category, although you may find a solution or support partner with a cloud monitoring capability who cannot support these cloud-native elements.

SaaS network monitoring and database monitoring also fall under this umbrella.

SaaS uptime monitoring 

Uptime monitoring means checking that a site is up and able to serve customers. With downtime having a huge negative impact on both SaaS and non-SaaS applications alike, this sort of work is essential.

Uptime monitoring comes in two main forms: active and passive.

• Active uptime monitoring means pinging the site at regular intervals to ensure it’s up and running
• Passive monitoring means using a service to check whether the site is accessible via outside networks, like search engines

This is also where we get into overlap, as downtime may be the result of a cloud or application-level issue.

SaaS security monitoring

Security monitoring usually means carrying out active scans for security and compliance issues, this might cover:

• Scanning the website itself 
• monitoring feeds from the application’s cloud platform 
• Emergency patching 
• Monitoring application assets 

Generally, this sort of work is packaged as VMaaS (vulnerability management as a service). This means a single service that scans and remediates security and compliance issues.

SaaS DevOps monitoring 

Monitoring and observability are key to any CI/CD pipeline or general DevOps effort. 

Monitoring in DevOps might mean revealing the effects of automating deployments on key KPIs or making automatic code changes more observable. For more of our thoughts on SaaS and DevOps, see here.

Problem 2 – the observability of cloud-native architecture in SaaS 

Most of the above falls into the category of APM. But today’s APM practices are very different from those of the pre-cloud-native era. 

A simple way of thinking about it is that cloud-native architectures (which usually means containerised microservices) are more dynamic, with traditional APM tools being built for observing static systems.

Let’s look at some examples:

Microservice-based architectures

Containerised microservice-based applications are inherently dynamic. Instead of single, static servers, these applications are spread across many services in multiple server clusters, which themselves can be disappeared or spun up by Kubernetes or another container orchestration service.

They’re also often multi-language and multi-database. Read more about SaaS and microservices here.

Container workloads 

The workloads running inside containers can vary a good deal. They can deploy databases, Java VMs and more. 

This variability makes it difficult to configure traditional monitoring solutions (and makes manual configuration essentially impossible).

Serverless observability 

If your SaaS application is also using serverless technologies, you’ll face additional APM challenges. Serverless applications are stateless and ephemeral, making them difficult to monitor. 

Additionally, you may incur more overhead by calling a service that has spun itself down.

So, what’s the solution? Cloud-native monitoring for SaaS 

Cloud-native monitoring solutions address the observability problems looked at above, as well as covering the many strands of a modern application monitoring strategy. 

But these types of solutions aren’t one size fits all. You could opt either to keep it all in-house, or tag in a dedicated partner.

Keeping it all in-house 

This option is only really recommended for organizations with a vast amount of resources. This requires keeping a staff of SREs (site reliability engineers), DevOps/DevSecOps engineers and full-stack developers as well as devoting a significant amount of their time to monitoring and support.

You’ll also need to invest heavily in monitoring tools such as Datadog, DataCake, various DevOps tooling solutions and more.

There is some advantage to getting a 100% customised solution, but the resource investment makes it unattractive and unattainable for most

Tag in a partner 

Outsourcing your monitoring and support means going with a dedicated support partner. 

However, it’s really worth looking at the breadth of the service offered, and the technology supporting it.

Going back to our discussion of the variability of supporting a SaaS platform, you can see why detailing each of these key areas is important.

You may find a support partner that monitors your cloud but focuses less on your application. Likewise, you may find a partner lacking the tools and skills to gain observability in cloud-native environments.

In some cases, this might not matter, as you may only need a support partner to fulfil one aspect of your monitoring strategy. 

However, it’s always worth talking through each aspect of the work to see where their exact capabilities lie.

How we can help

As a cloud-native MSP with a great record of monitoring and supporting cloud-native SaaS applications, we’re perfectly placed to take on your SaaS monitoring strategy.

With teams of full-stack developers, DevOps engineers and a bespoke, tech-enabled service purpose-built for the dynamic, distributed world of cloud-native – we’ve got you covered.