Two conversations keep happening at almost every company I’ve worked with as CTO, usually about eighteen months apart. The first is about which kind of cloud service to buy — SaaS, PaaS, or IaaS, and increasingly a few newer options nobody names correctly on the first try. The second happens after the first real cloud bill lands, and it’s a harder question: whether to be in the cloud at all, for everything. Here are both conversations, told close to how they actually go.
Quick Navigation
Conversation One: Which Kind of Cloud Service Do We Actually Need?
What follows is a composite of real meetings, not a transcript of one — but every question in it is one I’ve heard asked for real.
The room: a leadership team deciding whether to finally move off traditional hosting. In the chairs — a CEO pushing for the move, a CTO who has to make it work, a CFO tracking the bill, and a CISO worried about what happens to the data once it leaves the building.
CEO: “We’ve been on traditional hosting for years. Is it time to move to the cloud, or are we overthinking this?”
CTO: “I’d move. Cloud gives us scalability and cost-efficiency traditional hosting can’t — we pay for what we use instead of guessing capacity two years out.”
CFO: “Isn’t that just a more expensive way of renting the same servers?”
CTO: “Traditional hosting is like owning a house — big upfront cost, and you’re responsible for everything, maintenance included. Cloud is renting, and there are several ways to rent: fully furnished, partially furnished, or bare shell.”
CISO: “And the data risk of handing that over to a third party?”
CTO: “Real concern, and a fair one. Reputable providers invest heavily in security, but the responsibility doesn’t disappear — it shifts. We still have to choose well and configure it properly.”
CTO: “The three rental options, in plain terms — SaaS is renting the finished software: Google Workspace, Salesforce, you just log in and use it. PaaS is renting a kitchen to cook in: you build and deploy your own applications, but the provider maintains the stove and fridge — the underlying infrastructure. IaaS is renting the empty building: raw compute, storage, and networking, and you build everything on top yourself. IaaS gives the most control and demands the most expertise; SaaS gives the least control and needs almost none.”
CEO: “Which is most expensive?”
CTO: “IaaS costs the most upfront, since we’re paying for raw infrastructure — though it can be cheaper long-term if we manage resources well. SaaS is usually the cheapest to start, but the least flexible.”
CFO: “Lock-in risk if we want to switch providers later?”
CTO: “Highest with SaaS. Lower with PaaS and IaaS, since we control more of our own data and architecture.”
CISO: “And which carries the most corporate risk?”
CTO: “IaaS — more control means more responsibility for security and compliance falls on us. SaaS pushes most of that onto the provider. PaaS sits in between.”
CEO: “So what actually fits our strategy?”
CTO: “There’s no cookie-cutter answer — it’s a per-workload decision. My proposal: SaaS for standard tools, PaaS for custom development, IaaS for the infrastructure-heavy pieces that genuinely need the control. A hybrid mix, not a single choice.”
CEO: “Then let’s make it happen.”
That’s usually where the story ends in a pitch deck. In real life, the IT team spends the next few months evaluating providers, migrating workloads, and re-learning security in a new environment — and it does pay off, but not on the timeline anyone announced in that first meeting.
Then, Two Years Later, Someone Asked About Serverless
That conversation used to be the whole story. It isn’t anymore. In a later meeting — different company, younger architect on the call — the same question came back with three extra acronyms attached.
- Function as a Service (FaaS) / Serverless: You don’t manage servers at all, even the ones PaaS still has you thinking about. Upload a function, it runs when triggered, you pay only for the milliseconds it executes. Great for spiky, event-driven work; awkward for anything that needs to run continuously.
- Container as a Service (CaaS): Your application ships in containers — portable units that run identically everywhere — and the provider handles orchestrating them at scale. More control than PaaS, less operational burden than raw IaaS.
- Backend as a Service (BaaS): Pre-built backend infrastructure — auth, databases, push notifications — wired up via API, so a small team can ship a mobile or web app without building backend plumbing from scratch.
None of this changes the CFO’s question — it just adds more line items. The real surprise in cloud spending rarely comes from the sticker price; it comes from data egress fees, idle reserved capacity, and services nobody remembered to switch off. And for Indian companies specifically, data localization and sector-specific transfer rules — the DPDP Act included — now shape which region you’re even allowed to host in, a decision that used to be purely about latency.
Conversation Two: Should We Even Be Fully in the Cloud?
The second conversation shows up later, and it’s rarely about which service anymore — it’s about where. I’ve sat in this one too, usually triggered by a cloud bill that grew faster than anyone budgeted for.
- Cloud Hosting: infrastructure fully owned and run by a provider — AWS, Azure, GCP — you rent what you use. Fastest to scale, but the least control, and often the most expensive at real volume.
- On-Premise: you own and run everything yourself, in your own facility. Maximum control, maximum responsibility, and an upfront capital cost most growing companies can no longer justify.
- Collocation: you own the hardware, but it lives in someone else’s data center, using their power, cooling, and physical security. Real control over your own servers, without building your own facility.
- Hybrid: a deliberate mix — some workloads in the cloud for elasticity, others on-premise or collocated for cost, compliance, or latency. More operational complexity, but often the most honest answer past a certain company size.
Cloud usually wins early, when nobody can predict load and speed matters more than unit cost. On-premise or collocation start making sense once a workload is large, predictable, and steady enough that owning the hardware is cheaper than renting it indefinitely — a real crossover point, not a hypothetical one.
So — does a company ever actually move back? Yes, more often than cloud vendors advertise. I’ve seen it happen for one predictable, compute-heavy workload where the cloud bill stopped making sense once volume stabilized, while everything else stayed exactly where it was. It’s rarely all-or-nothing; it’s one workload at a time, moved for a specific reason, not an ideological switch.
Both conversations end the same way: there’s no single right answer, only the right answer for what a specific workload actually needs — how it scales, what it costs at your real volume, and how much operational burden your team can honestly carry. Get that evaluation right piece by piece, and both the service-model question and the cloud-vs-on-premise question stop being ideological and start being math.
Related Reading
- The CTO’s Candid Guide to Load Testing
- Build vs. Buy: The Software Question
- AI in the Indian Boardroom
