App reliability with Azure

At Lume, we use a three-phase methodology. This structure helps us to work together with the customer step by step towards a more reliable application environment. 

It all starts with a clear understanding of the current situation and goals. In this first phase, we dive deep into discussions with the client. 

What are the specific concerns? Does the client want a general overview or are there particular issues like slowness or downtime? We need to clarify expectations. That is crucial. 

We examine the technical setup of the application. What does the infrastructure look like? What architectural decisions have been made? This matters because certain design choices (or lack thereof) can impact performance. 

We map out the different workloads: the specific processes or tasks the application handles. A common example is an app that generates payslips monthly and tax statements annually. That yearly task is a heavy workload that only runs once a year. If it shares infrastructure with the daily tasks, it can slow down the entire app during that time. We look for those kinds of ‘hidden’ intensive processes. 

What is the client using today? Which tools? What data is being collected? 

Based on all that information, we create a concrete action plan for the next phase.

At this stage, we’re not yet installing tools or collecting data. It’s still about understanding, analysis, and planning. 

In the second phase, we roll up our sleeves and start implementing and improving monitoring and reliability. This involves several steps: 

We often see a mix of tools and approaches used by internal teams and external partners. Everyone has their own way of doing things, leading to fragmented monitoring that isn’t very effective. Our first step is therefore usually to standardize and centralize. We’re bringing everything together in one place, with one clear set of guidelines. 

Here’s where we differ from platforms like Dynatrace. We believe strongly in the flexibility and strength of Azure’s native ecosystem. We use a core set of tools: 

With those five tools, we can cover almost all monitoring and alerting needs for most scenarios. Yes, expensive tools such as Dynatrace may have highly specific, complex features that are hard to replicate. The key question remains, though: do you really need those? 

Quite often, you’ll pay for a costly suite while only using a fraction. Our approach is more cost-effective and focuses on what truly adds value. For instance, we add business context to monitoring so the impact of technical issues on the business becomes much clearer.

We’ve developed ready-to-go starter packs: sets of alerts and dashboards that provide immediate insights into basic infrastructure metrics (CPU, RAM, slowest DB queries, etc.). This gives you a solid start. Later, we fine-tune them per application and workload. We also offer an IaC Starter Pack (Infrastructure as Code), so new alerts and dashboards can be deployed consistently and automatically.

Once we have the data, we can analyze the application’s health. We assess four key areas: 

This is a crucial step: without health modelling, monitoring is just a good intention. We define what ‘healthy’, ‘degraded’ (reduced performance), and ‘unhealthy’ means per workload. 90% CPU usage might be fine for one workload, but critical for another. By implementing this model: 

If you want complete peace of mind, we also offer managed services. 

We receive and analyze alerts 24/7, create incidents in our system, and handle them. Azure platform issues? We resolve them immediately. Application issues? We escalate them to the appropriate development teams or partners. The client doesn’t have to worry about a thing. 

We identify recurring problems and proactively suggest solutions to prevent them from happening again. 

Optionally, we offer a quarterly review to discuss: