Archive
1290 posts · Page 41 of 108. ← Blog
Why an API is only as good as a developer's ability to succeed with it — the OpenAPI contract as the source of truth, reference docs versus guides, errors as documentation, and the DX niceties that turn a first request into a shipped integration.
An API is only as good as a developer's ability to succeed with it: OpenAPI as the machine-readable contract (docs, SDKs, mocks, contract tests), reference plus guides, errors as documentation, and optimizing time-to-first-successful-call.
How to design a system that keeps serving when its parts fail — the vocabulary of availability, the patterns that contain failure, and the Go primitives that make retries, limits, and fallbacks safe rather than dangerous.
Designing systems that survive failure: the nines and SLI/SLO/error budgets, eliminating single points of failure, timeouts and retries with backoff+jitter made safe by idempotency, circuit breakers, rate limiting and load shedding, and graceful degradation.
The capstone of this series — assembling roles, a use-case inventory, lifecycle gates, and policy-as-code into a right-sized governance program that produces evidence instead of paperwork, without crushing the velocity of a two-person team or failing an enterprise audit.
The capstone: assemble a right-sized governance program — roles and accountability, a model/use-case inventory as the backbone, lifecycle gates, and policy-as-code that blocks deploy when an owner, risk tier, model card, eval pass, or monitor is missing.
Part seven of the AI Security Engineering series: DevSecOps for AI systems — securing the secrets, network, supply chain, prompts, and CI/CD gates that surround the model, so a hardened model doesn't sit inside a soft pipeline.
DevSecOps for AI: secrets in a manager not code, least-privilege runtime identities (no ambient prod creds for agents), egress control, rate/spend limits against model DoS, supply-chain verification in CI, prompts-as-code, and a security-eval gate that fails the build.
Taking a watsonx.ai system from a notebook to production in Python — deployment spaces, reliability with retries and fallbacks, cost and throughput control, observability wired to watsonx.governance, and a hardening checklist.
Run a watsonx system in production from Python: IBM Cloud vs Cloud Pak for Data, project_id vs deployment spaces, reliability (tenacity retries, IAM token refresh, fallback), token-based cost, observability wired to watsonx.governance monitors, and securing IAM credentials.
Taking an NVIDIA-stack LLM system from a working prototype to something you trust in production — reliability, cost and throughput, observability, and security — all from Python, with the OpenAI-compatible surface keeping the code stable whether you burst to the API Catalog or run your own NIM.
Run an NVIDIA-stack LLM system in production from Python: hosted vs self-hosted vs hybrid, reliability (client retries, tenacity backoff, readiness probes, fallback), the GPU-hours cost model, Prometheus observability across the pipeline, and securing nvapi-/NGC keys.
Before a single word goes into the index, it passes through a quiet, decisive step: text analysis. Deciding what counts as a "word," how to normalize it, and which words to keep is what lets a search for "running" find a document about "ran," and what makes "The" not clog the index. Get analysis right and search feels intelligent; get it wrong and no clever ranking can save it. This post is about the unglamorous preprocessing that quietly determines search quality.
Before a word hits the index it passes through text analysis: tokenization (what is a word?), normalization (case folding, stemming vs lemmatization), stop words, and synonyms. The unglamorous step where a huge share of search quality is won — and where query and documents must speak the same vocabulary.
A gRPC service that works on localhost is a long way from one that runs reliably at scale. Production raises questions localhost never does: how do calls get load-balanced when connections are long-lived? How do you secure them, expose them to browsers, observe them, and evolve the contract without breaking anyone? This closing post covers what it takes to run gRPC for real.
A gRPC service that works on localhost is far from one that runs reliably at scale. Production raises questions localhost never does: how do calls get load-balanced when connections are long-lived? How do you secure them, expose them to browsers, observe them, and evolve the contract without breaking anyone? This closing post covers running gRPC for real.
Symmetric encryption is the workhorse of confidentiality — the same fast primitive protecting your disk, your database fields, and every byte inside a TLS connection. But "encrypt this" is a trap: raw encryption alone doesn't stop tampering, block ciphers need a mode of operation, and modes need nonces that must never repeat. The single right answer for almost every case is authenticated encryption, and this post explains why.
Symmetric encryption is the workhorse of confidentiality — but 'encrypt this' is a trap. Raw encryption doesn't stop tampering, block ciphers need a mode, and nonces must never repeat. The right answer for almost every case is authenticated encryption (AEAD), and this post explains why.
Model quality is bounded by data quality, and the defects you tolerate here — poor lineage, silent drift, unmanaged PII, careless retrieval — resurface downstream as hallucinations, bias, privacy incidents, and un-auditable decisions.
Model quality is bounded by data quality; poor lineage, silent drift, unmanaged PII, and careless retrieval resurface as hallucinations and privacy incidents. Phase 2: the governed data foundation.
An LLM demo costs almost nothing, so teams ship without a cost model — and then production traffic turns a rounding error into the biggest line item on the bill.
An LLM demo costs almost nothing, so teams ship without a cost model — then production traffic turns a rounding error into the biggest line item on the bill. Why AI costs explode, and how to see it coming.
Prompt engineering was about wording a single instruction well; context engineering is the broader discipline of deciding everything a model sees at inference time — and for agents, it is the discipline that matters most.
Prompt engineering was about wording one instruction well; context engineering is the broader discipline of deciding everything a model sees at inference — and for agents it is the skill that matters most.