Console → CLI → API: three doors into one cloud

There are three ways to tell a cloud provider "create me a server," and a beginner's biggest confidence jump comes from realizing they are three doors into the same room. Whether you click a button, type a command, or send an HTTP request, the exact same thing happens underneath. Understanding this turns the cloud from a maze of unfamiliar screens into a single system you can drive however you like — and it explains why professionals quickly stop clicking.

The API is the real cloud; everything else is a client

Underneath it all, every cloud provider exposes an API — an Application Programming Interface, a defined set of HTTP requests you can send to make things happen. "Create a VM" is, at bottom, an HTTP request to the provider's API with some parameters (which region, how big, which image). The API is the actual control surface of the cloud. Nothing happens without it.

The other two ways you interact are just friendlier clients that ultimately call that same API for you:

• The console is a website that turns your clicks into API calls.
• The CLI is a program that turns your typed commands into API calls.

Once you see that the console and the CLI are both just clients of the same API, the cloud stops being three things to learn and becomes one thing with three steering wheels.

Door 1 — The console: great for learning, bad for repeating

The console is the provider's web dashboard — you log in with a browser and click through forms to create and manage resources. It's the right place to start: it's visual, it labels every option, and it's forgiving while you build a mental model. When you're exploring a service for the first time, the console is your friend.

But the console has two fatal flaws for real work:

• It isn't repeatable. If you set up a server by clicking twenty checkboxes, the only record of what you did is your memory. Building the same thing again — or in another region, or for a teammate — means clicking the same twenty boxes and hoping you remember. This is how environments silently drift apart.
• It doesn't scale or automate. You can't click a button at 3 a.m. when traffic spikes, and you can't review a click in a pull request. Clicks leave no trail and can't be tested.

:::note "ClickOps" — and why it's a warning, not a compliment Provisioning infrastructure by manually clicking through the console is informally called ClickOps. It's fine for learning and one-off experiments. As a way to run production, it's an anti-pattern: undocumented, unrepeatable, and impossible to review. Chapter 3 (Infrastructure as Code) exists specifically to replace it. :::

Door 2 — The CLI: typed, scriptable, repeatable

The CLI (Command-Line Interface) is a program you install on your machine that lets you control the cloud by typing commands in a terminal instead of clicking. The same "create a server" action becomes a single line you can save, paste, and share. A representative command (provider-agnostic shape) looks like:

# Conceptual shape — every provider's CLI follows this pattern:
#   <tool> <service> <action> <options>
cloud compute instances create my-server \
  --region eu-central-1 \
  --machine-type small \
  --image ubuntu-22.04

Why this is a real upgrade:

• It's repeatable and shareable. That command is text. Save it in a file, send it to a colleague, run it again next month — you get the identical result. The console's "what did I click?" problem disappears.
• It's scriptable. Because commands are text, you can string them together in a shell script, loop over them, and feed the output of one into the next. This is the first taste of automation — making the computer do the repetitive work.
• It's how you authenticate machines. The CLI uses credentials (keys or tokens) rather than a human login, which is exactly how automated systems will talk to the cloud later.

Door 3 — The SDK and raw API: cloud from inside your code

One step deeper, an SDK (Software Development Kit) is a library for a programming language — Python, Go, JavaScript — that lets your application code make those same API calls. Instead of typing a command, your program calls a function like create_instance(...). This is how software provisions and manages cloud resources on its own: an app that spins up extra workers when a queue gets long is calling the API through an SDK.

And if you strip everything away, you can send the raw HTTP API request yourself. You rarely need to — the SDK and CLI exist so you don't — but knowing it's just an HTTP request underneath is the final piece of demystification.

The progression every engineer makes

There's a natural arc, and it mirrors the whole story of this guide:

You start in the console to understand a service. You move to the CLI to make your actions repeatable and scriptable. You reach for the SDK when software needs to drive the cloud. And finally — the destination of Chapter 3 — you graduate to Infrastructure as Code, where you stop issuing individual commands altogether and instead declare the entire system you want and let a tool make the API calls to build it. Each step removes more manual, un-reviewable, un-repeatable human clicking.

:::tip Durable vs dated The progression — console → CLI → API → IaC — is durable; it describes how serious cloud work is done and won't change. The exact CLI commands and console layouts are dated and differ per provider and get redesigned often. Learn the progression and the concept of "it's all the same API underneath"; look up the specific syntax when you need it. :::

Why it matters

Every cloud has one true control surface — its API — and the console (clicks) and CLI (typed commands) are just clients that call it for you. The console is ideal for learning a service but is unrepeatable and unreviewable, an anti-pattern for production known as ClickOps. The CLI makes your actions text — repeatable, shareable, scriptable — and the SDK lets your own programs drive the cloud. The professional arc runs console → CLI → SDK/API → Infrastructure as Code, each step trading manual clicking for automation. Seeing all of these as doors into one API is the mental shift that makes the cloud feel learnable.

You now have the full foundational picture of one cloud. But there are three giants — AWS, Google Cloud, and Microsoft Azure — and newcomers waste enormous energy wondering which to learn. The final lesson of this chapter gives you the mental model that makes that anxiety evaporate.

Next: The big-3 mental model →