Orchestration

Overview Orchestration and choreography are two ways to coordinate multiple services in a distributed system or workflow. Orchestration relies on a central controller that explicitly directs each step, while choreography lets services independently respond to event reactions with no single component in charge. The choice shapes coupling, visibility, and how easily the workflow evolves over time. Comparison Diagram OrchestrationChoreographyOrchestratorService AService BService CCentral controller directs each stepService XService YService ZeventeventeventServices react to each other's events Comparison Table Aspect Orchestration Choreography Control flow A central orchestrator explicitly invokes and sequences each step Each service reacts to events independently; no component sequences the whole flow Coupling Services couple to the orchestrator’s contract, not to each other Services couple to shared event schemas rather than a controller Workflow knowledge Orchestrator holds the full picture; services only know their own task No single component knows the entire workflow, only its trigger and reaction Failure handling Retries and compensation logic live centrally in the orchestrator Compensation is distributed, with services reacting to failure events themselves Adding new steps Requires modifying the orchestrator to include the new call A new service just subscribes to existing events with no central change Observability Single place to trace and inspect current workflow state Requires aggregating distributed logs and traces across services Failure/scaling risk Orchestrator can become a bottleneck or single point of failure Overall flow becomes hard to see, risking uncoordinated ’event sprawl' Typical tooling BPMN engines, AWS Step Functions, Temporal, Camunda Message brokers and event buses like Kafka, SNS/SQS, domain events Key Differences Orchestration uses a central controller; choreography relies on services reacting to events Orchestration couples services to the controller; choreography couples them to event contracts Extending orchestration means updating the orchestrator; extending choreography just means subscribing to events Orchestration gives centralized visibility; choreography requires distributed tracing to see the full flow Orchestration risks a bottleneck at the controller; choreography risks workflow sprawl across services When to Use Each Orchestration ...

Overview Both are Kubernetes controllers that manage sets of pods from a template, but they solve different problems: a Deployment treats pods as interchangeable, disposable replicas, while a StatefulSet gives each pod a stable name, network identity, and persistent storage that survives rescheduling. The choice matters because workloads like databases or clustered systems break if pod identity or storage isn’t preserved across restarts. Comparison Diagram DeploymentStatefulSetweb-7f9d4cweb-x9y8z2web-m4n5p6interchangeable, no stable identityweb-0web-1web-2pvc-0pvc-1pvc-2stable name, network ID & storage per pod Comparison Table Aspect Deployment StatefulSet Pod naming Random hash suffix per replica (web-7f9d4c-x2z9p), changes on every recreation Stable ordinal index (web-0, web-1, web-2) fixed for the pod’s lifetime Network identity Pods share a single Service VIP/DNS; individual pods have no predictable DNS name Requires a headless Service; each pod gets a stable DNS entry (web-0.svc.namespace) Storage PVCs, if used, aren’t guaranteed to reattach to the same pod on recreation volumeClaimTemplates provision a dedicated PVC per pod that persists and reattaches Scaling Creates or removes pods in parallel, in any order Scales one pod at a time in strict ordinal order (0, 1, 2, …) Rolling updates Replaces pods per maxSurge/maxUnavailable, order not guaranteed Updates pods one at a time in reverse ordinal order (N-1 down to 0) by default Failure recovery Replacement pod gets a new name and no guaranteed storage continuity Replacement pod keeps the same name/identity and reattaches its original PVC Typical workload Stateless web servers, APIs, workers that scale horizontally Databases, message queues, and clustered systems needing stable peers Key Differences Deployment pods get random names on every recreation, while StatefulSet pods keep a fixed ordinal name for life Only StatefulSet supports volumeClaimTemplates, giving each pod its own persistent volume that survives rescheduling StatefulSet requires a headless Service to give each pod a resolvable, stable DNS entry StatefulSet scales and updates pods in strict ordinal order; Deployment does both in parallel On node failure, Deployment pods lose their identity entirely, while StatefulSet pods are recreated with the same identity When to Use Each Deployment ...

Overview Docker packages an application and its dependencies into a portable container image and runs it on a single host, while Kubernetes schedules, scales, and heals many containers across a cluster of machines. They aren’t direct substitutes — Kubernetes typically runs containers built by Docker (or another OCI-compatible tool), sitting one layer above it. Comparison Diagram DockerKubernetesSingle Hostapp Aapp Bapp Cidledocker runmanual, per-hostif host dies, all lostControl PlaneNode 1Node 2Node 3scheduler places podsauto-reschedules on failuredeclarative, cluster-wide Comparison Table Aspect Docker Kubernetes Core purpose Build, package, and run containers from a single image spec Orchestrate and manage many containers across a fleet of machines Unit of work Container, defined by a Dockerfile and run via docker run Pod, a group of one or more containers scheduled together Deployment scope Single host (or manually scripted across hosts) Multi-node cluster with a control plane scheduling workloads Configuration model Imperative CLI commands or docker-compose.yml Declarative YAML manifests reconciled continuously toward desired state Networking & discovery User-defined bridge networks and container name resolution Cluster-wide Services, DNS, and Ingress across nodes Scaling Manual — start more containers or use docker-compose scale Automated via ReplicaSets and Horizontal Pod Autoscaler Failure recovery No built-in restart across host failure; relies on restart policies per host Self-healing — reschedules pods automatically if a node or container fails Rollouts & updates Rebuild image and manually restart containers Rolling updates and rollbacks managed declaratively per Deployment Key Differences Docker operates at the level of a single container; Kubernetes operates at the level of a cluster. Kubernetes doesn’t replace Docker — it typically schedules containers that Docker (or another container runtime) built and runs. Docker’s model is largely imperative, while Kubernetes is fundamentally declarative, continuously reconciling actual state to desired state. Kubernetes adds self-healing and autoscaling that plain Docker has no native concept of. For a single app on one machine, Kubernetes’ control plane overhead is often unjustified complexity. When to Use Each Docker ...