Devops

Overview Auto scaling and manual scaling both change how much compute capacity an application has, but they differ in who — or what — decides when that change happens. Auto scaling relies on an automated feedback loop that watches metrics and reacts on its own, while manual scaling depends on human intervention to notice load and issue the change. That difference in decision-maker drives everything else: reaction speed, cost efficiency, and how much ongoing attention the system needs. ...

Overview A managed database hands the operating system, patching, backups, and failover to a cloud provider, while a self-hosted database keeps the entire stack under your team’s direct control. The choice trades operational convenience against flexibility, cost structure, and how much low-level tuning you’re allowed to do. Comparison Diagram Managed DatabaseSelf-Hosted DatabaseApplication / QueriesProvider ManagesDB EngineOperating SystemHardware / StorageLess control, less toilYou Manage EverythingApplication / QueriesDB EngineOperating SystemHardware / StorageMore control, more toil Comparison Table Aspect Managed Database Self-Hosted Database Provisioning & setup Spin up via console or API in minutes; provider installs and configures the engine Manually install and configure the OS, storage, and database software yourself Configuration & tuning access Limited to exposed parameters and flags; some engine internals and OS access are locked Full root or admin access to every config file, kernel setting, and storage layout Scaling Resize compute or add read replicas with a click or API call; provider automates the process Provision new hardware and reconfigure sharding or replication topology yourself Backups & recovery Automated snapshots and point-in-time restore built into the service You script, schedule, and test your own backup and restore procedures Patching & upgrades Provider applies OS and engine security patches on a maintenance schedule You plan, test, and execute every patch and major version upgrade High availability & failover Multi-AZ replication and automatic failover configured with a toggle You design, build, and test the replication and failover setup yourself Monitoring & support Built-in dashboards and alerts, plus vendor support tickets for engine-level issues You assemble your own monitoring stack; support is internal or community-based Cost model Higher per-hour price that bundles operational labor into the bill Lower raw infrastructure cost but a hidden cost in engineering time Key Differences Managed services abstract patching and OS maintenance behind a provider SLA. Self-hosted setups grant full root access to tune kernel, storage, and engine internals. Failover and multi-AZ replication are automated in managed offerings but hand-built elsewhere. Cost shifts from engineering hours to a recurring subscription fee with managed databases. Self-hosting permits any custom extension or fork that managed platforms often restrict. When to Use Each Managed Database ...

Overview Docker Swarm and Kubernetes are both container orchestration platforms that manage deployment, scaling, and networking of containerized applications, but they differ sharply in operational complexity and feature depth. Swarm prioritizes simplicity, integrating directly into the Docker CLI for fast setup, while Kubernetes offers a far more extensible, battle-tested platform built for large-scale, production-grade workloads. Comparison Diagram Docker SwarmKubernetesSwarm ManagerRaft consensus storeWorker NodeTaskTaskTaskWorker NodeTaskTask2 node roles: manager + workerControl PlaneAPI ServeretcdSchedulerController MgrWorker NodekubeletPodWorker NodekubeletPodLayered control plane + kubelet-managed pods Comparison Table Aspect Docker Swarm Kubernetes Setup & installation Single command: docker swarm init/join Multi-step: kubeadm, managed service, or install tool Cluster architecture Manager nodes (Raft consensus) + worker nodes Control plane (API server, etcd, scheduler, controller manager) + worker nodes with kubelet Deployment unit Service made of identical Tasks, one container each Pod: one or more co-located, co-scheduled containers Networking Built-in overlay network, configured automatically Pluggable via CNI plugins (Calico, Cilium, Flannel) Service discovery & load balancing Built-in DNS plus routing mesh VIP kube-proxy with Service objects and Ingress controllers Scaling & scheduling Basic spread or binpack placement strategies Fine-grained scheduling with affinity rules, taints, and resource requests Self-healing & updates Restarts failed tasks, basic rolling updates Reconciliation loops, rolling updates, rollbacks, HPA/VPA autoscaling Ecosystem & extensibility Minimal, small plugin ecosystem Vast ecosystem: CRDs, Operators, Helm, service meshes Key Differences Docker Swarm favors simplicity, built directly into the Docker CLI, while Kubernetes requires setting up a separate control plane. Swarm deploys single-container Tasks, whereas Kubernetes groups containers into Pods that share network and storage. Kubernetes offers far more granular scheduling controls than Swarm’s basic spread strategy. Kubernetes’ ecosystem of CRDs, Operators, and Helm dwarfs Swarm’s, at the cost of a steeper learning curve. Swarm networking is automatic overlay by default, while Kubernetes relies on pluggable CNI plugins requiring explicit choice. When to Use Each Docker Swarm ...

Overview Both controllers watch metrics and adjust Kubernetes workloads automatically, but they scale in different dimensions. The Horizontal Pod Autoscaler adds or removes pod replicas to handle load, while the Vertical Pod Autoscaler resizes the CPU and memory requests/limits of existing pods. Comparison Diagram Horizontal Pod AutoscalerVertical Pod Autoscalerbeforepodafter (load increases)podpodpodScale OUTmore replicas, same pod sizebeforepodafter (load increases)podCPU/mem ↑Scale UPbigger pod, same replica count Comparison Table Aspect Horizontal Pod Autoscaler Vertical Pod Autoscaler What it adjusts Number of pod replicas in a Deployment/ReplicaSet/StatefulSet CPU and memory requests/limits on the pod’s containers Metrics source Metrics Server or custom/external metrics (CPU, memory, custom queries) via metrics.k8s.io API Historical and current usage sampled by the VPA recommender component Trigger condition Observed metric crosses a target threshold averaged across pods Recommender detects requests are consistently over- or under-provisioned Action taken Creates or deletes pod replicas to match target replica count Evicts and recreates pods with new resource requests (or just recommends, depending on updateMode) Disruption to running pods None — existing pods are untouched, new ones are added or removed Pod restart required to apply new resource values, causing brief downtime unless using in-place resize Best fit for workload type Stateless, horizontally scalable services behind a Service/load balancer Single-instance or hard-to-replicate workloads, or right-sizing before enabling HPA Conflict risk Can fight with VPA if both manage CPU on the same workload Should not manage CPU/memory targeted by HPA on the same workload simultaneously Configuration object HorizontalPodAutoscaler resource with min/max replicas and target metrics VerticalPodAutoscaler resource with updateMode (Off, Initial, Recreate, Auto) Key Differences HPA changes replica count, VPA changes resource requests on existing pods. VPA updates typically require a pod restart to take effect, while HPA scaling adds/removes pods without disrupting the rest. Running both on the same metric (like CPU) causes conflicting decisions unless carefully scoped. VPA is often used in recommendation-only mode to right-size requests before HPA takes over scaling. HPA assumes the workload is stateless and replicable; VPA fits singleton or stateful workloads that can’t simply be duplicated. When to Use Each Horizontal Pod Autoscaler ...

Overview Kubernetes uses liveness and readiness probes to answer two different questions about a running container: is it alive, and is it ready to serve requests. A failed liveness probe triggers a container restart, while a failed readiness probe only affects traffic routing by pulling the pod out of Service endpoints without killing it. Comparison Diagram Liveness ProbeReadiness ProbeContainerkubelet: is it alive?Fails?yesKill & Restart ContainernostaysrunningNo effect on Service trafficContainerkubelet: is it ready?Ready?yesAdded to Service EndpointsnoRemoved(not killed)Service / Load Balancer Comparison Table Aspect Liveness Probe Readiness Probe Core question Is the process still functioning? Is the process ready to accept traffic? Action on failure kubelet kills and restarts the container Container is left running, no restart Effect on Service endpoints None directly; pod may keep receiving traffic until restart completes Pod is removed from Service endpoints, stops receiving traffic Effect on rolling deployments Not consulted for rollout progress Must pass before the pod counts as available and rollout proceeds Restart count impact Increments the container restart count on each failure Never causes a restart Typical checks used Lightweight self-check for hangs or deadlocks Checks dependency health: DB connections, cache warm-up, config load Misconfiguration risk Too-aggressive thresholds cause restart loops (CrashLoopBackOff) Too-aggressive thresholds pull healthy pods out of rotation, cutting capacity Key Differences Liveness failure causes a container restart; readiness failure only removes the pod from Service endpoints. Liveness answers “is it alive,” readiness answers “is it ready for traffic.” Readiness gates rolling deployments; liveness has no say in rollout progress. Using a dependency check as a liveness probe risks a restart loop when the real problem is an external service, not the process. When to Use Each Liveness Probe ...

Overview Helm packages Kubernetes manifests as parameterized charts rendered through a Go templating engine, then tracks each install as a versioned release. Kustomize takes plain manifests and applies declarative overlays that patch a base configuration per environment, with no templating language or release state at all. Comparison Diagram HelmKustomizeCharttemplates/*.yaml + values.yamlhelm template / installRendered manifeststracked as a ReleaseClusterbase/plain manifestsoverlays/prodpatcheskustomize buildMerged manifestsno state trackedCluster Comparison Table Aspect Helm Kustomize Configuration model Go template engine that generates YAML text before it’s parsed Native Kubernetes objects patched via strategic merge or JSON patch Input format Chart with templates/, values.yaml, and Chart.yaml metadata Plain, valid YAML manifests plus a kustomization.yaml Parameterization Placeholder values injected as text, so output can become invalid YAML if misused Structured patches applied to already-valid objects, so output stays schema-correct Environment customization Layered values files (values-prod.yaml) merged into one chart Overlay directories per environment referencing a shared base Packaging & distribution Versioned, shareable chart archives published to chart repositories or OCI registries No packaging format; kustomization directories are just checked into git Dependency management Subcharts declared in Chart.yaml and pulled via helm dependency update Bases and components composed by referencing other directories Deployment execution helm install/upgrade tracks a named release and its revision history kustomize build pipes to kubectl apply with no release object created Rollback & drift helm rollback reverts to a stored prior release revision No built-in rollback; relies on git revert or kubectl’s own history Key Differences Helm renders manifests through text templating, while Kustomize edits already-parsed objects via structural patches Helm tracks installs as stateful releases with revision history; Kustomize has no release state at all Helm charts are packaged and versioned for reuse; Kustomize configs are just plain manifests in git Kustomize is built into kubectl directly, while Helm requires installing a separate CLI/tool Many teams combine both: a Helm chart as the base, customized per environment with Kustomize’s overlay patches When to Use Each Helm ...

Overview Immutable infrastructure treats servers as disposable artifacts — every change ships as a brand-new image that replaces the running instance rather than editing it. Mutable infrastructure instead updates in place, applying patches and config changes directly to long-lived servers. The choice determines how predictable, auditable, and drift-resistant your environments are. Comparison Diagram Immutable InfrastructureMutable InfrastructureImage v1Server v1terminatedImage v2Server v2live trafficchange = build new image,deploy new instance, discard oldServerv1 → v1.1 → v1.2patch in placechange = SSH in / run configmanagement, edit same instance Comparison Table Aspect Immutable Infrastructure Mutable Infrastructure Initial provisioning Instance built once from a versioned image or template Instance provisioned once, then edited repeatedly over its life Applying a change Rebuild the image with the change baked in SSH in, or run a config-management tool, against the live server Deployment mechanism Orchestrator replaces old instances with new ones (rolling/blue-green) Update scripts or agents (Ansible, Chef, Puppet) mutate the running instance Configuration drift Cannot occur — every instance matches its source image exactly Accumulates over time as ad hoc changes diverge from documented state Rollback Redeploy the prior image version, deterministic and fast Manually reverse changes on the server, often incomplete or unreliable Emergency hotfixes Requires rebuilding and redeploying an image, slower to react Can be patched directly on the box in seconds Auditability & reproducibility Image is a versioned artifact; environment is fully reproducible True state only knowable by inspecting the live server Pipeline & storage overhead Needs an image build pipeline and artifact/image registry Lower tooling overhead, no build pipeline required Key Differences Immutable instances are never touched after launch; mutable servers are patched in place. Immutable infrastructure eliminates configuration drift by construction. Rolling back immutable infra just means redeploying a prior image version. Mutable infra depends on ongoing config management tooling to keep state converged. Immutable workflows require an image build pipeline and registry that mutable setups skip. When to Use Each Immutable Infrastructure ...

Overview Both aim to automate software delivery, but they differ in who initiates the deployment and where the source of truth lives. Traditional CI/CD pushes changes into infrastructure from an external pipeline, while GitOps has an in-cluster agent continuously pull and reconcile state against a Git repository. The distinction matters most for security posture, drift handling, and auditability in Kubernetes-native environments. Comparison Diagram Traditional CI/CD push-based GitOps pull-based Git Repo merge trigger CI/CD Pipeline kubectl apply (holds cluster creds) Production Cluster external system pushes with cluster creds Git Repo Production Cluster (GitOps agent) pulls & diffs state agent auto-reconciles drift, no external creds Comparison Table Aspect Traditional CI/CD GitOps Deployment trigger Pipeline job runs on merge/tag and executes a deploy step In-cluster agent continuously polls or watches the Git repo for changes Source of truth Pipeline scripts and job history define what was deployed Git repository is the sole declarative source of desired state Cluster access model CI server holds cluster credentials and pushes from outside the network Agent runs inside the cluster; no external system needs cluster credentials Drift detection None built-in; manual kubectl edits go unnoticed until the next run Agent continuously compares live state to Git and flags or corrects drift Rollback Re-run the pipeline against a previous artifact or commit git revert triggers an automatic re-sync to the prior state Audit trail Split across CI logs, deploy scripts, and any manual changes Single, complete history captured in Git commit log Multi-cluster scaling Pipeline needs explicit logic and credentials per target environment Each cluster runs its own agent watching the same or a branched repo Key Differences CI/CD is push-based from an external system; GitOps is pull-based from inside the cluster GitOps treats the Git repo as the exclusive source of truth; CI/CD’s truth lives in pipeline state CI/CD requires the pipeline to hold cluster credentials; GitOps keeps them inside the cluster boundary GitOps performs automatic drift correction; CI/CD has no ongoing reconciliation Rollback in GitOps is a simple git revert instead of re-running a pipeline job When to Use Each Traditional CI/CD ...

Overview CI (Continuous Integration) and CD (Continuous Delivery/Deployment) are two connected stages of the same pipeline, not synonyms. CI focuses on automated testing of every code change as it merges, while CD focuses on automated deployment of that validated code into staging or production. Teams that only automate the first half often assume they have full ‘CI/CD’ when they’ve really just automated build-and-test. Comparison Diagram CICDCommitBuildTestPackageStagingProductionRuns automatically on every commitDelivery: manual approval before ProductionDeployment: fully automatic, no gateCI verifies the code — CD gets it running Comparison Table Aspect CI (Continuous Integration) CD (Continuous Delivery/Deployment) Trigger Code commit or push to a shared repository A successful CI run producing a new build artifact Core process Compile, run unit/integration tests, static analysis Package the artifact, provision environments, run deployment scripts Primary output A verified, mergeable build artifact A running release in staging and/or production Environment scope Build server or ephemeral test environment Staging and/or production environments Human gate None — fully automated on every commit Optional manual approval (Delivery) or none (Deployment) Release cadence N/A — runs per commit, not a release event Can range from multiple times a day to once per commit Failure consequence Blocks the merge; breaks the build for the team Blocks or rolls back the release; production stays on the last good version Primary goal Catch integration bugs early, keep the main branch releasable Get every releasable build to users quickly and safely Key Differences CI’s output is a verified build artifact, not a live release CD adds environment provisioning and deployment steps that CI never performs A CI failure blocks the merge; a CD failure blocks the rollout instead Continuous Delivery keeps a manual approval gate before production, while Continuous Deployment removes it CI runs on every single commit; CD can be throttled by environment or business readiness When to Use Each CI (Continuous Integration) ...

Overview Blue-green and canary deployment are both techniques for releasing new code with minimal downtime, but they differ in how traffic moves to the new version. Blue-green performs an instant cutover between two full environments, while canary performs a gradual rollout to a small slice of live traffic before expanding. Comparison Diagram Blue-GreenCanaryRouterBlueactiveGreenidle100%0%instant switch on cutoverRouterStable v195%Canary v25%gradual shift by percentage Comparison Table Aspect Blue-Green Deployment Canary Deployment Environment topology Two full, identical production environments (blue and green) Single environment with a small subset of new-version instances alongside the old Traffic routing Router/load balancer switches all traffic at once between environments Load balancer incrementally shifts a percentage of traffic from old to new Rollout progression Binary cutover: 0% or 100% to the new environment Staged progression, e.g. 5% -> 25% -> 50% -> 100% Validation approach New version smoke-tested in green before it receives any live traffic New version validated using real live traffic on a limited subset Rollback speed Instant - flip the router back to the blue environment Fast but partial - reduce canary percentage to 0, though some users already saw it Failure blast radius Zero pre-cutover, but 100% of users once switched Limited to whatever percentage of traffic is on the canary at the time Infrastructure cost Requires double full production capacity during the deploy window Requires only incremental capacity for the canary instances Tooling requirement Needs environment provisioning and DB/schema compatibility between versions Needs real-time metrics and automated analysis to judge canary health Key Differences Blue-green performs an instant router cutover; canary shifts traffic incrementally over stages. Blue-green requires duplicate infrastructure; canary needs only a small extra pool of instances. Canary limits failures to a traffic percentage, while blue-green exposes 100% of users the moment it cuts over. Canary depends on live metrics to progress safely; blue-green relies on pre-cutover testing in an isolated environment. When to Use Each Blue-Green Deployment ...