⌘ The Architecture Reference

Cld saas · Cloud & SaaS · Beginner

SaaS Foundations

SaaS is a business model first — a unified, single-version service experience for tenants — and multi-tenancy means collective management, not necessarily shared infrastructure.

Cld saas Beginner ⏱ 4 min read Complete

🧭 Analogy

A restaurant’s product is the food, but what you actually buy is the service — the table, the timing, the experience, the fact that the kitchen is improved tonight and you benefit immediately without reinstalling anything. SaaS is the same shift: you stop shipping a product to install and start running a service everyone consumes together, always on the latest version.

SaaS is a business model first

Golding’s central, recurring theme is that SaaS is not a technology-first endeavor. It is a business and software delivery model whose core objectives are agility, operational efficiency, innovation, frictionless onboarding, and growth. The architecture exists to realize those goals — not the other way around. His working definition: “SaaS is a business and software delivery model that enables organizations to offer their solutions in a low-friction, service-centric model that maximizes value for customers and providers.”

This is a shift from the traditional installed model — sales-driven, tolerant of per-customer variations and separate versions, pushing vendors toward slow quarterly releases. That model erodes margins and undermines agility as the install base grows.

Customers become tenants

In the unified model, customers are reframed as tenants — temporary occupants who consume only the resources they need. The apartment-complex analogy captures it: the building is shared infrastructure; tenants come and go, drawing on shared resources. The biggest payoff is operational efficiency and economies of scale, plus the ability to deploy an update once so all tenants get it immediately.

The litmus test: same version

The single clearest test of SaaS is that all tenants run the same version. Deploy once, everyone benefits. The moment you maintain per-customer versions, you have slipped into the Managed Service Provider (MSP) model — valid and sometimes a stepping stone, but not SaaS, because version variation reintroduces one-off operational pain.

Redefining multi-tenancy

Historically “multi-tenant” meant shared infrastructure. Golding rejects this. Through a spectrum of examples — fully shared microservices, mixed (shared compute with per-tenant databases, or vice versa), and fully dedicated per-tenant infrastructure — he shows real SaaS blends shared and dedicated resources.

graph LR
SH["Fully shared<br/>(shared microservices)"] --> MX["Mixed<br/>(shared compute,<br/>per-tenant databases)"]
MX --> DE["Fully dedicated<br/>(per-tenant infrastructure)"]
SH -. all multi-tenant if managed collectively .-> DE
He therefore redefines multi-tenant as any environment that onboards, deploys, manages, and operates tenants through a single unified experience, with no correlation to whether infrastructure is shared. He even abandons the term “single-tenant” — a fully dedicated environment is still multi-tenant if managed collectively.

graph TD
TM["Traditional installed model<br/>(per-customer versions)"] --> Q1{"Same version<br/>for all tenants?"}
Q1 -- No --> MSP["MSP model<br/>(not SaaS)"]
Q1 -- Yes --> Q2{"Managed through one<br/>unified experience?"}
Q2 -- Yes --> SAAS["SaaS / multi-tenant<br/>(shared OR dedicated infra)"]
Q2 -- No --> NS["Not SaaS"]

Build the surrounding services first

Don't treat the plumbing as secondary

The cross-cutting “surrounding” services — onboarding, identity, billing, metering, metrics, analytics, deployment, management — are not secondary. They drive the agility, efficiency, and growth benefits of SaaS and should be built front-and-center, even before the application architecture is optimized. Building the app first and bolting tenancy on later is the cardinal mistake.

These services form the control plane — explored in control plane vs. application plane — which acts as a “forcing function” injecting tenancy from day one. SaaS reshapes every role: product owners must value onboarding and time-to-value; engineers, QA, sales, and support all shift to a service-centric mindset. The book is framed as “a foundation, not a bible.”

See also

When to use it — and when not

✅ Reach for it when

  • Defining what 'being SaaS' means for your organization before choosing technology
  • Aligning business and engineering on agility, efficiency, and frictionless onboarding
  • Deciding whether a delivery model is genuinely SaaS or really an MSP

⛔ Think twice when

  • Treating SaaS as a technology-first endeavor and bolting tenancy on later
  • Allowing per-customer version variation (that is the MSP model, not SaaS)
  • Equating multi-tenant strictly with shared infrastructure
cld-saasTenant Isolation Models

Silo, pool, and bridge express how resources map to tenants — but deployment is not isolation; true isolation needs a separate gatekeeper scoped by tenant context.

cld-saasControl Plane vs. Application Plane

Every SaaS environment divides into a control plane that orchestrates all tenants and an application plane where the multi-tenant product features live.

cld-saasTenant Onboarding and Identity

Start with onboarding and identity: a fully automated front door that binds every user to a tenant and carries tenant context downstream as a JWT.

Check your understanding

Score: 0 / 4

1. What is SaaS, fundamentally?

Golding's thesis is that SaaS is a business model first; the architecture exists to realize agility, efficiency, innovation, onboarding, and growth.

2. How does Golding redefine 'multi-tenant'?

There is no correlation to whether infrastructure is shared — even fully dedicated per-tenant resources are multi-tenant if managed collectively.

3. What is the litmus test that distinguishes SaaS from an MSP?

Per-customer version variation reintroduces one-off operational pain. SaaS deploys an update once and every tenant gets it.

4. Why does Golding say the cross-cutting 'surrounding' services should be built front-and-center?

Onboarding, identity, billing, metering, metrics, and management are not secondary — they deliver the SaaS payoff even before the application is optimized.

Comments

Sign in with GitHub to join the discussion.