Every article published on xx0 Labs, in one place. Filter by category or search by keyword — filtering runs entirely in your browser, with no data sent anywhere.
The twelve-factor app is a set of principles for building cloud-native applications, published by developers at Heroku, covering configuration, dependencies, and process design; more than a decade later, most of its core ideas — like strict separation of config from code, and treating processes as stateless and disposable — remain standard practice, even as the specific platform assumptions behind a few of the original factors have shifted.
A message queue lets a service hand off work without waiting for it to be processed immediately, decoupling producer and consumer in time as well as in code; publish-subscribe extends this to many independent consumers reacting to the same event, and event-driven architecture built on these patterns trades the simplicity of direct, synchronous calls for resilience to temporary failures and independent scalability, at the cost of harder-to-trace, eventually-consistent behavior.
Spot instances sell a cloud provider's unused compute capacity at a steep discount compared to on-demand pricing, in exchange for the provider being able to reclaim that capacity with little notice when it's needed elsewhere; the discount is real and substantial, but it's only a good trade for workloads that can actually tolerate interruption, which rules out plenty of applications by design.
A monolith deploys as a single unit and keeps components in-process, which is simple to develop and operate at small scale but couples every part's deployment and scaling together; microservices split an application into independently deployable services, gaining independent scaling and deployment at the cost of network calls between components that were previously simple in-process function calls, and all the distributed-systems complexity that comes with it.
A service mesh is a dedicated infrastructure layer, typically implemented as sidecar proxies alongside each service instance, that handles service-to-service traffic management, security, and observability — moving that logic out of application code and into infrastructure; it solves a real problem for organizations running many interdependent microservices, and adds real operational complexity that isn't worth it for simpler architectures.
The CAP theorem proves that a distributed data system can't simultaneously guarantee consistency, availability, and partition tolerance; because network partitions are a real possibility that has to be tolerated, the actual choice every distributed database makes is between consistency and availability specifically during a partition, not a free choice among all three properties at once.
Replication keeps multiple copies of the same data on different nodes, providing redundancy and the ability to scale read traffic across replicas; sharding splits a dataset across multiple nodes so no single node holds all of it, which is what allows write throughput and total data volume to scale beyond what any one machine can handle — and most large-scale systems eventually need both, for different reasons.
A naive retry policy — retrying a failed request immediately, without limit — can turn a struggling but recoverable service into a fully failed one, by piling additional retried load onto exactly the service that's already overwhelmed; circuit breakers stop sending requests to a failing dependency for a cooldown period, and exponential backoff with jitter spreads out retries over time, both specifically to prevent this feedback loop.
A runbook is a documented procedure for diagnosing or resolving a specific, known operational scenario; the difference between a runbook that actually gets used during an incident and one that gets ignored usually comes down to whether it's kept current, tested against reality, and written for someone acting under real time pressure rather than for completeness.
Alert fatigue happens when the volume of low-value or non-actionable alerts is high enough that engineers start treating all alerts, including genuine ones, as background noise; the fix isn't more alerts or more sensitive thresholds, it's fewer, better ones — alerting only on symptoms that need a human right now, tied to concrete signals like the four golden signals or a defined error budget.
The four golden signals — latency, traffic, errors, and saturation — are a practical starting framework for deciding what to monitor on any user-facing service; together they cover how fast requests are handled, how much load the system is under, how often things fail, and how close the system is to its capacity limits, which is a more disciplined starting point than monitoring whatever metrics happen to be easiest to collect.
A distributed trace follows a single request as it moves through multiple services, made up of individual timed spans linked together by shared trace context that's passed along with the request; OpenTelemetry is the vendor-neutral standard that defines how this data is generated and exported, which matters because it prevents instrumentation from locking an application into one specific observability vendor.
Chaos engineering is the discipline of deliberately, carefully injecting failure into a system in a controlled way to test whether it actually behaves as resiliently as assumed; the point isn't to cause damage, but to find weaknesses in a planned experiment, with a defined blast radius and an abort mechanism, rather than discovering them for the first time during a real, unplanned outage.
A monorepo keeps many projects or services in a single version-controlled repository, making cross-project changes and dependency consistency easier at the cost of needing CI/CD tooling that scales to a large, shared codebase; a polyrepo keeps each project independent, which simplifies per-project tooling and ownership but pushes the cost of coordinating changes across repositories onto the teams that have to do it manually.
Secrets leak from CI/CD pipelines through a small number of recurring patterns — hardcoded credentials in source control, secrets printed to build logs, and overly broad pipeline permissions — and the core defenses are keeping secrets out of version control entirely, using a dedicated secrets manager, preferring short-lived over long-lived credentials, and applying least privilege to what a pipeline is actually allowed to access.
An immutable build artifact is built exactly once, then promoted unchanged through every subsequent environment — test, staging, production — rather than being rebuilt separately for each one; this guarantees that what was actually tested is byte-for-byte identical to what ships, closing off an entire category of 'it worked in staging' failures caused by environments quietly building slightly different things.
Smaller Docker images start faster, transfer faster, and have a smaller attack surface; multi-stage builds and minimal base images are the two techniques that do the most to shrink them, while understanding how image layers and caching actually work is what makes builds fast to iterate on, not just fast to run.
A feature flag is a conditional check that determines, at runtime, whether a piece of code is active — which lets a team deploy new code to production while keeping it dark, then turn it on separately, for specific users or gradually, without a further code deployment; that separation of deployment from release is the core idea, and it comes with real ongoing cost in flag cleanup and testing complexity.
GitOps is a specific operational pattern built on top of infrastructure as code: a Git repository is treated as the single source of truth for desired system state, and an automated agent continuously reconciles the live system to match it — which means every change is inherently version-controlled, reviewable, and auditable, and manual out-of-band changes get automatically corrected rather than silently tolerated.
Cloud identity and access management (IAM) controls who and what can do what to which resources; the principle of least privilege means granting only the specific permissions a given identity actually needs to do its job, no more — a standard that's simple to state and consistently hard to maintain as systems grow, which is exactly why over-permissioning is one of the most common cloud security gaps.
A virtual private cloud (VPC) is a logically isolated section of a public cloud provider's network, defined by an address range you control, subdivided into subnets, and connected to the internet or other networks only through gateways and route tables you explicitly configure — the foundation almost every other piece of cloud network security is built on top of.
A load balancer distributes incoming traffic across multiple backend servers so no single one is overwhelmed; layer 4 load balancers route based on network-level information alone and are fast and simple, while layer 7 load balancers read the actual application request content and can route far more intelligently, at the cost of more processing overhead.
Block storage presents raw, addressable chunks of storage that an operating system formats and manages, typically for a single attached server; file storage organizes data in a shared hierarchical directory structure multiple systems can access at once; object storage stores whole files as objects with metadata, accessed over HTTP APIs, and scales far beyond what either of the other two models is designed for.
Multi-cloud means deliberately running workloads across more than one provider; it offers real benefits — avoiding lock-in, meeting specific compliance needs, negotiating leverage — but each of those benefits comes with a genuine operational cost in complexity, and 'multi-cloud by accident' from unmanaged sprawl is a liability, not a strategy.
A content delivery network caches copies of content across many geographically distributed servers, so a user's request is served from a location physically close to them instead of a single origin server, which is what actually reduces latency — and a CDN also commonly absorbs traffic spikes and some categories of attack traffic before they reach your origin at all.
Cloud computing's core idea — computing as a metered, shared utility — predates the term by decades; the modern industry traces to Amazon Web Services launching S3 and EC2 in 2006, followed by Google and Microsoft's competing platforms, then a second wave built on Docker containers (2013) and Kubernetes orchestration (2014), which gave rise to today's infrastructure-as-code and CI/CD practices.
Virtual machines offer the most control and the slowest startup, billed for uptime; containers package an application with its dependencies for fast, portable startup, typically orchestrated with Kubernetes; serverless functions remove server management entirely, scale to zero, and bill per invocation — and the right choice depends on how a workload's traffic and control needs actually behave, not which model is newest.
Cloud bills tend to grow out of control for a handful of recurring, well-understood reasons — unused ('zombie') resources, data transfer charges, oversized instances, and a lack of cost visibility — and cost allocation tagging is the main mechanism that turns an opaque total bill into spend attributable to specific teams and projects.
On-call is a rotation of engineers responsible for responding to production alerts outside normal hours; effective incident response also depends on clear severity levels, a defined incident commander role during major incidents, and a blameless postmortem process that treats failures as system problems to learn from rather than individual mistakes to punish.
An SLI is a measured signal of service health (like request latency or error rate), an SLO is a target value for that signal over time, and an error budget is the amount of allowed unreliability implied by the gap between an SLO and perfect performance — a budget that, once spent, is meant to shift priority toward reliability work.
Observability is the property of being able to understand a system's internal state from its external outputs, including questions you didn't anticipate in advance; logs, metrics, and traces are the three complementary data types that make that possible, and each answers a different kind of question.
Blue-green deployment cuts traffic from the old version to the new one all at once between two full environments, giving an instant rollback; canary releases shift traffic to the new version gradually, in small increments, trading a slower rollout for earlier, smaller-blast-radius detection of problems.
Infrastructure as code means defining servers, networks, and other resources in versioned configuration files rather than provisioning them by hand; declarative tools like Terraform compare that configuration against current real-world state and compute a plan of changes before applying anything.
CI/CD bundles three related but distinct practices: continuous integration (frequently merging and automatically testing code), continuous delivery (keeping every change deployable, with a manual release gate), and continuous deployment (removing that gate entirely) — and conflating them leads to real confusion about what a pipeline actually guarantees.
The core trade-off between cloud and on-premises infrastructure is capital versus operational spending and fixed versus elastic capacity; cloud shifts operational burden to the provider and makes scaling near-instant, at the cost of ongoing usage-based billing and less low-level control.
Cloud providers organize infrastructure into geographic regions, each built from multiple physically isolated availability zones; where you place workloads within that structure directly determines your latency to users, your resilience to data center failures, and often your bill.
Cloud computing is on-demand, self-service access to shared, elastic computing resources billed by usage; IaaS, PaaS, and SaaS describe how much of the underlying stack the provider manages for you versus how much you manage yourself.
No articles match your search. Try a different keyword or category.