Cloud-Computing

Overview Edge computing and cloud computing both run workloads away from the end-user device, but they differ in where that processing physically happens relative to the data source. Edge computing pushes compute to nodes near the device to cut latency, while cloud computing centralizes it in remote data centers for scale and simplicity. The choice shapes latency budgets, bandwidth costs, and how much infrastructure you have to manage yourself. Comparison Diagram Where Processing HappensEdge ComputingDeviceEdgeNode~1-5 ms round tripCloud ComputingDeviceCloudDataCenter~50-150 ms round trip, multiple network hopsSame device, two distances to compute Comparison Table Aspect Edge Computing Cloud Computing Processing location Local nodes, gateways, or on-device hardware near the data source Centralized data centers operated by the provider, often far from the source Latency Single-digit to low double-digit milliseconds due to physical proximity Tens to hundreds of milliseconds depending on distance and network path Network dependency Can operate with intermittent or low-bandwidth connectivity to the core network Requires a stable, sufficiently fast connection to reach the data center Bandwidth usage Filters or pre-processes data locally, sending only summaries upstream Raw data typically travels over the network to be processed centrally Compute and storage capacity Limited by the size and power of local hardware Effectively unlimited, elastic capacity provisioned on demand Data handling and privacy Sensitive data can be processed and stay on-site, reducing exposure Data leaves the local environment and is subject to provider-side controls Scalability and management Scaling means deploying and maintaining more physical nodes across sites Scaling is a configuration change managed by the provider Cost model Upfront hardware and per-site operational costs Pay-as-you-go operating expense with no hardware to own Key Differences Edge computing minimizes latency by keeping processing physically close to the data source Cloud computing offers far greater elastic capacity since it draws on a shared, centralized pool of resources Edge deployments reduce bandwidth costs by filtering data before it ever leaves the site Cloud computing is simpler to manage since there’s no distributed hardware fleet to maintain Edge nodes can keep sensitive data local, while cloud centralization concentrates data in provider infrastructure When to Use Each Edge Computing ...

Overview Both are ways to rent compute capacity from a cloud provider, but they trade cost against reliability in opposite directions. Spot Instances tap into unused capacity at steep discounts but can be reclaimed with almost no notice, while On-Demand Instances cost more per hour in exchange for a guaranteed, uninterrupted slot. Comparison Diagram Timeline of a running workloadOn-Demand InstanceReserved for you, no interruptionsRuns continuously until you stop itSpot InstanceRunning!2-min warningthen reclaimedResumes on new capacityUp to 90% cheaper, but availability is never guaranteed Comparison Table Aspect Spot Instances On-Demand Instances Request & provisioning Fulfilled only if provider has spare capacity at your bid price Fulfilled immediately from reserved capacity pools Capacity guarantee None — provider can reclaim the instance at any time Guaranteed for as long as you keep paying Pricing model Variable, set by real-time supply and demand for spare capacity Fixed hourly rate published by the provider Interruption behavior Reclaimed with a short warning (e.g. ~2 minutes on AWS) Never interrupted by the provider; you control shutdown Cost predictability Fluctuates; can spike or be revoked when demand rises Stable and predictable, easy to forecast in a budget Ideal workloads Fault-tolerant, stateless, or checkpointable batch jobs Stateful, latency-sensitive, or continuously running services Termination control Provider-initiated; your app must handle abrupt shutdown User-initiated; you decide exactly when it stops Key Differences Spot pricing floats with market demand and can be up to 90% cheaper than On-Demand rates Spot capacity is reclaimable at any time, typically with only a short warning window On-Demand gives a firm capacity guarantee that Spot never promises Workloads on Spot need to tolerate sudden termination or design for checkpointing On-Demand cost is fixed and predictable, while Spot cost is variable and market-driven When to Use Each Spot Instances ...

Overview In serverless and containerized systems, a cold start happens when a request must wait for a new execution environment to be provisioned and initialized before it can run, while a warm start reuses an already-running instance and skips straight to execution. The gap between the two explains why the same function can respond in 5ms or 2 seconds depending on whether an idle instance was standing by. Comparison Diagram Cold StartReqProvisioncontainerInit runtime+ codeExecutelatency: tens of ms - several secondsWarm Startidle, pre-initialized container waitingReqExecutelatency: sub-ms - low tens of ms Comparison Table Aspect Cold Start Warm Start Trigger condition No idle instance available (scale-to-zero, scale-out, or fresh deploy) Idle, already-initialized instance is available to handle the request Environment state at invocation No running process; container or sandbox must be created from scratch Process is already running in memory from a prior invocation Steps performed Provision compute, load code, initialize runtime and dependencies, run init code, then handle request Skip provisioning and init; execute the handler directly on the existing process Typical latency added Tens of milliseconds to several seconds depending on runtime and package size Sub-millisecond to low tens of milliseconds Resource cost to provider Higher; allocates new compute, memory, and network setup Lower; reuses resources already allocated Frequency of occurrence Rare relative to total traffic but concentrated after idle periods, deploys, or scale-out Common; most requests during steady, active traffic Primary mitigation Provisioned concurrency, smaller packages, lighter runtimes, scheduled pings Sustained traffic, minimum instance counts, connection reuse Key Differences Cold start pays full provisioning overhead; warm start reuses an already-initialized process. The latency gap can span orders of magnitude — low milliseconds versus multiple seconds. Cold starts are triggered by scale-to-zero or scale-out events, not by what the request contains. Whether a start is warm depends on the platform’s idle timeout before it reclaims the instance. Avoiding cold starts usually means paying for reserved capacity to keep instances standing by. When to Use Each Cold Start ...

Overview Public and private cloud both deliver on-demand, virtualized IT resources, but differ in who owns and shares the underlying infrastructure. Public cloud pools shared hardware across many customers over the internet, while private cloud reserves dedicated hardware for a single organization. The choice shapes cost, control, and compliance posture. Comparison Diagram Public CloudPrivate Cloudvia Public Internetvia Private Network / VPNOrg AYouOrg BOrg CYour Org OnlyComputeStorageNetworkShared, multi-tenantDedicated, single-tenant Comparison Table Aspect Public Cloud Private Cloud Infrastructure ownership Owned and operated by a third-party provider (AWS, Azure, GCP) Owned by the organization, or a provider-managed dedicated instance Tenancy model Multi-tenant — hardware and hypervisor shared across many customers Single-tenant — hardware reserved exclusively for one organization Network access path Reached over the public internet, secured via account credentials and VPCs Reached over a private network, VPN, or dedicated leased line Provisioning and scaling Near-instant self-service scaling from a shared resource pool Scaling bounded by pre-purchased or pre-built capacity Cost structure Pay-as-you-go operating expense with no upfront hardware cost Large upfront capital expense or fixed contract, amortized over time Security and compliance control Shared responsibility model; provider secures the underlying infrastructure Full control over physical and network security, easing strict compliance audits Customization and control Limited to the services and configurations the provider exposes Full control over hardware, hypervisor, and network topology Key Differences Public cloud runs on shared infrastructure across many customers; private cloud reserves hardware for a single tenant. Public cloud follows a shared responsibility security model; private cloud gives the organization full control over the stack. Public cloud costs are operating expense, scaling with usage; private cloud typically requires capital investment upfront. Public cloud offers near-instant elastic scaling; private cloud scaling is bounded by provisioned capacity. Private cloud simplifies strict regulatory compliance; public cloud relies on provider-audited controls instead. When to Use Each Public Cloud ...

Overview IaaS and PaaS are cloud service models that differ in how much of the technology stack the provider abstracts away from you. IaaS hands you raw virtualized infrastructure and leaves the OS, runtime, and app management to you, while PaaS also manages the OS and runtime so you only push application code. The distinction matters because it determines your team’s operational burden, control, and how fast you can ship. Comparison Diagram IaaSPaaSApplicationRuntimeOSNetwork & StorageVirtualizationHardwareyou manage 3 layersApplicationRuntimeOSNetwork & StorageVirtualizationHardwareyou manage 1 layercolored = customer-managed · outlined = provider-managed Comparison Table Aspect IaaS PaaS Provisioning unit Virtual machines, block storage, virtual networks Application slots or containers bound to a managed runtime OS and runtime management Customer installs, configures, and patches OS and runtime Provider installs and patches OS and runtime automatically Deployment workflow Customer scripts server setup, then deploys app via SSH/config management Customer pushes code (git push, CI artifact); platform builds and deploys Scaling Customer configures auto-scaling groups and load balancers manually Platform scales instances automatically based on traffic or rules Customization and control Full root access, any OS, any custom software stack Constrained to platform-supported languages, frameworks, and versions Failure recovery Customer builds and monitors health checks, failover, and backups Platform handles instance replacement and basic health monitoring Vendor lock-in Low — standard VM images port across most cloud providers Higher — apps depend on platform-specific APIs and build conventions Typical adopter Infrastructure/ops teams migrating or replicating existing systems Application developers who want to ship features without managing servers Key Differences IaaS gives you a virtual machine; PaaS gives you a managed runtime for your code PaaS abstracts away OS patching, which IaaS leaves entirely to the customer IaaS deployment means configuring servers yourself; PaaS deployment is typically a git push PaaS trades flexibility for speed, increasing vendor lock-in compared to IaaS Auto-scaling is built into PaaS, whereas IaaS requires customer-configured scaling groups When to Use Each IaaS ...