There is a common assumption that "the cloud" is a marketing word invented sometime around 2010 to make renting servers sound weightless. It is older than that, and it is not a metaphor for weightlessness at all. It is a drawing convention — a shape engineers scribbled on whiteboards for decades before anyone thought to sell it.
The cloud started as a symbol for "not my problem"
Draw a network diagram by hand. You have boxes for the machines you control, lines for the cables you own, and then you reach the edge of your own responsibility — the telephone company's switching network, a carrier's backbone, the internet itself. You cannot draw what is in there. You do not know what is in there, and more importantly you do not need to: you hand data in one side and it comes out the other.
So engineers drew a cloud. A soft, deliberately vague blob, standing in for a system that is real, complicated, expensive and entirely somebody else's concern. The convention was well established in telecoms and networking diagrams long before commercial cloud computing existed — you can find it in ATM and frame-relay documentation through the 1990s, and the same idiom sits behind the phrase "out on the network cloud."
That is the whole origin. When utility computing became a commercial product in the mid-2000s — Amazon's EC2 opened to the public in 2006, and Google's Eric Schmidt used "cloud computing" on a conference stage the same year, which is usually credited with popularising the term — the industry did not invent a name. It reached for the symbol every engineer in the room already understood, because it described the product exactly: infrastructure you use without owning, inspecting or maintaining.
Why the abstraction is the actual product
This matters more than a naming trivia answer, because the cloud symbol is a promise about ignorance. It says: you may stop thinking about this part.
That promise is what you are buying. Nobody rents a virtual machine because they want a virtual machine; they rent one so they never have to source a rack, negotiate bandwidth or replace a failed drive at 2am. The value is the size of the blob — how much complexity fits inside the cloud shape and stays there.
It is also where the risk lives. Whatever you draw inside that cloud, you have chosen not to understand. That is fine right up until it is the thing that breaks.
Where the cloud boundary sits in an IoT system
Connected products make this concrete, because the line has to be drawn somewhere physical. On one side is a microcontroller with kilobytes of RAM, a battery budget and no fan. On the other is effectively unlimited compute that costs money per request and only exists when the network is up.
Deciding what goes where is one of the highest-leverage architecture calls in the whole build:
- Push too much into the cloud and the device becomes a paperweight the moment connectivity drops. For a sensor in a Philippine warehouse with patchy Wi-Fi, or a field unit on cellular, that is not an edge case — it is Tuesday.
- Push too little and you are shipping raw sample data at full rate, paying bandwidth and storage that scale linearly with fleet size, while burning battery on radio transmissions that carry almost no information.
The usual answer is neither extreme. The device filters, aggregates and makes time-critical decisions locally; it buffers to flash when the link is down and reconciles when it returns; the cloud gets summaries, exceptions and anything that needs history or cross-device context. Firmware handles what must be immediate and offline-tolerant. The backend handles what must be durable, queryable and shared.
Get that split right and the cloud genuinely is a blob you can stop thinking about. Get it wrong and you end up debugging across the boundary anyway — which is the one thing the cloud symbol was invented to spare you.
Silicon to cloud
The reason we describe our work as IoT and web services from silicon to cloud is that these are not two projects. The firmware decisions and the backend decisions constrain each other: your payload format sets your bandwidth bill, your buffering strategy sets your data-loss behaviour, your local decision logic sets how much downtime a customer actually notices.
If you are designing a connected product and trying to work out where that boundary belongs, tell us what you are building — it is usually a much shorter conversation than people expect, and it is far cheaper to have before the firmware is written than after.
The cloud is a real place full of real machines. It just got its name from a drawing that meant "do not look in here."
Top comments (0)