The cloud: from the 1990s network diagram to the 2011 NIST definition, and the three service models

The cloud -- cloud computing -- is the delivery of computing resources (servers, storage, networking, databases, software) as on-demand services over the internet, instead of owning and maintaining that infrastructure locally. The definition sounds abstract, and that's why much of the literature glosses over it: what matters isn't the metaphor in the term, but the concrete service models the cloud offers and the decisions each one implies.

It's worth starting with the real origin, because casual use of the term has diluted its meaning to the point where almost any digital service is called "cloud" without the word meaning much.

The origin of the term and the modern era since 2006

The cloud symbol in network diagrams dates back to the 1990s, when engineers used a drawn cloud to represent external networks whose internals they didn't need to detail. "Your system connects to that; what's inside the cloud doesn't matter for this diagram." The visual metaphor was pragmatic: an abstraction so they wouldn't have to draw the external infrastructure every time.

The use of the term "cloud computing" in its modern sense is usually attributed to Eric Schmidt, then CEO of Google, in a talk at the Search Engine Strategies Conference in August 2006, where he said "we call it cloud computing -- they should be in a cloud somewhere." Although there were earlier uses in academic and technical circles, that talk popularized the expression.

More important than the term was what happened that same year on the technical side:

March 2006: Amazon launches S3 (Simple Storage Service), enabling object storage via a web API. Any developer could start storing files remotely with pay-as-you-go pricing.

August 2006: Amazon launches EC2 (Elastic Compute Cloud), enabling virtualized compute capacity to be rented. For the first time, a company or developer could spin up servers without buying hardware or maintaining their own data center.

Those two launches marked the birth of modern cloud infrastructure. Google Cloud Platform entered the market in 2008. Microsoft Azure launched commercially in February 2010. The cloud as a competitive sector took off there.

The canonical definition: NIST 800-145 (2011)

The most rigorous and widely cited definition of cloud computing is from the U.S. National Institute of Standards and Technology, published in Special Publication 800-145 in September 2011 and authored by Peter Mell and Timothy Grance. It's a short document (~7 pages) that remains an academic and industry reference.

NIST defines cloud computing by five essential characteristics, three service models, and four deployment models.

The five essential characteristics

On-demand self-service. The user provisions resources without human intervention from the provider. You spin up a server with a click; you don't fill out a form and wait days.

Broad network access. Resources are available over the network and accessible from any standard device (phone, computer, tablet) -- they don't require a specialized client.

Resource pooling. The provider's resources are pooled and dynamically allocated among multiple customers (multi-tenancy). The user neither knows nor needs to know where their server is physically located.

Rapid elasticity. Resources can be scaled up or down quickly, in many cases automatically, according to demand. What used to require buying new hardware is now done by adjusting a variable.

Measured service. Usage is monitored and billed by consumption. You pay for what you use, not for installed capacity you may not use.

If a service doesn't meet these five characteristics, it technically isn't cloud computing in the NIST sense. It's traditional web hosting with a modern look.

The three service models

This is the most important operational distinction for making infrastructure decisions. NIST identifies three levels of cloud service based on what the provider supplies and what the customer manages:

IaaS -- Infrastructure as a Service

The provider delivers virtualized infrastructure: compute capacity, storage, networking. The customer manages the operating system, runtimes, data, and applications. Examples: AWS EC2 + S3, Google Compute Engine, Azure Virtual Machines, DigitalOcean Droplets, Linode.

It's the most flexible level and the one that requires the most technical knowledge. Suitable for companies that need fine-grained control over their infrastructure or that run non-standardized workloads.

PaaS -- Platform as a Service

The provider delivers a development and runtime platform with the runtime, operating system, and automatic scaling already configured. The customer only handles the application code and the data. Examples: Heroku, Vercel, Netlify, AWS Elastic Beanstalk, Google App Engine, Azure App Service.

It dramatically reduces deployment complexity. Suitable for development teams that want to focus on code rather than infrastructure.

SaaS -- Software as a Service

The provider delivers a complete, ready-to-use application. The customer only configures, uses, and operates within the limits the application allows. Examples: Gmail, Salesforce, Slack, Notion, Figma, Polimake.

It's the most accessible model and the one that has dominated cloud consumption. The vast majority of small and mid-sized companies consume the cloud through dozens of SaaS products without realizing they're in the cloud.

The distinction matters because the decisions around investment, control, risk, and migration are completely different at each level. A company that depends on several critical SaaS products has different risks from one with its own infrastructure on IaaS.

The four deployment models

NIST also identifies four models based on who operates the infrastructure and for whom:

Public cloud. Infrastructure owned by the provider, offered openly to the market. AWS, Azure, and GCP in their standard form are public cloud. Most small and mid-sized companies use public cloud.

Private cloud. Infrastructure dedicated exclusively to one organization (it can be operated by the organization itself or by a third party, but use is exclusive). It's usually justified by regulatory, security, or extreme customization requirements.

Hybrid cloud. A combination of public and private, with data and applications moving between the two as needed. A common model in large companies with mixed workloads.

Community cloud. Infrastructure shared by several organizations with common concerns (e.g., healthcare consortia with similar regulatory requirements). Less common in practice than the other three.

Why understanding these distinctions matters

The usual conversation about the cloud at non-technical companies tends to treat everything as a black box labeled "cloud." That oversimplification hides decisions that matter:

Different structural cost by model. SaaS has a predictable cost but no economies of scale (you pay per user or per consumption); IaaS has a variable cost that can explode with usage or fall with optimization. A company that consumes the cloud without understanding the difference between models usually has higher bills than necessary.

Different vendor lock-in risk. Migrating from one SaaS to another is usually painful but bounded. Migrating between IaaS providers means a complete re-architecture of the solution. Initial technology decisions set paths for years.

Security and compliance. Each service model has a different responsibility model: with IaaS you manage the operating system and the application; with PaaS only the application; with SaaS only the configuration. Confusion about who is responsible for what generates real vulnerabilities.

Performance and latency. The deployment model (public vs. private vs. hybrid) affects latency, throughput, and user experience in ways the generic category "it's in the cloud" doesn't capture.

The 2026 reality: ubiquitous cloud, but with nuances

Seventeen years after the launch of AWS S3, the cloud has gone from a trend to standard infrastructure. The global cloud computing market exceeds 500 billion dollars annually and grows at double digits consistently. Practically all mid-sized and large companies consume the cloud at some level.

Some trends in the current state:

Multi-cloud and hybrid as the standard. Few large companies entrust their operations to a single provider. Diversification is protection against outages, against price increases, and against the provider's strategic changes.

Sovereign cloud. Growth of cloud providers localized by jurisdiction (especially in Europe) due to concerns about data sovereignty and GDPR compliance. Initiatives like GAIA-X (European) reflect that concern.

Edge computing. The reverse of the centralized cloud -- bringing compute capacity close to the end user to reduce latency. Cloudflare Workers, AWS Wavelength, and Azure Edge Zones are examples.

FinOps as a discipline. The financial management of cloud consumption has become a dedicated function at many companies, with the FinOps Foundation (created in 2019) consolidating practices.

Partial repatriation. Some large companies have moved workloads from public cloud to their own infrastructure or private cloud after doing the math and discovering that certain workloads are cheaper on-premise. 37signals (Basecamp, HEY) publicized its move out of AWS in 2022-2023 and has published detailed analyses of the savings.

Common mistakes in cloud usage

Confusing SaaS with the entire cloud. "We're in the cloud" when what you mean is "we use several SaaS tools" is not the same as having a cloud strategy.

Underestimating the long-term cost. Public cloud seems cheap at first. At scale, especially with predictable workloads, it can be more expensive than your own infrastructure. Honest math requires a 3-5 year cost model.

Invisible vendor lock-in. Building applications that depend on a provider's proprietary services (Lambda on AWS, Cosmos DB on Azure) significantly reduces migration flexibility.

Not designing for provider failures. Outages at AWS, Azure, and GCP have happened and will happen. Assuming 100% uptime is irresponsible planning.

Forgetting GDPR and data sovereignty. Especially for European companies, where data physically resides matters legally. Not all providers offer guaranteed European residency for all services.

SaaS sprawl. The number of SaaS tools per company has grown exponentially. Without governance, companies accumulate duplicate, abandoned, or redundant subscriptions with significant cumulative cost.

The cloud and creative operations

For a marketing team, agency, or audiovisual production house, the cloud isn't an abstract technical decision -- it's the infrastructure on which all creative work lives in 2026. Asset management, collaboration across disciplines, production tools, the archive of completed projects -- all of it is in the cloud. The choice of which services to use and how to organize them largely defines the speed, cost, and security of the creative operation.

That choice fits into creative operations: content production requires cloud infrastructure that enables collaboration and reuse, brand management needs accessible repositories that keep versions under control, and approval workflows operate on platforms that connect distributed stakeholders.

At Polimake, that logic lives in a SaaS creative operations platform that coordinates Studio (planning), Studio (production), and Media (asset management) -- so creative assets live in a system designed for creative work, not scattered across Drive, Dropbox, WeTransfer, and local folders.

---

If you lead technology, operations, or marketing at a company making cloud decisions and you've landed here looking for an answer, the most useful thing you can take from this article is probably the distinction almost no one respects: "being in the cloud" isn't one decision; it's many different decisions depending on the service model (IaaS/PaaS/SaaS) and the deployment model (public/private/hybrid). Making cloud decisions without the right granularity produces higher bills, inadvertent lock-in, and vulnerabilities that are discovered late.

To round this out, working in the cloud covers the practical benefits for remote teams, SaaS goes deeper into the most widely used service model, and digital assets covers the management of the assets that live in the cloud on creative projects.

Quick references

• SaaS (Software as a Service) -- the most widespread model in enterprise consumption.
• Working in the cloud -- the operational benefits for teams.
• Digital assets -- what gets stored in the cloud in creative operations.
• CMS -- a category of SaaS specialized in content management.
• Hosting -- a traditional category adjacent to the cloud.