Try Now

Cloud & Infrastructure

Almost every tool in a modern data stack gives the same answer to “where does it run?” The cloud. So cloud vocabulary is table stakes for any data conversation you’ll have this year.

This category covers the delivery models and the infrastructure layers, without the vendor fog. The terms 👇

30-Second Summary

Cloud and infrastructure terms describe how computing gets delivered, from full cloud platforms and the providers behind them, to SaaS applications, down to the virtual servers underneath.

What This Category Covers

📌 Quick take: Every 'as a service' acronym is answering one question: which layers do you want to stop managing yourself?

The Terms in This Category, Walked Through

Cloud computing anchors the folder. On-demand resources, paid by use. Stacked into the IaaS-PaaS-SaaS layer cake. Each step up trades control for convenience.

And the page goes past the definition. It treats the deployment models (public, private, hybrid, multi) as the risk-and-regulation decisions they really are. It draws the shared-responsibility line where cloud breaches are actually born. Plus the elastic-money disciplines of FinOps, and the migration sequence (six R’s triage, data gravity first) that avoids the classic lift-and-shift regret.

Cloud service providers covers the companies behind the metaphor. How do the hyperscalers actually differ? Skills gravity, ecosystem fit, region coverage. Those beat feature matrices every time. You’ll also find the dependency-management playbook: portability tiers, open formats, annually priced exits. Then the specialist and sovereign providers beyond the big three. And the contract clauses (SLAs, support tiers, price-change mechanics) that matter precisely when everything else is going wrong.

Software as a service takes the top layer seriously as a data topic. There’s a buyer’s checklist that reads contracts for export completeness, API depth, and termination terms. There are estate-management disciplines against shadow SaaS and license drift. Plus the integration layer that makes dozens of tools behave like one system, and a vendor-economics section that explains why SaaS products act the way they do.

Here’s the frame worth keeping. Every SaaS subscription scatters a piece of your data estate. This page is about scattering deliberately.

And virtual private servers cover the unfashionable workhorse. Dedicated resources on shared hardware. Root access. Flat pricing. The page places the VPS honestly against shared hosting, cloud instances, and serverless. It walks the operator’s hardening checklist. And it covers the pet-to-cattle maturity that turns server failures into rebuild drills. Steady, modest, self-contained workloads (collectors, self-hosted tools, small APIs) are exactly where its bargain shines.

The Decisions This Folder Frames

Three choices thread through every page. First: which layers to stop managing. The whole IaaS-to-SaaS spectrum is that one question at different depths.

Second: how much dependence to accept. That’s managed convenience weighed against exit cost, decided per workload, not per ideology. And third: where data may live. Residency, egress, and compliance outrank every feature comparison.

Answer those three explicitly. Because once you do, the vendor and architecture decisions mostly answer themselves.

Using This Folder

Facing a cloud-adoption decision? Read cloud computing first, then providers. Model, then vendor, in that order.

For estate hygiene, the SaaS page’s checklists earn their time within the first renewal cycle. And for workloads that just need a steady machine, the VPS page is permission to choose the boring option on purpose, with the operational discipline that makes boring reliable.

Underneath all of it sits the folder’s quiet constant. The movement and identity disciplines from the neighboring categories apply at full strength, wherever the computing happens to run.

Questions This Category Answers

“Which layers should we stop managing?” The whole IaaS-PaaS-SaaS spectrum is that single question at different depths. The cloud computing page frames the trade, and the SaaS page covers what the top layer means for your data.

“How locked in are we?” The providers page’s playbook makes dependence a managed number. Portability tiers. Open data formats. An annually priced exit.

“Why did the bill spike?” The FinOps section names the usual suspects: idle resources, unwatched egress, and elastic workloads meeting elastic pricing without cost observability. The disciplines are boring. And they work.

“Whose fault is a breach?” The shared-responsibility line answers precisely. Your provider secures the infrastructure. Everything you configure (identities, permissions, buckets) is yours, and it’s where the incidents actually happen.

“Does anything still belong on a plain server?” The VPS page’s honest answer: yes. Steady, modest, self-contained workloads at flat prices, chosen deliberately and operated with pet-to-cattle discipline.

One compass for the whole folder. Decide by data first (where it may live, what leaving costs), economics second, features last. Teams that decide in that order rarely revisit in regret.

How This Category Connects to the Rest of the Wiki

The cloud is where the rest of this wiki physically happens. Your pipelines run on its compute. The lakes and warehouses fill its storage, and scale analytics rents its elasticity. Most of Architecture & Systems‘ platforms now arrive as its SaaS. So when you read any other folder, the silent footnote is usually “running on infrastructure this folder describes.”

The governance connections run deep too. Because the shared-responsibility line hands most breach surface to configuration, identity and platform security become the cloud’s real perimeter. Meanwhile, data residency and privacy law constrain which regions and providers are even eligible. Before features enter the conversation at all.

And one economic through-line worth carrying between folders. Elastic infrastructure made experiments cheap and standing waste expensive. That’s the exact inversion of the on-premise era. Every architectural pattern in this wiki got reshaped by that inversion. Internalize it (watch the idle, price the exits, match tiers to needs) and you get the cloud everyone was promised.

Start Here If You’re New

Take the gentle on-ramp. Cloud computing first, the model and its layers, because everything else assumes that vocabulary. Then SaaS, the layer you already use daily, examined properly. Then providers for the market map. And VPS last, the counterpoint that keeps the picture honest.

Not new, just inheriting an estate? Start from the money instead. Pull the bills, walk the FinOps section’s usual suspects, and read the provider page’s contract clauses before the next renewal. Estates are understood fastest through their invoices. The architecture explains the bill, and the bill exposes the architecture.

Either path ends at the same maturity. Infrastructure decisions made deliberately, priced honestly, and revisited on calendar rather than crisis. That posture is what this folder exists to make normal.

Frequently Asked Questions

What is cloud infrastructure?

Cloud infrastructure is the pooled compute, storage, and networking that providers rent out on demand, paid by use instead of owned outright. It’s the physical and virtual foundation under every “as a service” offering. You consume it through layers (IaaS, PaaS, SaaS) depending on how much you want to manage yourself.

What’s the difference between IaaS, PaaS, and SaaS?

IaaS rents you raw infrastructure, PaaS adds a managed platform on top, and SaaS delivers the finished application. Each step up hands more operations to the vendor and keeps less control for you. Same question at three depths: which layers do you want to stop managing?

Who is responsible for security in the cloud?

Both parties, split by the shared-responsibility line: the provider secures the infrastructure, and you secure everything you configure on it. Identities, permissions, and storage buckets stay on your side of the line. That’s where most real-world cloud incidents actually start.

Is a VPS still worth using in a cloud-first world?

Yes. For steady, modest, self-contained workloads, a VPS delivers dedicated resources and flat pricing that elastic cloud instances can’t beat. Collectors, self-hosted tools, and small APIs fit it well. The catch is that you operate it yourself, so the hardening and rebuild discipline is on you.