Cloud technologies are the hosted systems a SaaS company uses to run the product, keep records, decide who is allowed in, and talk to other software. The customer never buys those systems. They buy a login and a job that finishes. The company buys the rooms underneath.
People say we moved to the cloud and mean one of four rooms. Hosting is where the app process lives. Data is where the truth lives. Identity is who gets a key. Integration is how other tools hear about a change. Mix the rooms and every outage sounds the same: the cloud is down. It is rarely the whole cloud. It is one room.
This page is a map of those four rooms for a team that sells software, not a catalog of every AWS badge.
What cloud technologies means when you sell a subscription
If you sell Software as a Service, you already made a promise. The customer does not install a box. You keep the lights on. Cloud technologies are how you keep that promise without owning a raised floor.
They are not a personality. A startup on a single managed database and a hosted app platform is using cloud technologies. So is a firm with three regions and a service mesh. The difference is how many rooms you staff, not whether you are allowed to say cloud.
The useful test is ownership. If a vendor can take the hardware away and your product still has a place to run, you are in this neighborhood. If the product dies when one laptop sleeps, you are not.
Hosting: where the app process lives
Hosting is the room that answers when a user hits your URL. Something has to accept the request, run your code, and send a page or a JSON payload back.
That something might be a virtual machine you patch. It might be a platform that takes a git push. It might be a container image a provider schedules for you. It might be a function that wakes for one event. Those are different products. They are the same room: a place for the process.
SaaS hosting has a shape that a brochure VM does not. You need more than one copy of the app if you care about a deploy that does not take the login down. You need a place that is not production so you can break things. You need a way to ship a change without a person SSHing in on a Friday.
What good hosting looks like for SaaS
A request has a path that you can draw. DNS, load balancer, app, back to the user.
A release is a repeatable action. The same artifact that passed staging is the artifact that production runs.
A dead copy is replaced without a war room. That can be a platform restart or a container scheduler. It should not be a founder on a phone in a parking lot.
What hosting is not
Hosting is not the database. Putting the app and the only copy of customer data on one box feels simple. It makes every deploy a data event.
Hosting is not the CDN by itself. A cache in front of a down origin is a faster way to show yesterday.
Hosting is not multi-cloud. Two providers with no way to fail over is two invoices.
You also need two more places that look like production and are not. One place to break a release. One place that uses the same shape of services with fake or masked data. A demo from a laptop convinces a room. It does not convince the first real tenant.
If the team cannot say where a request dies, hosting is a pile of instances with a logo.
Data: where the truth lives
Data technologies are the systems that remember. Billing status. The document the customer uploaded. The event that said the invoice was paid. If hosting is the conversation, data is the memory.
SaaS data is not one product. A primary database holds the records the app treats as law. Object storage holds files that should not live in that database. A warehouse or analytics store holds copies for questions the production database should not answer during lunch rush. A queue holds work that is allowed to wait.
The failure mode is treating all of those as the same bucket because they are all in a cloud console.
The record that must not fork
For each object, pick a writer. The subscription lives in billing or it lives in the app database. It should not live in both as equals. Copies are allowed. Two writers are how a customer is canceled and active in the same afternoon.
Backups are part of the data room. A snapshot you have never restored is a story. Restore into a throwaway environment on a calendar, not after the incident.
Tenancy is a data design, not a checkbox
SaaS data has neighbors. Two companies share a platform and must not share a row. That can mean a column on every table, a schema per tenant, or a database per tenant. Each choice changes backups, migrations, and the blast radius of a bad query.
The identity room can say which tenant a login belongs to. The data room has to enforce it. If enforcement is only in the app layer, one missing where clause is a breach. This is why data technologies for SaaS are not generic hosting add-ons. They are the product.
Files, events, and the warehouse
Files belong in object storage with keys and a plan for leaving. Events belong in a queue or a log when the next step can happen later: send the email, build the export, update search. The warehouse belongs to questions. It should not be the place the app checks before it lets a user in.
Encryption and access on these stores are data work, not a hosting afterthought. A locked app in front of an open bucket is a locked door on a room with no wall.
Identity: who is allowed in
Identity technologies decide whether a person or a machine is who they claim, and what they may touch after that.
For SaaS this room has two floors. The first floor is your customer: the admin at the buyer company, the teammate they invite, the API token their script holds. The second floor is your staff: the engineer who can open production, the support agent who can impersonate a tenant, the contractor who should not.
Those floors use similar tools and must not share the same god account.
Customer identity
Sign-in should be boring. SSO for the buyers who require it. A second factor for everyone else. Tenant isolation that does not depend on the app remembering to filter by company_id in every query.
Tokens for machines need an owner, an expiry, and a way to revoke without a database hunt. A token that lives in a ticket from 2023 is not identity. It is a spare key under the mat.
Staff identity
Production access through the same single sign-on the company already uses. Short sessions. A reason recorded when someone becomes the customer for a support call.
Cloud consoles are identity too. The person who can delete the database is part of the product whether they write code or not. If that permission lives in a personal email, you do not have a staff identity design. You have a habit.
Integration: how other tools hear about a change
Integration technologies move a fact from one system to another without a person copying it. In a SaaS company that fact might go from your app to billing, from billing to the CRM, from the app to the customer’s Slack, from a warehouse to a support view.
This room is where stacks get noisy. Each new logo arrives with a native button. The button works for the demo record. It fails for the customer who has two emails and a canceled seat.
The rule that keeps this room small: one source of truth per object, copies downstream, no two-way sync unless you can name the winner of a conflict.
What belongs in the product
Webhooks you publish. An API a customer can call. A native connection you will staff when the vendor changes a field name.
Outbound is you telling the customer system that something changed. Inbound is their system telling you. Treat those as different products. An outbound webhook you retry with care. An inbound firehose you authenticate and do not trust twice.
What belongs outside the product
Internal glue to your own CRM or finance tool. That glue can live in middleware or a small service you own. It should not ship as a customer-facing integration you cannot explain.
If you cannot name the person who gets paged when a payment event runs twice, the connection is not a technology choice. It is folklore with an API key.
How the four rooms lean on each other
Hosting without identity is an open port. Identity without data rules is a locked door in front of a shared spreadsheet. Data without hosting that can fail over is a perfect backup of an app nobody can reach. Integration without a source of truth is five dashboards and one argument.
A change in one room taxes the others. A new region is a hosting ticket. It is also a data residency question, an identity question about where tokens work, and an integration question about webhooks that now fire twice.
When a founder says we need to be on the cloud, ask which room hurts. Slow pages are hosting and sometimes data. Surprise invoices from a customer who was canceled are data and integration. A former employee who still has admin is identity. Treating all of those as a single migration is how you buy a second provider and keep the same outage.
What to buy first, and what to stop buying
Start with one hosting path that can take a real deploy, one database you know how to restore, sign-in you could explain to a customer admin, and zero customer integrations you cannot staff.
Add object storage when files appear. Add a queue when a user request should not wait for email. Add SSO when a buyer with a security questionnaire asks. Add a warehouse when the production database is doing homework during the workday.
Stop buying a new room because a competitor mentioned it on a podcast. Multi-region hosting before you have one healthy region is a costume. A customer-facing app marketplace before you have one webhook that survives a retry is a costume. A second identity vendor because the first one annoyed someone in a sprint is how tokens multiply.
Cloud technologies compound. Each new system is another thing that can be correct in isolation and wrong as a company.
Cost and lock-in without a lecture
The bill is not only compute. Data transfer between rooms shows up after the architecture looks elegant. Identity products charge per seat until you notice machine tokens. Integration platforms charge per task until every CRM edit is a task.
Lock-in lives in the glue more than in the logo. Images and SQL dumps move. The annotations, the identity mappings, and the recipes that only one middleware understands do not move on a weekend.
Regions belong in this conversation only after one region is boring. A second region is hosting copies, data copies, identity that still works, and integrations that do not double-send. Compliance questions land here too. A buyer who needs a data home in one country is asking about the data room first, then hosting, then whether identity and logs follow.
Choose boring in each room when the product is young. A managed database with a restore drill beats a clever data layer nobody can draw. A single region with backups in another place beats two regions that share one brain.
A stack you can draw on one page
Write four headings on a sheet. Hosting. Data. Identity. Integration. Under each, one sentence for the system of record and one sentence for who is on call.
If a heading has five systems and no name, that room is already overgrown.
If a heading is blank, that room is running on a founder laptop and a hope.
Cloud technologies for SaaS are not a list of services to memorize. They are four rooms that have to agree when a customer pays, cancels, exports, or leaves. Hosting keeps the conversation going. Data remembers. Identity hands out keys. Integration tells the rest of the world. Get those four straight and the rest of the cloud catalog can wait.
Comments