Cloud versus self-hosting
Two choices hide here: who builds the software, and who runs it.
Build or buy
At one end you write and run your own software. In the middle you take ready-made software, like PostgreSQL, and run it yourself: on your own machines (on premises) or on rented cloud VMs (IaaS). At the other end a vendor builds and runs it for you. Keep in-house what makes your business special; buy the routine parts.
When cloud pays off
Cloud is not always cheaper. If your team already knows how to run a system and the load is steady, owning machines often costs less. Cloud wins when you lack those skills, or when load swings a lot. Fast analytics queries need many machines for seconds, then none.
The cost of giving up control
With a service you can't add a missing feature, fix an outage, or read its logs. If it shuts down or gets pricey you must move, and with few standard APIs, moving is costly (lock-in). You must also trust the provider with your data, and sanctions can cut you off. Cloud still grows, but trading systems that need full hardware control stay in-house.
Cloud native storage
Cloud native systems build on other cloud services. If a higher-level service fits your need, use it; if none fits, build from lower-level ones. Object storage, like S3, holds big files and survives failures. A VM's local disk is only a cache, since it is lost with the VM. Virtual disks are network services: every read crosses the network. Storage and compute are separate, so data moves over the network to the CPUs. Many customers share the same hardware (multitenancy), which needs strict isolation.
Operations in the cloud era
DevOps and SRE value automation and short-lived machines. In the cloud, capacity planning becomes cost planning. You still pick and connect services, watch quotas, secure your code, and debug slowdowns.
Remember
- Steady, familiar load is often cheaper self-hosted.
- Cloud costs you control.
- Local disks are a cache; durable data lives in services.
- Ops changes shape; it does not go away.