[Back to blog](https://zsoftly.ca/blog) [Engineering](https://zsoftly.ca/blog/category/engineering) # Cloud service models: MaaS, IaaS, PaaS, SaaS at a glance A short guide to the four-layer cloud stack: Metal, Infrastructure, Platform, and Software as a Service, with ZCP services mapped to each layer. ZSoftly Team May 16, 2026 2 min read Share The cloud service model stack describes who manages what. Each layer hands off more of the operating burden to the provider and leaves you with less to run. There are four layers worth knowing in 2026: Metal, Infrastructure, Platform, and Software as a Service. [NIST SP 800-145](https://csrc.nist.gov/pubs/sp/800/145/final) formally defines three of them (IaaS, PaaS, SaaS). MaaS is a newer industry-recognized model, championed by [Canonical MAAS](https://maas.io/) and [OpenStack Ironic](https://wiki.openstack.org/wiki/Ironic). It sits one layer below IaaS. ## The four layers MaaS, Metal as a Service. You get a physical server, provisioned on demand. No hypervisor, no neighbors. You bring the OS and everything above it. Useful for GPU training, license-bound software, and workloads unable to tolerate virtualization overhead. IaaS, Infrastructure as a Service. Virtual machines, block and object storage, virtual networks. The provider runs the hypervisor and physical layer. You manage the OS, runtime, and apps. NIST defines IaaS as “the capability to provision processing, storage, networks, and other fundamental computing resources.” PaaS, Platform as a Service. You deploy code or containers. The provider runs the runtime, scaling, and patching. Managed Kubernetes, managed databases, and serverless functions all sit here. SaaS, Software as a Service. A complete application delivered over the network. The user signs in and uses it. Email, CRM, and collaboration tools are the canonical examples. A 2024 [IEEE comparative analysis](https://ieeexplore.ieee.org/document/10823401) of these models notes the trade-off is consistent across the stack: more abstraction means less control and easier operations. ## ZCP service mapping Here is where each ZCP product fits: | Layer | ZCP service | | --- | --- | | MaaS | Private Cloud Build-Out (bare-metal procurement and operation, not self-serve) | | IaaS | Virtual Machines (CloudStack + KVM), Block Storage (Ceph), Object Storage (S3-compatible), File Storage, VPC + Networking (OPNsense + WireGuard), Security, DNS | | PaaS | Managed Kubernetes (control plane $99/mo), Observability (Prometheus + Grafana). Serverless is on the roadmap. | | SaaS | Not offered directly. SaaS ISVs run their products on ZCP IaaS. | The bulk of ZCP today is IaaS, with a thin and growing PaaS layer. We do not pretend to be a SaaS vendor. We run the layer underneath the SaaS you already use. ## Picking a layer A useful rule: choose the highest layer with the control you need. If you only need to send transactional email, SaaS wins. If you need a Postgres cluster but not the OS underneath it, PaaS. If you need OS-level control or custom networking, IaaS. If you need the physical host (GPUs, hardware-bound licenses, strict isolation), MaaS. Most workloads land on IaaS or PaaS. ZCP’s catalog is built around those two layers first. ## Related articles Engineering November 4, 2026 ### [How Zenphry Built a Reusable Office Connection for Its Remote Team](https://zsoftly.ca/blog/remote-teams-office-network) How Zenphry built an approved remote-access foundation with a Headscale VPN control plane on ZCP, a Dallas exit node, Tailscale clients, and managed routers. Engineering November 4, 2026 ### [Why I Love Orca for ZSoftly’s Development Workstations](https://zsoftly.ca/blog/shared-development-workstation-orca-zcp) How ZSoftly is designing dedicated developer workstations on ZCP, with Orca across interactive work and a separate CI/CD path for execution. Engineering October 12, 2026 ### [A Backup Is Not a Disaster Recovery Plan](https://zsoftly.ca/blog/backup-is-not-disaster-recovery) A successful backup job does not prove you can recover. Separation, verification, restore testing, and operational ownership create real disaster recovery readiness.