February 22, 2026A Software Bill of Materials is a machine-readable inventory of every component in a software artifact. It lists packages, libraries, versions, licenses, and dependency relationships. An SBOM answers the question: what exactly is inside this container image, binary, or repository?
When a new CVE drops, organizations without SBOMs scramble to determine which systems are affected. Organizations with SBOMs query a database and have the answer in seconds.
February 22, 2026Your container image contains hundreds of dependencies you did not write. A compromised base image or malicious package runs with your application’s full permissions. Supply chain attacks target the build process because it is often less guarded than runtime.
The goal is to answer three questions for every artifact: what is in it (SBOM), who built it (signing), and how was it built (provenance).
A Software Bill of Materials lists every dependency in an artifact. Two tools dominate.
February 22, 2026SQLite is not a toy database. It handles more read traffic than any other database engine in the world – every Android phone, iOS device, and major web browser runs SQLite. The question is whether your workload fits its concurrency model: single-writer, multiple-reader. If it does, SQLite eliminates an entire class of operational overhead with no server process, no network protocol, and no connection authentication.
Write-Ahead Logging (WAL) mode is the single most important configuration for production SQLite. In the default rollback journal mode, writers block readers and readers block writers. WAL removes this limitation.
February 22, 2026Site Reliability Engineering treats operations as a software engineering problem. Instead of a wall between developers who ship features and operators who keep things running, SRE defines reliability as a feature – one that can be measured, budgeted, and traded against velocity. The core insight is that 100% reliability is the wrong target. Users cannot tell the difference between 99.99% and 100%, but the engineering cost to close that gap is enormous. SRE makes this tradeoff explicit through service level objectives.
February 22, 2026Deployments treat pods as interchangeable. StatefulSets do not – each pod gets a stable hostname, a persistent volume, and an ordered startup sequence. This is what you need for databases, message queues, and any workload where identity matters.
| Feature | Deployment | StatefulSet |
|---|---|---|
| Pod names | Random suffix (web-api-6d4f8) | Ordinal index (postgres-0, postgres-1) |
| Startup order | All at once | Sequential (0, then 1, then 2) |
| Stable network identity | No | Yes, via headless Service |
| Persistent storage | Shared or none | Per-pod via volumeClaimTemplates |
| Scaling down | Removes random pods | Removes highest ordinal first |
Use StatefulSets when your application needs any of: stable hostnames, ordered deployment/scaling, or per-pod persistent storage. Common examples: PostgreSQL, MySQL, Redis Sentinel, Kafka, ZooKeeper, Elasticsearch.
February 22, 2026Static validation catches infrastructure errors before anything is deployed. No cluster needed, no cloud credentials needed, no cost incurred. These tools analyze configuration files – Helm charts, Kubernetes manifests, Terraform modules, Kustomize overlays – and report problems that would cause failures at deploy time.
Static validation does not replace integration testing. It cannot verify that a service starts successfully, that a pod can pull its image, or that a database accepts connections. What it catches are structural errors: malformed YAML, invalid API versions, missing required fields, policy violations, deprecated resources, and misconfigured values. In practice, this covers roughly 40% of infrastructure issues – the ones that are cheapest to find and cheapest to fix.
February 22, 2026A status page is the single source of truth for service health. It communicates current status, provides historical reliability data, and sets expectations during incidents through regular updates. A well-maintained status page reduces support tickets during incidents, builds customer trust, and gives teams a structured communication channel.
The most widely adopted hosted solution. Integrates with the Atlassian ecosystem.
# Create a component
curl -X POST https://api.statuspage.io/v1/pages/${PAGE_ID}/components \
-H "Authorization: OAuth ${API_KEY}" \
-d '{"component": {"name": "API", "status": "operational", "showcase": true}}'
# Create an incident
curl -X POST https://api.statuspage.io/v1/pages/${PAGE_ID}/incidents \
-H "Authorization: OAuth ${API_KEY}" \
-d '{"incident": {"name": "Elevated Error Rates", "status": "investigating",
"impact_override": "minor", "component_ids": ["id"]}}'Strengths: Highly reliable, subscriber notifications built-in, custom domains, API-first. Weaknesses: Expensive ($399+/month business plan), limited customization, component limits on lower tiers.
February 22, 2026Small models (2-7B parameters) produce structured output that is 85-95% as accurate as cloud APIs for well-defined extraction and classification tasks. The key is constraining the output space so the model’s limited reasoning capacity is focused on filling fields rather than deciding what to generate.
This is where local models genuinely compete with — and sometimes match — models 30x their size.
Ollama’s JSON mode forces the model to produce valid JSON:
February 22, 2026Agents need structured data from LLMs – not free-form text with JSON somewhere inside it. When an agent asks a model to classify a bug as critical/medium/low and gets back a paragraph explaining the classification, the agent cannot act on it programmatically. Structured output is the bridge between LLM reasoning and deterministic code.
The simplest approach. Tell the API to return valid JSON and describe the shape you want in the prompt.
February 22, 2026An on-call engineer paged at 3 AM has limited cognitive capacity. They may not be familiar with the specific service that is failing. They may have joined the team two weeks ago. A runbook bridges the gap between the alert firing and the correct human response. Without runbooks, incident response depends on tribal knowledge – the engineer who built the service and knows its failure modes. That engineer is on vacation when the incident hits.