← All posts

SaaS Factory (The Series) · Part 3 of 4

SaaS Factory (The Series) — Understanding the SaaS Factory Architecture (Part 3/4)

The goal of this post is to provide an introduction to the basic terminology, strategies and patterns applied when building SaaS products…

2 min read483 wordsSections: 4Images: 4Apr 21, 2022

Keywords

Share
Comment
SaaS Factory (The Series) — Understanding the SaaS Factory Architecture (Part 3/4)

The goal of this post is to provide an introduction to the basic terminology, strategies and patterns applied when building SaaS products on AWS. This material presents a mental model that can be used to dive deeper into SaaS technical content.

In the previous post, we talked about: The Benefits and Drawbacks of Each Model and Software as a Service Delivered with Agility. In today’s post, we will talk about Software as a Service Operations.

Software as a Service Operations

SaaS environments require a robust and responsive operations footprint. Having an accurate, proactive view of your system’s health is essential to maximizing the reliability of your SaaS environment. SaaS architecture makes it possible to leverage a rich collection of tools to build robust, tenant-aware views of tenant activity, and policies to manage system health.

Tenant-Level Monitoring

It is important to identify specific strategies and tools that can be combined to support the unique set of operational challenges SaaS providers face. In this sense, analytics, consumption and application metrics can correlate tenant activity with system health to proactively identify and troubleshoot issues. You should also explore techniques for monitoring and managing the different SaaS tenant isolation models, such as silo, pool and so on.

Proactive Operations Model

The multi-tenant context of SaaS requires the entire operation to be observed and analyzed proactively. Establishing a working guide (framework) helps structure this process. Basically, the SaaS monitoring process considers three components:

  • System/Tenant Metrics: You should define tenant SLAs, analyze tenant consumption, set tier thresholds, define the tenant onboarding process, and track activity metrics;
  • Policies: Once the metrics are established, action policies are defined based on their analysis. Policies define the different flows set up from the data collected from the environment;
  • Alerts, automations and notifications: The policies mentioned above define the flow by which, given a certain trigger, alerts and alarms are raised; from these triggers, some actions are fired automatically and customers are duly notified.

This flow ensures a proactive and, above all, reliable operation.

Aggregating Technical and Application Data

Still on monitoring, an important practice is adopting horizontal metrics. Much more than analyzing contexts from a component perspective — databases, servers, functions and so on — it is about understanding the horizontal lifecycle of a service. For example: for a web application to work, different components need to be functional — frontend services, web servers, application servers, database servers… In this case, if a component eventually fails or degrades, the entire service will likely suffer. So it is essential to make sure the monitoring layer analyzes not just the context of each component individually, but the whole service, end to end.

In the next post, we will talk about Software as a Service Architecture.

SaaS Factory (The Series) — How to Build Software as a Service Solutions on AWS

See you then =)

Comments

Every comment is moderated before it appears here. Nothing is published automatically.

Loading…