Ria Febin
Cloud services are computing resources you rent over the internet instead of owning: servers, storage, databases, development platforms or finished applications. The provider runs the hardware in its data centres, you set things up yourself through a web panel or API, and you pay for what you use. They come in three main types. IaaS gives you virtual servers and storage, PaaS gives you a platform to run your code on, and SaaS gives you a ready-made application such as web-based email. The difference between them is how much of the stack you manage yourself.
What makes a service “cloud”
The definition most people refer to comes from the US National Institute of Standards and Technology (NIST, Special Publication 800-145). It describes cloud computing as on-demand network access to a shared pool of configurable resources “that can be rapidly provisioned and released with minimal management effort or service provider interaction”. NIST lists five essential characteristics:
| Characteristic | What it means in practice |
|---|---|
| On-demand self-service | You create a server or storage yourself, without emailing anyone |
| Broad network access | You use it over the network from any device |
| Resource pooling | The provider’s hardware serves many customers, and you usually pick a region rather than a machine |
| Rapid elasticity | You can add or remove capacity quickly, sometimes automatically |
| Measured service | Usage is metered and reported, typically for pay-per-use billing |
So “the cloud” is not a place. It is a way of delivering computing: someone else’s servers, rented through self-service and metered like a utility.
IaaS, PaaS and SaaS: who manages what
NIST defines three service models. They differ in where the provider’s work stops and yours starts:
- Infrastructure as a Service (IaaS): you get processing, storage and networks and can “deploy and run arbitrary software, which can include operating systems and applications”. You control the operating system and everything on it; the provider runs the hardware and the virtualisation underneath.
- Platform as a Service (PaaS): you deploy your own application using languages and tools the provider supports. You do not manage servers or operating systems, only your code and some settings.
- Software as a Service (SaaS): you use the provider’s application, usually through a browser. You manage little more than your users and your own settings.
| Layer | Own server room | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Data centre, power, hardware | You | Provider | Provider | Provider |
| Virtualisation | You | Provider | Provider | Provider |
| Operating system and patches | You | You | Provider | Provider |
| Runtime, web server, middleware | You | You | Provider | Provider |
| Application | You | You | You (your code) | Provider |
| Data, user accounts, access | You | You | You | You |
The last row never changes. Microsoft’s shared responsibility guide puts it plainly: whatever the service type, you always stay responsible for your data, the devices that access the service, user accounts and access management such as multi-factor authentication. A SaaS provider will not notice that a former employee still has a login.
Examples of each type
Google Cloud’s comparison of the models gives its own products as examples, and adds two newer labels:
| Type | Example | You bring |
|---|---|---|
| IaaS | Compute Engine (virtual machines) | Operating system choice, software, data |
| CaaS (containers as a service) | Google Kubernetes Engine | Container images |
| PaaS | App Engine, Cloud Run | Application code |
| FaaS (functions as a service) | Cloud Functions | Small pieces of code that run on events |
| SaaS | Google Workspace | Users and data |
Public, private and hybrid cloud
NIST also names four deployment models, which describe who the infrastructure is for rather than what you rent:
- Public cloud: open to the general public and run on the provider’s premises.
- Private cloud: for one organisation only. It can be run by that organisation or a third party, on or off its premises.
- Community cloud: shared by organisations with common needs, such as the same compliance rules.
- Hybrid cloud: two or more of these joined so that data and applications can move between them.
A common hybrid setup for a growing business is a dedicated server for the main application and database, plus a public cloud service for backups, email or occasional extra capacity.
Where VPS, dedicated servers and web hosting fit
Hosting products do not always carry the word “cloud”, but they map onto the same layers:
| Product | Closest cloud model | What you manage |
|---|---|---|
| Shared web hosting | Close to PaaS | Your website files, databases and email accounts, through a control panel |
| KVM VPS | IaaS | The operating system and everything on it, with full root access |
| Dedicated server | IaaS on a whole physical machine | Everything above the hardware; no neighbours on the same server |
| Business email and office apps | SaaS | Users, mailboxes and settings |
The main practical difference is billing and scaling. Large cloud platforms meter usage closely: Amazon EC2, for example, bills on-demand servers by the hour or by the second, with a 60-second minimum. That suits workloads that grow and shrink during the day. VPS and dedicated servers are usually rented as fixed monthly plans, which is easier to budget for a website or application with steady traffic. If you want to understand how a VPS is built, read What Is KVM VPS Hosting?
How to choose a cloud service
- Decide how much you want to manage. If nobody on your team will patch servers, prefer SaaS or managed services over raw IaaS.
- Check where your data lives. NIST notes that customers usually choose a country, region or data centre rather than a machine. Make sure the region suits your users and any data rules you must follow.
- Understand the bill. Metered services charge for things you may not expect: Amazon S3, for example, charges per request as well as for the storage itself. Fixed plans are simpler but do not shrink when you are quiet.
- Plan your exit. Before you commit, check that you can export your data in a standard format and move it elsewhere.
- Keep your own backups. The shared responsibility model leaves your data with you, so keep a copy outside the service.
- Secure the accounts. Turn on multi-factor authentication for every admin login from day one.
Ucartz offers several of these layers. Our KVM VPS hosting gives you full root access with automated deployment, our Google Workspace plans cover email and office apps as SaaS, and if you already run on a public cloud, our managed AWS service can take over monitoring, security and cost optimisation for you.
