4.1Deployment models and types

The first decision when deploying an app is "where, and on top of what, will it run." For the same app, whether you want to keep sensitive data inside your walls, react instantly to load swings, or process with low latency near factory sensors completely changes which cloud model and runtime substrate you should choose. This section organizes the private/public/hybrid/edge deployment models and the runtime forms—VM, bare metal, container—not as terminology to memorize but as the design judgment of "which to choose for this requirement."

4.1.1Cloud deployment models

• A private cloud is infrastructure dedicated to a single organization (your own DC or a dedicated environment). It suits requirements that prioritize control, compliance, and data sovereignty, but since you provision capacity yourself it is weak at sudden expansion. A public cloud uses a provider's shared infrastructure on a pay-as-you-go basis, with the advantages of elastic scaling and reduced operational burden.
• A hybrid cloud combines private and public, placing workloads by requirement. For example, keep sensitive data in the private side and offload only seasonal load spikes (bursts) to the public side (cloud bursting). "One or the other" is rare; choosing per characteristic is the mainstream in practice.
• The edge (edge cloud) model distributes processing physically close to users and devices. It avoids the latency of a round trip to a central data center and responds locally without depending on wide-area links. The decision axes are latency, bandwidth cost, control, and speed of scaling—not "public because it is newer."

4.1.2Edge computing

• Edge computing means processing near where data is generated (sensors, cameras, stores, factories) and sending only the needed results to the center. Because raw data is not all shipped to the cloud, you gain reduced latency, saved bandwidth, and offline resilience. It is especially valuable for IoT, industrial control, and real-time video analytics.
• Contrasted with a centralized model (process everything in the cloud), the essence of edge is "first-pass processing at the source." For example, when a factory vibration sensor emits thousands of samples per second, shipping all of it to the cloud wastes bandwidth and is slow. Judging anomalies at the edge and sending only alerts and summaries is the sound design.

4.1.3VM, bare metal, and container

• A virtual machine (VM) runs on a hypervisor with its own guest OS. It is strongly isolated at the OS level and can host different OSes on one host, but because it carries a whole OS it is slow to start and heavy. Choose it when "strong isolation" or "mixed heterogeneous OSes" is the requirement.
• A container shares the host kernel and runs just the app plus its dependencies packaged together. Carrying no OS, it is lightweight, fast-starting, and highly portable (runs the same everywhere). It suits microservices and high-frequency deployment in CI/CD. Understand that its isolation is weaker than a VM's (shared kernel).
• Bare metal places the OS/app directly on hardware with no virtualization layer. With no virtualization overhead it delivers peak performance, but tends to be one machine per purpose, so flexibility and consolidation are low. Choose it for high-performance computing or extremely latency-sensitive workloads.

Suppose you are designing the deployment for a 50-store retail chain: a system that estimates "checkout queue length" in real time from in-store camera video and notifies staff when it is crowded. A developer initially proposes "continuously upload every store's camera video to a central public cloud and analyze it all there," but this mistakes the requirement. Continuously uploading raw video from 50 stores times several cameras makes the wide-area bandwidth cost enormous, the round-trip latency undermines the real-time goal of alerting on "current crowding," and a link outage takes a whole store down. The sound choice here is edge computing: place a small runtime at each store, do the video analysis locally as first-pass processing, and send only the light result—"queue length"—to the center. Next, choose the runtime. Store devices have limited hardware and must host multiple apps (video analysis, POS integration, a monitoring agent) updated frequently, so rather than a VM that carries a whole OS, a container—kernel-shared, lightweight, fast-starting, and portable—is the rational choice (shipping the same image to every store makes "the same everywhere" pay off). Meanwhile, the central batch that retrains the ML model at scale wants raw GPU performance, so bare metal or a high-performance VM fits there. And highly sensitive member-purchase data belongs on the private side for compliance, while only the seasonal-sale analysis spike is offloaded to the public side—so the whole thing becomes a hybrid design. The key is that it is neither "all cloud because it is newer" nor "all edge because it is cheap": each requirement (latency, bandwidth, isolation, performance, control) is the basis for judging which model and which substrate to choose.

4.1.4Section summary

• Choose the deployment model by requirement: private for control/compliance, public for elastic scale, hybrid to place per characteristic, edge for low latency near the source
• Edge computing does first-pass processing locally instead of shipping raw data, improving latency, bandwidth, and offline resilience
• Choose the substrate by requirement: VM (own OS, strong isolation, heavy), container (shared kernel, lightweight/portable, weaker isolation), bare metal (direct install, peak performance)