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.
Not the same question as the sibling chapter: Cloud Deployment Models for IoT asks “which deployment model should this IoT workload use, backed by what governance record?” This chapter asks the question underneath that one: “what is a public cloud, a private cloud, on-premise versus off-premise, and a hypervisor versus a container, mechanically, before any IoT placement decision gets made?”
4.2 The Deployment-Model Taxonomy: Public, Private, Hybrid, and the Others
Seven named patterns cover who owns a cloud’s infrastructure and who is allowed to share it. Four are the well-known core; three more round out the “Others” category:
Public Cloud
A cloud set-up for the use of any person or industry, typically owned by the organization that offers the service.
Private Cloud
A cloud set-up functioning only for a single organization, typically managed either by that organization itself (on-premises) or by a third party (off-premises).
Hybrid Cloud
Two or more distinct cloud set-ups – private, community, or public – pooled together by standardized tools, supporting data and application portability.
Others
Four further named patterns: community, distributed, multi-cloud, and inter-cloud – detailed below.
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.
Hybrid cloud is not a third infrastructure type in its own right – it is what you get when two or more of the others (private, community, or public) are pooled together by standardized tools. That pooling is what supports data and application portability, for example a facility for load-balancing between the pooled clouds, and it is why a hybrid arrangement can offer more than one deployment model’s worth of coverage at once.
The remaining four patterns round out “Others”:
Community Cloud
A shared set-up between several organizations that have common concerns – security, compliance, jurisdiction – and is managed either internally or by a third party.
Distributed Cloud
A collection of scattered computing devices in different locations, connected to a single network. Two named types: public-resource computing and volunteer cloud.
Multi-Cloud
Multiple cloud computing services offered via a single heterogeneous architecture – chosen to increase fault-tolerance and flexibility.
Inter-Cloud
A unified, global “cloud of clouds” built on the internet, supporting interoperability between different cloud service providers.
4.3 Comparing and Choosing: On-Premise, Off-Premise, Dedicated, and Shared
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:
Virtual Machines
Multiple instances of potentially different operating systems running on the same physical machine – the mechanism underneath Infrastructure-as-a-Service. Each instance carries its own full guest OS.
Containers
Different applications running on a virtualized OS within partitions – the mechanism underneath Platform-as-a-Service. Execution stays safe to the kernel even if an application inside a container has security issues.
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 worked example, read rather than run. Walk through the following the way you would read someone else’s terminal session, not as an install-and-follow-along lab – the point here is to see the container model operate end to end, not to stand up a working Docker environment. It is adapted from the classic “Get Started” walkthrough at docs.docker.com (the source material’s own tutorial pinned Python 2.7, a version long past its end of life; a version-neutral base image is used below instead, and every other instruction is transcribed as taught).
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 Summary
A deployment model answers a question a service model does not: whose hardware is it, and who else shares it? Public, private, and hybrid are the three core patterns, rounded out by community, distributed, multi-cloud, and inter-cloud. 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.6 Key Takeaway
“Private” describes who has access, not where the server sits – and “container” is not a smaller virtual machine, it is a different mechanism that removes the guest-OS-per-instance and hypervisor layers entirely. Before naming a deployment model or a virtualization approach, name the actual trade-off it makes: ownership versus sharing, and how much machinery runs per isolated instance.
4.7 See Also
Service Models: IaaS, PaaS, and SaaS
The previous chapter in this module: the responsibility bracket this chapter’s deployment-model taxonomy sits alongside as a separate, independent axis.
Service Management, SLAs, and Economics
The next chapter in this module: once a deployment model and a virtualization approach are chosen, this is how the resulting service gets managed, billed, and paid for.
Cloud Deployment Models for IoT
The applied companion chapter: turns this chapter’s deployment-model taxonomy into an IoT placement decision with a governance record.