SaaSCron: Cloud Models

DaaS vs SaaS: what desktop as a service adds to the cloud stack

Ricardo Machado — Fri, 23 Oct 2026 16:00:00 GMT

Your staff work from laptops you do not control, a contractor needs a Windows machine for three months, or an old desktop application has no web version. Someone suggests “DaaS”, and you need to know how it differs from the SaaS tools you already pay for. Desktop as a service (DaaS) rents you a complete Windows desktop that runs in a provider’s data center; software as a service (SaaS) rents you one application.

The two solve different problems, and they often run side by side. This guide places DaaS in the cloud stack, shows who manages what, works through real prices from one provider and clears up the second meaning of the acronym. For the basics of SaaS itself, see What is SaaS?.

DaaS in plain terms

Think of it like the difference between renting a furnished office and using a print shop. The furnished office comes with a desk, a chair, a computer and a filing cabinet, and you arrange it as you like. The print shop does one job for you, and you never touch its machines.

DaaS is the furnished office. You get a whole desktop: an operating system, a start menu, files and any applications you install. You reach it from a laptop, a tablet or a browser, but the desktop itself runs on the provider’s servers. SaaS is the print shop: one application, such as email or a CRM, that the vendor runs and updates for you.

Where DaaS sits in the cloud stack

A widely cited reference for cloud service models is NIST Special Publication 800-145, “The NIST Definition of Cloud Computing”, published in September 2011. It names three service models: infrastructure as a service (IaaS), platform as a service (PaaS) and SaaS (NIST SP 800-145). DaaS is not one of them. It is a packaged offering that providers built later, on top of the same layers.

How DaaS is described depends on how much the provider runs:

Microsoft Windows 365 calls itself “a cloud-based software-as-a-service (SaaS)” that creates Cloud PCs, one Windows virtual machine per user. It is sold “as a separate license per user for a fixed monthly fee” (Microsoft Learn, What is Windows 365?). The Business edition is for companies of up to 300 seats.
Azure Virtual Desktop runs in your own Azure subscription. Microsoft’s documentation says you “only manage the image and virtual machines you use for the sessions”, not the gateway and broker roles (Microsoft Learn, What is Azure Virtual Desktop?). That is closer to IaaS with a managed control plane.
Amazon WorkSpaces offers both persistent personal desktops and shared pools, billed monthly or by the hour (AWS WorkSpaces pricing).

So DaaS is not a fourth layer with a fixed place. It is a product type that can look like SaaS or like IaaS, depending on who manages the virtual machines. For the line between the three NIST models, see SaaS vs PaaS.

Who manages what

The table compares a SaaS application with the two ends of the DaaS range. It is assembled from the documentation above; check your provider’s own shared-responsibility page before you sign.

Layer	SaaS application	DaaS, fully managed (Windows 365 style)	DaaS, self-managed (Azure Virtual Desktop style)
Data center, servers, network	Vendor	Provider	Provider
Virtual machines	Vendor	Provider, created automatically per license	You
Desktop image	Not applicable	Provider’s image, or your own on Enterprise	You
Applications installed on the desktop	Not applicable	You	You
The application itself	Vendor	You (or its own SaaS vendor)	You (or its own SaaS vendor)
Users, access and data	You	You	You

The bottom row never moves. In every model, you decide who has access and you own your data. The table shows the main trade: DaaS hands you a whole computer to manage remotely, while SaaS hands you a finished application.

Worked example: personal desktops vs a shared pool on AWS

AWS publishes worked pricing examples for its US West (Oregon) Region on the WorkSpaces pricing page (checked October 17, 2026). Two of them:

A Windows Standard personal desktop at a fixed $44 per month (AlwaysOn billing).
A Standard bundle in WorkSpaces Pools at $0.10 per hour, plus a Remote Desktop Services Subscriber Access License (RDS SAL) fee of $4.19 per user per month.

A personal desktop keeps the user’s machine and settings between sessions. A pool hands out a fresh desktop from a shared set, so it suits staff who use the same few applications and keep files elsewhere.

Example: a team of 25 people, each using a cloud desktop for 140 hours a month (about seven hours a day on 20 working days). The hours are an assumption; the prices are AWS’s examples.

Option	Calculation	Monthly cost
Personal desktops, AlwaysOn	25 x $44	$1,100
Pools, compute	25 x 140 hours x $0.10	$350
Pools, licenses	25 x $4.19	$104.75
Pools, total	$350 + $104.75	$454.75

At what usage do the two cost the same per user? Solve $4.19 + $0.10 x hours = $44: hours = ($44 - $4.19) / $0.10 = 398.1 hours a month. Below about 398 hours, the pool is cheaper per user in this example. The catch is not the price: a pool is non-persistent, so it fails users who need their own installed software or local settings. Price both on the AWS calculator for your Region before you decide.

The other DaaS: data as a service

The same acronym also stands for data as a service: a provider sells access to a dataset, usually through an API or a scheduled file delivery. Examples of the category include company records, address validation and market prices. Data as a service has nothing to do with desktops. When a vendor or a colleague says “DaaS”, ask which one, before anyone writes a budget line.

Common mistakes

Expecting DaaS to replace your SaaS tools. A cloud desktop still needs email, a CRM and storage, often bought as separate SaaS. Why it happens: “everything in the cloud” sounds like one purchase. Instead: list the applications that will run inside the desktop and price them separately.
Comparing per-user prices without the usage pattern. In the example, the same 25 people cost $1,100 or $454.75 a month depending on the billing type. Why it happens: price lists show one number per bundle. Instead: estimate hours per user first, then compare monthly and hourly billing.
Assuming the provider manages everything. With a self-managed service such as Azure Virtual Desktop, the image and the virtual machines are yours to manage. Why it happens: the word “service” suggests the provider does it. Instead: read the provider’s documentation on what you manage, as quoted above.
Forgetting license fees beside compute. AWS’s pool example adds $4.19 per user per month for a Remote Desktop license. Why it happens: hourly compute prices are the headline. Instead: add every per-user license to the comparison.

For how Microsoft splits responsibility in its office suite, see Microsoft 365 as SaaS.

Sources

NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
Microsoft Learn, What is Windows 365? and What is Azure Virtual Desktop?, checked October 2026.
AWS, Amazon WorkSpaces pricing, pricing examples for US West (Oregon), checked October 2026.

In three sentences

Desktop as a service rents you a whole cloud desktop that you manage remotely, while SaaS rents you one finished application that the vendor runs. DaaS is not one of NIST’s three service models: fully managed products such as Windows 365 describe themselves as SaaS, while Azure Virtual Desktop leaves the virtual machines to you. With AWS’s Oregon examples, 25 personal desktops cost $1,100 a month and a 140-hour shared pool $454.75, so estimate usage hours before you choose.

SaaS vs on-premise software: costs, control and security compared

Ricardo Machado — Mon, 19 Oct 2026 21:00:00 GMT

Your company has to replace a business application, and the shortlist has a SaaS product and a version you would install on your own servers. You need to compare cost, control and security on one page before anyone signs. On-premise software runs on hardware you own or rent, operated by your own staff. SaaS runs on the vendor’s infrastructure, and you use it over the internet, usually for a subscription. Between the two sits single-tenant or “private” SaaS, where the vendor runs a separate copy just for you.

The license price is rarely what decides it. Staff time, upgrades, security work and the rules your data falls under usually weigh more. This guide shows who runs what in each model, a five-year cost example with every assumption labeled, and a decision table for regulated data. For the definition of SaaS, see What is SaaS?. For how SaaS reaches you over the network, see SaaS in cloud computing.

On-premise and SaaS in plain terms

Think of getting to work. Owning a car means you choose it, modify it, park it, insure it and fix it when it breaks; you pay a lot up front and a little every month. A taxi means you pay per ride and the driver handles the rest, but you cannot repaint the taxi. A car with a driver leased only to you sits between them: nobody else rides in it, and it costs more than a taxi.

On-premise is the owned car. Multi-tenant SaaS is the taxi. Single-tenant SaaS is the leased car with a driver.

Who runs what

The US National Institute of Standards and Technology (NIST) defines SaaS as “the provider’s applications running on a cloud infrastructure”, reached through a browser or a program interface. You do not manage the servers, the operating system or “even individual application capabilities” (NIST SP 800-145). Microsoft’s shared responsibility matrix adds a line that holds in every cloud model: “For all cloud deployment types, you own your data and identities.”

Area	On-premise	Single-tenant SaaS	Multi-tenant SaaS
Data center, hardware, network	You	Vendor	Vendor
Operating system and patches	You	Vendor	Vendor
Application upgrades	You decide when	Usually agreed with you	Vendor’s calendar
Customization	Anything, including code	Often deeper than multi-tenant	Configuration and extensions
Data, settings, users and access	You	You	You
How you pay	License, maintenance, hardware, staff	Subscription, usually higher	Subscription

The rows for hardware, operating system and data follow NIST’s definition and the on-premises and SaaS columns of Microsoft’s matrix. The upgrade, customization and payment rows describe how the models usually work; your contract sets the actual terms.

Five-year cost example

Example (hypothetical): a 50-person company choosing an application. Every input below is an assumption for illustration, not a vendor’s price.

On-premise:

License: $60,000 once, covering up to 100 users.
Server hardware: $15,000 once.
Maintenance and support: 20% of the license a year, so $12,000 a year.
Staff time: a quarter of one administrator’s year at $100,000, so $25,000 a year.
Five years: $60,000 + $15,000 + 5 x ($12,000 + $25,000) = $75,000 + $185,000 = $260,000.

SaaS:

Subscription: 50 users x $40 x 12 months = $24,000 a year.
Staff time: a tenth of one administrator’s year, so $10,000 a year.
Setup: $10,000 once.
Five years: $10,000 + 5 x ($24,000 + $10,000) = $10,000 + $170,000 = $180,000.

SaaS costs $80,000 less over five years here, and much less up front. Year one is $112,000 on-premise ($60,000 + $15,000 + $12,000 + $25,000) against $44,000 for SaaS.

Now double the users to 100. The on-premise license already covers them. The SaaS subscription becomes 100 x $40 x 12 = $48,000 a year, and five years cost $10,000 + 5 x ($48,000 + $10,000) = $300,000. On-premise, at $260,000, is now cheaper by $40,000. Per-user pricing scales with headcount; an owned license with fixed staff costs does not. Run this with your own numbers before you decide.

Security and compliance

Neither model is secure by default. On-premise, every layer is yours, from the door of the server room to the user list. Microsoft, which sells cloud services, lists common gaps in on-premise environments: delayed patching, weak physical security, incomplete network monitoring, outdated hardware and untested backups. In SaaS, the vendor carries those layers, and you keep data, identities and settings.

Regulated data adds paperwork in both models. A vendor’s ISO/IEC 27017 or similar certificate tells you how it runs its side; see ISO/IEC 27017 explained for how to read one.

Decision table for regulated data

Situation	Leans toward	What to check
The system must run with no internet connection	On-premise	SaaS is reached over the network by definition (NIST).
US health data (electronic protected health information)	Either	The HIPAA Security Rule lets a business associate hold that data for a covered entity only if the entity obtains “satisfactory assurances” of safeguards (45 CFR 164.308(b)(1)). Ask for the agreement before the trial.
A US federal agency or contract that requires FedRAMP	SaaS with an authorization, or on-premise	Look up the service in the FedRAMP Marketplace, which listed 544 certified services on October 17, 2026.
Data must stay in one country	Single-tenant SaaS, or SaaS with a region commitment	Get the data location written into the contract, not only into the sales deck.
Core processes need code changes	On-premise or single-tenant SaaS	Multi-tenant SaaS limits you to configuration and extension tools.
No staff to run servers	Multi-tenant SaaS	Count the staff hours in the cost example before you decide otherwise.

Common mistakes

Comparing the license with the subscription and nothing else. In the example, staff time is $125,000 of the $260,000 on-premise total. Why it happens: the license is the only number on the quote. Instead: add hardware, maintenance and staff time for five years, as the example does.
Assuming on-premise is safer because the servers are in your building. Physical control does not patch software. Why it happens: owning the hardware feels like control. Instead: list who patches, monitors and tests backups, and check that someone actually does.
Assuming SaaS makes you compliant. The vendor’s certificate covers the vendor’s side; access, settings and data stay with you. Why it happens: compliance pages on vendor sites read like guarantees. Instead: map each rule you follow to the party that carries it.
Ignoring growth. At 50 users SaaS wins by $80,000; at 100 users on-premise wins by $40,000. Why it happens: the comparison is run once, for today’s headcount. Instead: run the cost at today’s users and at your three-year forecast.

For the boundary between SaaS and the platforms you build on, see SaaS vs PaaS.

Sources

NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
Microsoft Learn, Shared responsibility in the cloud, updated August 24, 2026.
45 CFR 164.308(b)(1), Electronic Code of Federal Regulations, checked October 2026.
GSA, FedRAMP, checked October 17, 2026.

In three sentences

On-premise software runs on infrastructure you own and staff, multi-tenant SaaS runs on the vendor’s shared infrastructure, and single-tenant SaaS gives you a vendor-run copy of your own. In the hypothetical example, SaaS is $80,000 cheaper over five years at 50 users and $40,000 more expensive at 100 users, because per-user pricing grows with headcount. In every model you keep responsibility for your data, users and settings, so pick by cost over time, customization needs and the rules your data falls under.

SaaS vs PaaS: where the line is, with real examples

Ricardo Machado — Sat, 17 Oct 2026 11:00:00 GMT

You need a small internal tool, say an approval form for purchase requests, and a colleague asks whether you want a SaaS product or “something on a PaaS”. You want the difference in one line. With PaaS (platform as a service) you bring the application code and the provider runs everything underneath it. With SaaS (software as a service) the provider brings the code too, and you only use the finished product.

The line matters because it decides who writes, fixes and updates the application, and that is where most of the cost hides. For the full definition of SaaS, see What is SaaS?; for how SaaS reaches you over the network, see SaaS in cloud computing.

PaaS and SaaS in plain terms

Think of food. Renting a fully equipped commercial kitchen by the hour is PaaS: the owner keeps the ovens, gas and cleaning running, and you bring the recipe and cook. Ordering from a restaurant is SaaS: the recipe, the cooking and the kitchen are theirs, and you choose from the menu.

The US National Institute of Standards and Technology draws the same line in SP 800-145. PaaS lets you deploy “consumer-created or acquired applications created using programming languages, libraries, services, and tools supported by the provider.” SaaS gives you “the provider’s applications running on a cloud infrastructure.” In both, you do not manage the servers or the operating system. The difference is whose application it is.

Who manages what

Microsoft publishes a shared responsibility matrix for its cloud. The rows below are its PaaS and SaaS columns, with one row added from the NIST definitions: who writes the application code.

Responsibility	PaaS	SaaS
Application code	You	Provider
Customer data, settings, identities	You	You
Applications (configuration, access)	Shared	Shared
Network controls	Shared	Provider
Operating system, hosts, data center	Provider	Provider

Two rows stay with you in every model: your data and who can sign in. Microsoft states it directly: “For all cloud deployment types, you own your data and identities.” Moving from PaaS to SaaS hands over the code and the network controls, not your data.

Eight real products, classified

Microsoft’s own page names several of its products as PaaS or SaaS examples, which makes the boundary easy to see inside one vendor. The table adds three products from other vendors.

Product	Model	You bring	Source of the classification
Azure App Service	PaaS	Web app code	Microsoft
Azure Functions	PaaS	Function code	Microsoft
Azure SQL Database	PaaS	Schema, queries, data	Microsoft
Heroku	PaaS	App code, add-on choices	Heroku docs: you deploy your own code
Microsoft 365	SaaS	Users, settings, content	Microsoft
Dynamics 365	SaaS	Users, settings, records	Microsoft
Google Workspace	SaaS	Users, settings, content	Google Workspace as SaaS
Salesforce sales applications	SaaS	Users, settings, records	Runs Salesforce’s code; you configure it

A database service sits in the PaaS column even though you write no application code for it. You still design the schema and the queries, which is your code in another form. That is a useful test: if you are writing logic that the provider will run, it is PaaS.

Worked example: an internal app on PaaS vs a SaaS tool

Heroku publishes its prices in its usage and billing documentation (as of October 2026): “a Basic dyno costs US$7 per month” and “an Essential-0 Heroku Postgres database costs US$5 per month,” prorated to the second.

Example: you need a purchase-approval tool. Option A is a small app you build and run on Heroku. Option B is a SaaS approvals tool. The SaaS price and the maintenance time are assumptions for illustration; the Heroku prices are published.

Option A hosting: one Basic dyno ($7) + one Essential-0 database ($5) = $12 a month.
Option A maintenance: 4 hours a month of a developer’s time (fixes, updates, security patches) at $75 an hour = $300 a month.
Option A total: $12 + $300 = $312 a month, whatever the number of users.
Option B: a SaaS tool at $10 per user per month. For 10 users, 10 x $10 = $100 a month. For 50 users, $500 a month.
Break-even: $312 / $10 = 31.2 users. Up to 31 users the SaaS tool costs less; from 32 users, the PaaS app does, if the maintenance estimate holds.

Hosting is 4% of Option A’s cost ($12 of $312). The developer’s time is the real price of PaaS, which is why the hosting line alone misleads.

The platform can change under you

A PaaS carries a risk that a spreadsheet does not show. On February 6, 2026, Heroku announced that it “is transitioning to a sustaining engineering model focused on stability, security, reliability, and support,” and that enterprise contracts “will no longer be offered to new customers.” Customers paying by credit card can continue to use it.

Your app keeps running in that situation, but the platform’s roadmap is no longer growing, and your code is written for it. SaaS has the same risk in a different shape: the vendor can change or retire the product. In both models, ask what an exit would cost before you start.

Common mistakes

Comparing hosting fees and ignoring maintenance. On PaaS you own the code, so you own its bugs and updates. Why it happens: the hosting price is the only number on the pricing page. Instead: add developer hours, as in the example, before you compare with a SaaS subscription.
Thinking PaaS means no security work. Your data, identities and application configuration stay yours in both models, per Microsoft’s matrix. Why it happens: “the provider manages the servers” sounds like “the provider handles security”. Instead: list the rows that stay with you and assign each one an owner.
Classifying by vendor instead of by product. One company can sell SaaS and PaaS side by side, as Microsoft and Salesforce do. Why it happens: the brand is easier to remember than the product. Instead: ask, for each product, whose code runs.
Building on a PaaS for a job a SaaS tool already does. Custom code is worth it when the workflow is yours alone. Why it happens: a small app looks cheap to build. Instead: check the break-even user count, then decide.

Sources

NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
Microsoft, Shared responsibility in the cloud, checked October 2026.
Heroku, Usage and billing, checked October 2026.
Heroku, An update on Heroku, February 6, 2026.

In three sentences

PaaS runs code you write on infrastructure the provider manages, while SaaS runs the provider’s own finished application for you. In both models your data, your identities and your settings remain your responsibility. When you compare the two, count the developer hours a PaaS app needs, because hosting is often the smallest part of its cost.

SaaS in cloud computing: how software reaches you over the internet

Ricardo Machado — Fri, 16 Oct 2026 15:00:00 GMT

Your cloud computing course lists SaaS as one of three service models, next to IaaS and PaaS, and you can recite the acronyms but cannot picture what actually happens when you use one. Here is the picture: SaaS is the top layer of the cloud, the layer where a finished application runs on the provider’s machines and reaches you over the internet, so that you never touch the servers underneath it.

This guide follows one click from your browser to the vendor’s database and back, explains why one system can serve thousands of companies without mixing their data, and turns an uptime promise like “99.9%” into minutes you can plan around. The definition of SaaS itself is in What is SaaS?.

The cloud in plain terms

Think of electricity. A century ago a factory that wanted power built a generator in the basement, bought the fuel and hired someone to keep it running. Today the factory plugs into the grid, pays per kilowatt-hour and never thinks about the power station. The grid is shared by everyone, metered for each customer, and still delivers power to one building without affecting the next.

Cloud computing is the grid for computing. The US National Institute of Standards and Technology defined it in SP 800-145 (September 2011) as “a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources” that “can be rapidly provisioned and released with minimal management effort or service provider interaction.” The same document names three service models, which differ only in how much of the stack you rent:

IaaS (infrastructure as a service): you rent “processing, storage, networks, and other fundamental computing resources” and run your own software on them. The generator is theirs; the wiring is yours.
PaaS (platform as a service): you deploy your own applications onto a platform the provider runs, “using programming languages, libraries, services, and tools supported by the provider.”
SaaS (software as a service): you use “the provider’s applications running on a cloud infrastructure.” You do not manage “network, servers, operating systems, storage, or even individual application capabilities.”

SaaS is the only one of the three where the thing you rent is the finished product. That is why it is the model your non-technical colleagues use every day without knowing the word.

What happens when you click Save

Example: you edit a customer record in a web-based CRM and click Save. In the half second before the green tick appears, five things happen. The table shows where each step runs and who is responsible for it. Specific product names are left out because the shape is the same for almost every SaaS product.

Step	What happens	Where it runs	Who owns it
1	Your browser packages the change into an HTTPS request	Your device	You (device, browser, network)
2	The request reaches the vendor’s edge: DNS, TLS, a content delivery network, a firewall	A data center near you, run by the vendor or its CDN provider	Vendor
3	An application server checks your session, your permissions and the rules of the product	The vendor’s application tier, usually on rented IaaS or PaaS	Vendor
4	The database writes the change to the rows that belong to your company, and only yours	The vendor’s database tier	Vendor (the engine), you (the content)
5	A response travels back and the page updates	Your device	You

Two things in that table matter for a buyer. The application and the database (steps 3 and 4) usually run on a cloud provider the vendor rents from, so “SaaS” is often built on top of “IaaS” or “PaaS”: the layers stack. And the only part you control is the two ends. If step 1 fails because your office Wi-Fi dropped, the vendor’s status page will show green, and it will be right.

How one system serves thousands of companies

Most SaaS products are multi-tenant: one running copy of the software, one set of servers, many customers. Each customer is a tenant. The product tags every row of data with the tenant it belongs to, and every query carries that tag, so your company’s records never appear in another company’s screen. It is the apartment building again: shared structure, separate keys.

Multi-tenancy is the economic engine of SaaS. The vendor patches one system instead of a thousand, rolls out a feature once, and spreads the cost of hardware and engineers across every customer. That is how a product can cost $7 per user per month. The trade-off is that you share capacity and release schedules with everyone else, which is why large customers sometimes pay for single-tenant or dedicated versions.

Access is the other half. A browser is the usual client, but most products also expose an API (application programming interface) so that other software can read and write the same data. The NIST definition covers both: “a thin client interface, such as a web browser (e.g., web-based email), or a program interface.” When your CRM shows up inside your email tool, that is the API at work.

What 99.9% uptime means in minutes

SaaS vendors publish an uptime commitment in a service level agreement (SLA): the share of time the service promises to be available, measured per calendar month, with service credits if it misses. Google Workspace commits to a monthly uptime of 99.9% and credits 3, 7 or 15 days of service when uptime falls below 99.9%, 99.0% or 95.0% respectively (Google Workspace SLA, checked October 2026). Atlassian commits to 99.9% for its Premium cloud plans and 99.95% for Enterprise (Atlassian SLA, effective April 30, 2026).

Percentages hide the size of the promise. Minutes do not.

Example: a 30-day month has 30 x 24 x 60 = 43,200 minutes. A year has 365 x 24 x 60 = 525,600 minutes. The allowed downtime is the remaining percentage of those minutes: at 99.9%, it is 0.1% of 43,200 = 43.2 minutes a month.

Uptime commitment	Allowed downtime per 30-day month	Allowed downtime per year
99%	432 minutes (7.2 hours)	5,256 minutes (3.65 days)
99.9%	43.2 minutes	525.6 minutes (8.76 hours)
99.95%	21.6 minutes	262.8 minutes (4.38 hours)
99.99%	4.3 minutes	52.6 minutes

Each extra nine cuts the allowed downtime by ten. The difference between 99.9% and 99.99% is the difference between a 43-minute outage during your month-end close and a 4-minute one. Read the SLA for how uptime is measured (scheduled maintenance is often excluded) and what the credit is: in Google’s case, days of service added to your subscription, not cash.

Common mistakes

Thinking “the cloud” is one server somewhere. A SaaS product is dozens of components across several data centers: edge, application tier, database, backups, each with its own failure modes. Why it happens: the word suggests one place. Instead: when a vendor says “hosted in the cloud”, ask which provider, which regions, and what the recovery plan is if one region fails.
Thinking multi-tenant means other customers can see your data. Tenants share the system, not the data; isolation is enforced in the software and tested in the vendor’s security audits. Why it happens: “shared” sounds like “visible”. Instead: ask for the vendor’s SOC 2 report or ISO 27001 certificate, which cover exactly this control, and check how the product handles your own sharing settings, which are the far more common leak.
Blaming the vendor for your own outage. If step 1 of the Save table fails, nothing the vendor does will help. Why it happens: the symptom is identical, the app does not load. Instead: check the vendor’s status page and a second website before opening a ticket, and keep a mobile hotspot for the day the office line goes down.
Reading 99.9% as “almost never down”. It is 43 minutes a month, and the SLA only pays out when the vendor misses it. Why it happens: three nines sound like a rounding error. Instead: convert to minutes, compare with the cost of an hour without the tool, and decide whether the Enterprise tier’s extra nine is worth its price.

Sources

NIST, SP 800-145, The NIST Definition of Cloud Computing, September 2011.
Google, Google Workspace Service Level Agreement, checked October 2026.
Atlassian, Service Level Agreement for Atlassian cloud products, version effective April 30, 2026.

In three sentences

SaaS is the top layer of cloud computing: the provider runs a finished application on shared infrastructure and you reach it through a browser or an API without touching servers, operating systems or storage. One running system serves many companies as separate tenants, which is what makes a few dollars per user per month possible. An uptime promise of 99.9% allows 43 minutes of downtime in a 30-day month, so convert every SLA to minutes before you decide what it is worth.