What is Cloud Computing? #

Many people go straight to the AWS or GCP console, spin up a VM, and start experimenting with services. There’s nothing wrong with that approach, but it often leaves gaps in understanding that only surface once an architecture gets complex or a bill suddenly balloons. Before touching a single cloud service, we need a solid definition of what cloud computing actually is, why it exists, and how it changes the way we think about infrastructure. This article covers those foundations thoroughly — from the official definition to the myths that often mislead.

When Do You Need Cloud Computing? #

Before diving into definitions and concepts, it’s important to know when cloud computing is genuinely needed and when it isn’t. Not every technical problem has to be solved with the cloud.

You DO need cloud computing if: ✓ You want to provision infrastructure in minutes, not weeks ✓ Your workload fluctuates — there are peaks and quiet periods ✓ You want to avoid large upfront hardware investments (CapEx) ✓ Your team wants to focus on building products, not managing data centers ✓ You need to reach users across different geographic regions

You DON’T need cloud computing if: ✗ Your workload is completely stable and 100% predictable ✗ Compliance requires data to be processed on hardware you own ✗ Your application has a latency requirement below 1ms to the hardware ✗ You don’t yet understand the shared responsibility model

The Official Definition — NIST #

The most widely used definition in the industry comes from NIST (National Institute of Standards and Technology). According to publication SP 800-145, cloud computing is:

A model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources — networks, servers, storage, applications, and services — that can be rapidly provisioned and released with minimal management effort or service provider interaction.

That definition is dense, but it contains several keywords that are absolutely crucial:

Each of these keywords isn’t just a technical description — it reflects a fundamental shift in how infrastructure is managed. On-demand eliminates slow procurement processes. Shared enables cost efficiency through resource sharing. Rapidly provisioned turns provisioning time from weeks into minutes. And minimal management effort frees teams from operational tasks that don’t add direct value to the product.

It’s important to note that the NIST definition does not tie cloud computing to any particular vendor. The cloud isn’t “AWS” or “Azure” — the cloud is a model. AWS, Azure, and GCP are just commercial implementations of that model. This understanding becomes the foundation when we discuss private cloud and hybrid cloud later in the site.

• The NIST SP 800-145 definition is widely used across the industry as a reference standard.
• This definition applies to all cloud models — public, private, and hybrid.
• A vendor or service that claims to be “cloud” but doesn’t meet the five NIST characteristics isn’t actually cloud computing.

The Five Essential Characteristics #

NIST defines five characteristics that must be present for something to be called cloud computing. These aren’t bonus features — they’re the minimum requirements. Without all five, what you have is just regular hosting with a “cloud” label slapped on.

On-Demand Self-Service #

Users can provision computing resources on their own, whenever needed, without interacting with a human on the provider’s side. You can spin up 100 servers at 3 AM without calling anyone — no purchase orders, no approval chains, no waiting time.

The most noticeable difference from this characteristic is the elimination of bureaucratic procurement. In traditional infrastructure, ordering a new server could involve filing a request with the procurement department, getting management approval, negotiating with vendors, and waiting for hardware delivery. In the cloud, the entire process is cut down to a single click or a single API call.

flowchart TD
    subgraph Tradisional["Traditional Infrastructure (Weeks/Months)"]
        A[Need Server] --> B[Submit Purchase Order]
        B --> C[Management & Finance Approval]
        C --> D[Vendor Negotiation & Delivery]
        D --> E[Assemble & Wire Physically in DC]
        E --> F[OS Installation & Configuration]
        F --> G[Server Ready]
    end
    
    subgraph Cloud["Cloud Computing (Minutes)"]
        H[Need Server] --> I["Console Click / API Call"]
        I --> J[Automatic Provisioning by Platform]
        J --> K[Server Ready]
    end

Broad Network Access #

Resources are available over the network and can be accessed from various devices — laptops, smartphones, tablets, workstations — using standard protocols. There’s no dependence on proprietary networks or specialized hardware. This is what lets developers work from anywhere.

This characteristic is also what allows the cloud to serve global users. An application deployed in the Southeast Asia region can be accessed by users in Europe over the same internet — no special cables or proprietary VPNs required.

Resource Pooling #

The provider’s computing resources are pooled to serve many consumers at once using a multi-tenant model. Physical and virtual resources are dynamically assigned and reassigned according to demand. Users generally don’t know — and don’t need to know — exactly where their resources are physically running.

flowchart TD
    subgraph Penyedia["Cloud Data Center (Resource Pool)"]
        CPU["CPU Pool"]
        RAM["RAM Pool"]
        Disk["Storage Pool"]
    end
    
    subgraph Tenant["Logical Isolation (Multi-Tenancy)"]
        T1["Tenant A (Retail Application)"]
        T2["Tenant B (Financial Application)"]
        T3["Tenant C (Education Application)"]
    end
    
    CPU & RAM & Disk -. "Allocation" .-> T1
    CPU & RAM & Disk -. "Allocation" .-> T2
    CPU & RAM & Disk -. "Allocation" .-> T3

Multi-tenancy doesn’t mean your data gets mixed with other people’s data. Each tenant remains logically isolated — like apartments in a single building. You don’t know your neighbor in the next unit, and you don’t care which floor you’re on, as long as your apartment works properly. It’s this resource pooling that lets cloud providers push costs down — because resources unused by one tenant can be allocated to another.

Rapid Elasticity #

Capacity can be provisioned and released elastically — in many cases automatically — to match demand. From the consumer’s perspective, available capacity appears unlimited. When traffic spikes, the infrastructure grows. When traffic is quiet, it shrinks. Nobody has to sleep in the data center.

Elasticity is what sets the cloud apart from traditional hosting. A regular VPS might let you upgrade RAM or CPU, but the process is manual and often requires a restart. In the cloud, auto-scaling can add or remove instances within minutes based on metrics you define — CPU utilization, request count, queue length, or other custom metrics.

flowchart LR
    Low["Low Load (Night)"] -->|"Scale In (Automatic)"| VM2["2 VM Instances"]
    High["Peak Load (Daytime)"] -->|"Scale Out (Automatic)"| VM10["10 VM Instances"]

Measured Service #

Cloud systems automatically control and optimize resource usage using precise measurement capabilities — storage, processing, bandwidth, active user accounts. Usage is monitored, controlled, and reported transparently. This is what makes the pay-as-you-go model work.

Without measured service, the cloud couldn’t bill fairly. Every API call, every byte of data transferred, every second of compute used — all of it is measured and recorded. This transparency benefits both sides: providers can optimize infrastructure, and users can understand and control their costs.

What Is NOT Cloud Computing #

Understanding the definition becomes sharper when you know what doesn’t count as cloud computing. Many hosting services market themselves as “cloud” without meeting the five NIST characteristics. This distinction isn’t just about terminology — it affects architecture, cost, and scaling capability.

• Many providers use the “cloud” label for regular VPS — especially in the Indonesian hosting market.
• Use the five NIST characteristics as a filter when evaluating services.
• If a service doesn’t support true on-demand self-service and automatic elasticity, it’s not cloud — no matter how it’s marketed.

Why Cloud Computing Exists #

The cloud wasn’t born from technology for its own sake. It was born from real problems businesses faced for years — problems that traditional infrastructure approaches couldn’t solve.

The Capacity Problem #

Traditional infrastructure forces organizations to choose between two equally bad options. Over-provisioning means buying more capacity than needed to anticipate peaks — servers sit idle 80-90% of the time and money goes to waste. Under-provisioning means buying just enough — when traffic spikes (flash sales, viral events, holiday seasons), systems crash and customers leave.

There’s no easy middle ground once hardware has been purchased. An e-commerce company that buys servers to handle Harbolnas (12.12) traffic will have idle servers for the remaining 364 days. Conversely, an e-commerce company that only buys for normal traffic will crash on promotion day. The cloud solves this by letting capacity adapt dynamically.

The Time Problem #

Hardware procurement can take 2 to 8 weeks — and that doesn’t include internal procurement processes that are often even slower in large corporations. In startups, speed is everything. Fast-moving businesses can’t wait that long to test new ideas or respond to market opportunities.

A competitor that can move in minutes will always beat one that needs weeks. If a startup finds product-market fit and needs to scale 10x overnight, traditional infrastructure can’t keep up. The cloud can.

The Capital Problem — CapEx vs OpEx #

Servers, storage, and networking require large capital expenditure (CapEx) upfront — even before the infrastructure produces any value. A startup with a great idea can run out of money before launching its product, simply because of initial infrastructure costs.

The cloud turns this model into operational expenditure (OpEx): pay for what you use, start from zero, and scale with growth. This isn’t just an accounting change — it changes who can build digital products. With the cloud, two students with a credit card can build infrastructure as large as a Fortune 500 company’s.

CapEx Model — Traditional Infrastructure: Month 1: Buy 10 servers → $50,000 Month 1-2: Data center setup → $20,000 Month 3: 15% utilization → 85% of money wasted Month 8: Traffic spikes → running out of capacity Month 9: Buy 10 more servers → $50,000 + 4 weeks

OpEx Model — Cloud Computing: Month 1: Deploy 2 instances → $150/month Month 3: Scale to 5 instances → $375/month Month 8: Traffic spikes → auto-scale to 50 instances Month 9: Traffic drops → auto-scale back to 5 // Total cost is proportional to actual utilization

The Operational Problem #

Running a data center requires very specific expertise — power supply and redundancy management, cooling systems, hardware maintenance, physical security, compliance with building standards, and cable management. All of this is operational overhead that doesn’t directly contribute to the product being built.

Imagine a startup team of 5 developers. If they had to manage physical servers, at least 1-2 people would spend all their time on infrastructure operations. With the cloud, all five developers can focus entirely on product features. The cloud moves the entire operational burden to the service provider, letting engineering teams focus on what really matters: building products.

The Three Cloud Service Models #

Cloud computing is categorized into three main service models, often represented as a stack because each one builds on the one below it. Understanding the difference is crucial for determining how much control and responsibility you need. Besides these three main models, there are also additional models like FaaS (Function as a Service) and CaaS (Container as a Service), covered in their own articles.

flowchart TD
    subgraph SaaS["SaaS — Software as a Service"]
        A1[Application]
    end
    subgraph PaaS["PaaS — Platform as a Service"]
        B1[Runtime & Middleware]
        B2[OS]
    end
    subgraph IaaS["IaaS — Infrastructure as a Service"]
        C1[Virtualization]
        C2[Server]
        C3[Storage]
        C4[Network]
    end

    SaaS --> PaaS
    PaaS --> IaaS

    U1["Managed by provider ↑"] --- IaaS
    U2["Control by user ↓"] --- SaaS

IaaS — Infrastructure as a Service #

IaaS provides the basic building blocks of infrastructure: virtual machines, storage, networking, and firewalls. You get an “empty machine” and can install anything on top of it. Maximum control, but also maximum responsibility — you manage the OS, middleware, runtime, application, and data.

IaaS suits organizations with a strong ops team or legacy applications that can’t be modified to run on managed platforms. You can control almost every aspect of infrastructure — from the Linux kernel version to network firewall configuration. But remember: every bit of control you have means one more thing you have to manage.

PaaS — Platform as a Service #

PaaS provides a platform for developing, running, and managing applications without dealing with the infrastructure underneath. The OS, middleware, and runtime are managed by the provider. Developers only focus on code and data.

PaaS is great for startups and small teams that want to accelerate time-to-market. You push code, and the platform handles the rest — scaling, load balancing, health checks, even deployment rollbacks. The downside: you lose control over the environment underneath, and some specialized configurations may not be supported.

SaaS — Software as a Service #

SaaS provides finished applications ready to use directly through the browser. Users don’t need to install, manage, or update anything. Everything is managed by the provider — including infrastructure, platform, security, and availability.

SaaS is the model most widely used by end users, even though many don’t realize they’re using cloud computing. Every time you open Gmail, edit a document in Google Docs, or send a message in Slack — you’re using SaaS. For businesses, SaaS makes it possible to use enterprise tools with zero infrastructure investment.

Cloud Deployment Models #

Besides the three service models, the cloud also has several deployment models that describe how cloud infrastructure is organized and accessed. The deployment model choice affects security, compliance, cost, and level of control.

flowchart TD
    A{"Deployment needs?"} --> B{"Need full control<br>over infrastructure?"}
    B -- Yes --> C{"Have budget and<br>internal team?"}
    C -- Yes --> D["Private Cloud<br>(OpenStack / VMware)"]
    C -- No --> E["Managed Private Cloud<br>(third-party provider)"]
    B -- No --> F{"Have sensitive workloads<br>AND elastic workloads?"}
    F -- Yes --> G["Hybrid Cloud"]
    F -- No --> H{"Need to avoid<br>vendor lock-in?"}
    H -- Yes --> I["Multi-Cloud"]
    H -- No --> J["Public Cloud<br>(AWS / GCP / Azure)"]

Public Cloud #

Infrastructure is owned and operated by a third-party provider (AWS, GCP, Azure) and shared with many organizations over the internet. This is the most common and most cost-effective model because infrastructure costs are spread across millions of users. Physical and network security are fully managed by the provider. For most workloads, the public cloud is the right choice — especially for startups, SaaS products, and applications that need global scalability.

Private Cloud #

Cloud infrastructure is used exclusively by a single organization. It can be managed internally or by a third party, and can live in an on-premise data center or a colocation facility. Private cloud gives you more control over security, compliance, and customization — but at a higher cost and with the need for an internal team to manage it.

Hybrid Cloud #

A combination of public and private cloud connected through technology that allows data and applications to move between them. Organizations can run sensitive workloads in the private cloud while leveraging the public cloud’s elasticity for peak demand. This model is the most flexible but also the most complex to manage — it requires network integration, consistent security policies, and tooling that supports both environments.

Multi-Cloud #

Using two or more public cloud providers simultaneously. The motivations vary: avoiding vendor lock-in, taking advantage of the best services from each provider, or meeting regional compliance requirements. Multi-cloud offers maximum flexibility but requires expertise in managing several platforms at once — and it can become far more complex than expected if not planned well.

The Paradigm Shift #

What makes the cloud truly different isn’t just the technology — it’s the accompanying change in thinking. Many organizations move to the cloud technically but still think the old way — designing cloud architectures exactly like on-premise data centers, or buying fixed capacity without leveraging elasticity.

This paradigm shift is often the hardest thing to adopt, especially for large organizations with mature culture and processes. Frequently, what’s called a “cloud migration” is just lift-and-shift: moving applications from physical servers to VMs without changing the architecture. The result? Costs higher than on-premise, without gaining the elasticity and resilience benefits the cloud offers.

// ANTI-PATTERN: Cloud managed like on-premise
// Ordering reserved instances for all workloads without utilization analysis
// Ignoring auto-scaling — turning off the cloud's most valuable feature
// Not using managed services — managing the database yourself on a VM
// Avoiding automation — still deploying manually over SSH
// Result: higher costs, cloud benefits never realized

// CORRECT: Leveraging the cloud paradigm fully
// Use auto-scaling for fluctuating workloads
// Take advantage of managed services (database, message queue, cache)
// Automate provisioning with Infrastructure as Code (Terraform, Pulumi)
// Apply FinOps for continuous cost monitoring and optimization
// Design applications assuming failure will happen — use retry, circuit breaker

Myths and Misconceptions #

As the cloud’s popularity keeps growing, many myths circulate in the industry. Separating fact from fiction matters for making sound architectural decisions. The following myths are covered in depth in the later articles of this section:

1. “The Cloud Is Always Cheaper” — Fact: it can be more expensive if you don’t leverage elasticity.
2. “The Cloud Is Secure by Default” — Fact: security IN the cloud remains entirely your responsibility.
3. “Moving to the Cloud = Modernization” — Fact: lift-and-shift without architectural changes just moves the problem around.
4. “The Cloud Means No Infrastructure Team Needed” — Fact: the role shifts from hardware technician to cloud/IaC/DevOps engineer.
5. “The Cloud Is Always Available Without Downtime” — Fact: regional outages still happen; architectures must be designed with resilience.
6. “Every Workload Fits the Cloud” — Fact: strict latency requirements or certain data sovereignty regulations are better served on-premise.

Summary #

• The cloud isn’t just servers on the internet — it’s a service model with 5 essential characteristics per NIST: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service.
• The NIST definition is the industry standard — use it as a filter to distinguish true cloud computing from regular hosting that markets itself as “cloud.”
• The cloud was born from real problems — rigid capacity, slow procurement times, heavy CapEx burden, and operational complexity.
• Three service models (IaaS, PaaS, SaaS) determine how much control and responsibility you have. Choose based on needs, not trends.
• Deployment models (public, private, hybrid, multi-cloud) determine where infrastructure runs. Each has trade-offs between cost, control, and complexity.
• The paradigm shift matters more than the technology shift — without changing how you think about infrastructure, failure, and cost, the cloud just becomes more expensive hosting.
• The cloud isn’t always cheaper, isn’t automatically secure, and isn’t right for every workload — good decisions are based on analyzing technical and business needs.