How Infrastructure & DevOps Works

A Content Delivery Network (CDN) is a globally distributed network of servers (called edge nodes or Points of Presence) that cache copies of your content close to users. Instead of every user's request travelling to your origin server in Virginia, a user in Tokyo gets the content from a CDN edge server in Tokyo — 5ms instead of 200ms. CDNs reduce latency, absorb traffic spikes, protect against DDoS, and cut your origin server's bandwidth costs.

GitHub Actions is a CI/CD platform built into GitHub. You define workflows in YAML that run automatically on events — a push, a pull request, a schedule — to build, test, and deploy your code. A workflow contains jobs, each a set of steps that run on a runner (a virtual machine). Steps can run shell commands or reusable actions from the marketplace, and secrets keep credentials safe. It turns your repository into an automated pipeline with no separate CI server to manage.

Containers and virtual machines both isolate workloads, but at different levels. A virtual machine runs a full guest operating system on top of a hypervisor, so each VM carries its own kernel — heavy but strongly isolated. A Docker container shares the host operating system kernel and packages just the application and its dependencies, making it far smaller and faster to start. Containers win on density and speed; VMs win on isolation and running different OS kernels.

A reverse proxy is a server that sits in front of one or more backend servers and forwards client requests to them. To the outside world it looks like the application; the real servers stay hidden behind it. This single entry point is the natural place to handle cross-cutting concerns: load balancing across backends, TLS termination, caching, compression, request routing, and security. It differs from a forward proxy, which sits in front of clients rather than servers.

Docker packages your application and all its dependencies into a container — an isolated process that runs the same way everywhere. Under the hood, containers are not virtual machines. They are regular Linux processes isolated using three kernel features: namespaces (what a process can see), cgroups (how much CPU/memory it can use), and union filesystems (layered, copy-on-write storage). Docker adds a developer-friendly layer of tooling on top of these primitives.

Kubernetes is a container orchestration system: you tell it what you want (run 10 replicas of this container, keep them alive, expose them on port 80) and it continuously works to make reality match your desired state. It handles scheduling containers onto nodes, replacing crashed containers, scaling up on load, rolling out updates without downtime, and load balancing traffic. Kubernetes turned the operational complexity of running thousands of containers into a declarative configuration problem.

A load balancer sits between clients and your servers and distributes incoming requests across multiple backend instances. Without a load balancer, scaling horizontally is impossible — all traffic would hit a single server. A load balancer also monitors server health and stops sending traffic to unhealthy instances, providing both scalability and high availability. Modern load balancers also handle SSL termination, routing by path/hostname, and connection draining.

CI/CD (Continuous Integration / Continuous Delivery) is the practice of automating the steps between writing code and running it in production. Every code push triggers a pipeline: run tests, build a container image, push it to a registry, deploy to staging, run integration tests, and deploy to production — all without manual steps. The goal is to ship code changes in minutes rather than weeks, catch bugs early when they're cheap to fix, and make deployments a boring, routine event rather than a stressful ceremony.

Terraform is an infrastructure-as-code tool: you describe the cloud resources you want in declarative configuration, and Terraform makes reality match. Instead of clicking through a console, you write what should exist, and Terraform figures out what to create, change, or destroy. It tracks what it manages in a state file, shows you a plan before making changes, and uses providers to talk to AWS, GCP, Azure, and hundreds of other platforms.

GitOps is a way to deploy and manage infrastructure where Git is the single source of truth for the desired state. You describe what should be running (usually as Kubernetes manifests) in a Git repository, and an automated controller continuously compares the live system to Git and reconciles any difference. Deployments become git commits, rollbacks become git reverts, and the cluster is always kept in sync with the repository — auditable, automated, and self-healing.

Platform engineering is the practice of building an Internal Developer Platform (IDP) — a curated set of self-service tools and workflows that let application developers ship software without wrestling with the underlying infrastructure. It is a response to DevOps sprawl: as tooling exploded, every team was expected to master Kubernetes, CI/CD, cloud, and observability. A platform team packages the best practices into paved "golden paths," reducing cognitive load so developers focus on features.

Observability is the ability to understand what is happening inside a system from the data it emits — without shipping new code to investigate. It rests on three pillars: metrics (numeric measurements over time), logs (timestamped records of events), and traces (the path of a request across services). Traditional monitoring watches for known problems; observability lets you ask new questions and debug the "unknown unknowns" that plague complex distributed systems.

Prometheus is an open-source monitoring system built around a time-series database. Unlike tools that receive pushed metrics, Prometheus pulls (scrapes) metrics from your services over HTTP at regular intervals. It stores each measurement as a time series identified by a name and labels, lets you query and aggregate them with PromQL, and fires alerts through Alertmanager. Paired with Grafana for dashboards, it is a de facto standard for cloud-native metrics.

OpenTelemetry (OTel) is the vendor-neutral, open standard for generating and collecting telemetry — traces, metrics, and logs — from your applications. Instead of locking into one vendor SDK, you instrument your code once with OpenTelemetry, and export the data to any compatible backend (Jaeger, Prometheus, Grafana, or commercial tools). It provides SDKs, automatic instrumentation for common frameworks, a standard wire protocol (OTLP), and a Collector to process and route the data.

Blue-green and canary are two strategies for releasing new software with minimal risk and downtime. Blue-green runs two identical environments — the current one (blue) and the new one (green) — and switches all traffic at once, enabling an instant rollback by switching back. Canary releases the new version to a small slice of users first, watches metrics, and gradually ramps up if all looks healthy. Both avoid the risky "deploy to everyone at once" of a naive release.

Serverless does not mean there are no servers — it means you never manage them. You deploy code as functions, and the cloud provider runs them on demand, automatically scaling from zero to thousands of concurrent executions and charging only for the time your code actually runs. Functions are triggered by events — an HTTP request, a file upload, a queue message. The trade-offs are cold starts, execution limits, and less control, in exchange for no capacity planning and true pay-per-use.

Helm is the package manager for Kubernetes. Deploying an app to Kubernetes means writing lots of YAML — deployments, services, config maps, ingresses — often nearly identical across environments. Helm packages these into a reusable, parameterised bundle called a chart. You supply a values file to customise it, and Helm renders the templates into final manifests and installs them as a tracked release you can upgrade and roll back — turning sprawling YAML into a versioned, shareable package.

Nginx is a high-performance web server that also works as a reverse proxy, load balancer, and cache. Its power comes from an event-driven, asynchronous architecture: a small number of worker processes each handle thousands of connections using an event loop, instead of one thread or process per connection. This lets Nginx serve huge concurrency with low memory. In modern stacks it usually sits in front of application servers, handling TLS, routing, load balancing, and static content.

Autoscaling automatically adjusts capacity to match demand, so a system stays responsive under load without paying for idle resources during quiet periods. It watches metrics — CPU, memory, request rate, or a custom signal — and adds or removes instances as those metrics cross thresholds. In Kubernetes this comes in layers: the Horizontal Pod Autoscaler adds pods, the Vertical Pod Autoscaler resizes them, and the Cluster Autoscaler adds nodes when pods have nowhere to run.

Secrets management is how applications store and access sensitive credentials — database passwords, API keys, TLS certificates — without exposing them. Hardcoding secrets in code or config is dangerous: they leak through version control, logs, and images. A secrets manager (like HashiCorp Vault or a cloud KMS) centralises secrets, encrypts them, controls who can read each one, audits access, and can rotate them automatically — even issuing short-lived, dynamic secrets that expire on their own.

Container networking gives each container its own network identity while letting containers talk to each other, the host, and the outside world. It builds on Linux network namespaces — each container gets its own isolated network stack — connected by virtual interfaces to a bridge on the host. On a single host, a bridge network handles this; across many hosts, an overlay network makes containers appear on one flat virtual network. Kubernetes standardises all of it through the CNI plugin model.

A Kubernetes operator extends Kubernetes to manage complex applications the same way Kubernetes manages built-in resources. It combines a Custom Resource Definition (CRD) — a new resource type like a PostgresCluster — with a controller that continuously reconciles the real world to match that resource desired state. In effect, an operator encodes the operational knowledge of a human expert (how to deploy, back up, upgrade, and recover an app) as software that runs the app for you.

Envoy is a high-performance Layer 7 proxy designed for cloud-native systems and the data plane of most service meshes. It handles traffic between services with rich features — load balancing, retries, timeouts, circuit breaking, mTLS, and deep observability — all applied consistently and configurable at runtime. Its defining trait is dynamic configuration via the xDS APIs: a control plane pushes updates to Envoy live, without restarts, which is what makes service meshes possible.

eBPF lets you run small, sandboxed programs inside the Linux kernel without changing kernel source or loading risky kernel modules. You attach an eBPF program to a hook — a network packet arriving, a system call, a function entry — and it runs safely in kernel space with near-native speed. A verifier proves each program is safe before it runs, and maps let it share data with user space. eBPF has become the foundation for a new generation of observability, networking, and security tools.

WebAssembly (Wasm) is a portable binary instruction format that runs at near-native speed in a secure sandbox. Originally built to run compiled languages like C, C++, and Rust in the browser, it is now spreading to the server and edge. A Wasm module is compiled once and runs anywhere there is a Wasm runtime, isolated from the host by default. With WASI (the WebAssembly System Interface) giving it controlled access to files and networking, Wasm is emerging as a lightweight, fast, secure alternative to containers for certain workloads.