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."