4 Deployment Models and Virtualization

4.1 Start With What a Deployment Model Actually Decides

The previous chapter’s responsibility bracket answered “who runs which layer of the stack” — infrastructure, platform, or application. This chapter answers a different question sitting underneath it: whose hardware is it, and who else is allowed on it? That is what a deployment model decides. It is not a service model — a single IaaS server can run on public, private, hybrid, or community infrastructure, and the deployment model is a separate axis you choose independently, exactly as the origins chapter’s NIST three-pillar model kept essential characteristics, service models, and deployment models apart. This chapter builds that third pillar in full, then drops one level lower again, to the virtualization mechanism that makes any of these models physically possible.

A useful plain-language anchor before the taxonomy starts: Oxford Dictionaries defines the cloud itself as “a network of remote servers hosted on the Internet and used to store, manage, and process data in place of local servers or personal computers.” For an IoT system specifically, that network is not optional infrastructure sitting off to one side — it is where device management and configuration happen, where data aggregation, processing, storage, and analysis/visualization happen, and where service customization and infrastructure sharing happen. Every deployment-model choice below is a choice about who owns, and who else shares, the servers doing that work.

4.2 The Four NIST Deployment Models

NIST defines four deployment models: public, private, community, and hybrid. Together they describe who may use the cloud infrastructure and how distinct cloud environments are composed. Distributed cloud, multi-cloud, and inter-cloud are useful architecture or operating patterns, but they are not additional members of this NIST pillar.

Public cloud is what most people picture first: Amazon Web Services, Google Compute Engine, and Microsoft Azure are the source material's own named examples. Its advantages follow directly from being shared, provider-owned infrastructure -- it is easy to set up at low cost because the provider covers the hardware, application, and bandwidth costs; it scales to meet demand; and pay-per-use ensures that, from the user's perspective, no paid-for resources sit idle.

Private cloud trades that shared-cost advantage for exclusivity: the set-up serves a single organization only, whether that organization manages it itself or a third party manages it on the organization's behalf. The advantages are total control over the system and data, and correspondingly fewer security concerns to negotiate with a shared tenant base. The named disadvantage is the mirror image of public cloud's low up-front cost: regular maintenance is the organization's own burden, not something absorbed into a shared bill.

Community cloud is the fourth model, not an "other." It serves a defined group of organizations that share governance requirements, while remaining distinct from a private cloud serving only one organization. Hybrid cloud is also a NIST deployment model in its own right: it composes two or more distinct private, community, or public cloud infrastructures through technology that supports data and application portability, such as controlled load movement between them.

4.3 Comparing and Choosing: On-Premise, Off-Premise, Dedicated, and Shared

Deployment model choice becomes concrete when a fast control deadline and a long historical workload share one system. Figure 4.1 places a city-pump interlock, fleet records, elastic analytics, and the hybrid evidence hand-off.

In Figure 4.1, Edge / private control owns the 20 ms shut-off and survives WAN loss. Public cloud buys elastic storage, batch analytics, and managed queues, while Hybrid evidence path uploads sequenced signed events and returns versioned policy rather than granting an unbounded cloud override.

The public-versus-private comparison above already hints at the real trade-off underneath every deployment decision: security and control on one side, cost and scale on the other. A second, complementary view makes the same four core models easier to place side by side, by crossing two independent questions -- is the infrastructure on the organization's own premises or hosted elsewhere, and is access dedicated to one tenant or shared across several?

Reading that matrix column by column resolves a distinction the plain private-versus-public framing tends to blur: "private" is not a synonym for "on-premises." A private cloud can be hosted off-premises by a third party and still be dedicated to a single organization -- the defining trait of a private cloud is dedicated access, not physical location. Community cloud occupies the position most people would otherwise expect private cloud to sit in: on-premises, but shared across a defined group rather than dedicated to one tenant. Public cloud is the only combination that is both off-premises and shared, which is exactly why it earns the lowest security rating and the lowest per-unit cost in the comparison table above -- more tenants sharing more distant infrastructure is the same trade-off expressed two different ways.

Put together, the practical decision route is: name whether the workload needs dedicated infrastructure (regulatory, latency, or control reasons) or can tolerate shared infrastructure; then name whether an organization is willing to operate that infrastructure itself or would rather have it hosted. Those two answers, independently, land on one of the four cells above -- hybrid and multi-cloud arrangements are simply combinations of more than one cell at once, which is why they were introduced as compositions rather than as a fifth and sixth cell of their own.

4.4 Under the Hood: Virtual Machines, Containers, and a Worked Docker Example

Every deployment model above describes an ownership and sharing arrangement -- it says nothing yet about the mechanism that lets one physical server safely host more than one tenant's workload at once. That mechanism is virtualization: it is what enables clouds to run separate workloads under strict resource partitioning, letting CPU and memory be used optimally while still giving each workload security guarantees against the others sharing the same hardware.

Two approaches deliver that partitioning, and they trade off in opposite directions:

The diagram behind that pair of cards makes the structural difference concrete. On the virtual-machine side, each application sits on its own binaries/libraries, on its own full guest operating system, and all of those guest OS instances sit on a hypervisor, which itself sits on the host OS and the physical server. On the container side, each application sits on its own (or shared, where appropriate) binaries/libraries, but the containers sit directly on the host OS -- there is no per-container guest OS and no hypervisor layer at all. Containers are isolated from each other, but they share the host OS, and share binaries/libraries wherever that sharing is safe to do.

Removing the guest-OS-per-instance and hypervisor layers is what produces the container approach's named advantages: containers are fast to instantiate, can be destroyed as needed, need no hypervisor, can share OS libraries across instances, and are easy to scale. Every one of those five advantages is a direct consequence of the same structural fact -- there is simply less machinery to start, stop, and duplicate per instance than a virtual machine requires.

A Dockerfile is a plain-text recipe for an image -- it names a starting point and a sequence of build steps:

# Use a Python runtime as the parent image
FROM python:slim
# Set the working directory to /app
WORKDIR /app
# Copy the current directory contents into the container at /app
ADD . /app
# Install any needed packages specified in requirements.txt
RUN pip install --trusted-host pypi.python.org -r requirements.txt
# Make port 80 available to the world outside this container
EXPOSE 80
# Define an environment variable
ENV NAME World
# Run app.py when the container launches
CMD ["python", "app.py"]

Reading it top to bottom: start from a Python base image; make `/app` the working directory; copy the current directory's contents into that `/app` folder inside the image; install whatever packages `requirements.txt` lists; declare that the container will listen on port 80; set one environment variable; and finally, name the command that runs when a container starts from this image. `app.py` itself, in the source's own walkthrough, does one thing -- it listens for connections on port 80 and returns an HTML page.

Building an image from that Dockerfile and giving it a name, then running a container from it, is two commands:

docker build -t docker-file .
docker run -p 4000:80 docker-file

The first command builds the image and tags it `docker-file` (the name the source's own walkthrough uses for the `docker run` step). The second command starts a container from that image: `-p 4000:80` maps port 80 inside the container -- the port `EXPOSE 80` declared -- to port 4000 on the host machine, which is why a browser on the host would reach the running application at port 4000, not port 80. That single `-p` flag is the entire bridge between "a process listening inside an isolated container" and "a service reachable from outside it."

4.5 Lab: Constrained IoT Ingestion Container

This lab turns the VM/container comparison into evidence. Build a minimal HTTP ingestion process, bind it only to localhost, cap CPU and memory, record the image digest and build provenance, and force both a bad-input failure and a process restart. The container boundary reduces packaging variation; it does not provide a separate kernel or remove the need to secure the host.

Create server.py:

import json
from http.server import BaseHTTPRequestHandler, HTTPServer

class Handler(BaseHTTPRequestHandler):
    def do_POST(self):
        try:
            length = int(self.headers.get("content-length", "0"))
            event = json.loads(self.rfile.read(length))
            assert isinstance(event.get("device"), str)
            assert isinstance(event.get("value"), (int, float))
            print(json.dumps({"accepted": event}, sort_keys=True), flush=True)
            self.send_response(202)
        except (ValueError, AssertionError, json.JSONDecodeError) as error:
            print(json.dumps({"rejected": type(error).__name__}), flush=True)
            self.send_response(400)
        self.end_headers()

HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()

Create Dockerfile:

FROM python:3.13-alpine
WORKDIR /app
COPY server.py .
USER 65532:65532
EXPOSE 8080
CMD ["python", "server.py"]

Build and run it from a disposable lab directory:

docker buildx build --load --provenance=mode=max --sbom=true -t iot-ingest:defa .
docker image inspect iot-ingest:defa --format '{{.Id}}'
docker run --name iot-ingest-defa --detach \
  --publish 127.0.0.1:8080:8080 \
  --memory 128m --cpus 0.5 --pids-limit 64 \
  --read-only --tmpfs /tmp:rw,noexec,nosuid,size=16m \
  --restart on-failure:3 iot-ingest:defa
curl -i -X POST http://127.0.0.1:8080 -d '{"device":"lab-7","value":21.4}'
curl -i -X POST http://127.0.0.1:8080 -d '{"device":7,"value":"bad"}'
docker stats --no-stream iot-ingest-defa
docker logs --timestamps iot-ingest-defa

Record the Docker/Buildx versions, Dockerfile checksum, image digest, provenance/SBOM location, published interface and port, resource limits, accepted and rejected request status, log timestamps, restart count, and cleanup. Stop and remove only the named lab container when finished: docker rm --force iot-ingest-defa.

4.6 Summary

A deployment model answers a question a service model does not: whose infrastructure is it, and who is allowed to use it? NIST’s four models are public, private, community, and hybrid. Distributed cloud, multi-cloud, and inter-cloud instead describe placement, coordination, or federation patterns that may be used with those models. The on-premise/off-premise by dedicated/shared-access matrix resolves the common confusion that “private” means “on-premises” — it does not; dedicated access is the defining trait of private cloud, regardless of who hosts it. Underneath any deployment model, virtualization is the mechanism that lets one physical server safely partition workloads: virtual machines give each workload a full guest OS on a shared hypervisor, while containers skip both layers and run directly on the shared host OS, which is why containers are faster to instantiate, destroy, and scale. A worked Dockerfile — build steps, a base image, an exposed port, and a run command with a port mapping — shows that mechanism operating end to end.

4.7 Key Takeaway

4.8 See Also