// STRYKE-AZURE — ENGINEERING REPORT

>_EXECUTIVE SUMMARY

stryke-azure is an opt-in connector package in the stryke ecosystem — the Azure counterpart to stryke-aws. It exposes Blob Storage, Storage Queues, Cosmos DB, Key Vault Secrets and Keys, and Entra identity as the typed data plane, plus an Azure Resource Manager management plane (Virtual Machines, Storage-account management, Service Bus, Monitor, Container Instances / AKS, Resource Groups, Subscriptions) — all under the Azure package. The data plane is built on the official Azure SDK for Rust (GA 1.0.0; Cosmos on the 0.35.0 preview).

The SDK pulls in tokio, hyper, rustls, reqwest, and the typespec client-core plus per-service generated models — a dependency tree that ships once, on demand, as an opt-in package. stryke core is never linked against it. The management plane has no GA typed Rust SDK crate, so those ops reach ARM over REST — reusing the same shared Entra credential and the same azure_core HTTP client the typed data-plane clients use.

~ARCHITECTURE

A single in-process cdylib. The stryke side is a thin .stk library; the heavy SDK code lives in libstryke_azure and is dlopened on first use Azure. No sidecar process, no fork per call.

~SERVICE MAPPING

The surface tracks stryke-aws, remapped onto Azure's GA Rust SDK for the data plane and onto Azure Resource Manager REST for the management plane. The typed crate versions below are the ones pinned in Cargo.lock.

The data-plane services come from the GA typed crates. The management plane has no GA typed Rust SDK crate; rather than shipping an untyped second SDK or a separate process, those ops issue ARM REST calls through the azure_core HTTP pipeline already linked for the typed clients — one auth path, one runtime, one HTTP stack.

~SURFACE

89 FFI exports, surfaced through the flat Azure namespace plus twelve typed sub-packages. The Azure namespace also carries the pure helpers and the version / ping convenience wrappers.

$WHY OPT-IN (NOT BUILTIN)

The Azure SDK for Rust crates pull in tokio, hyper, rustls, and reqwest, plus a chain of typespec / generated-model support code. The core stryke binary stays slim precisely because each connector ships separately. Daily-driver work — one-liners, awk replacement, data scripting — doesn't need an Azure SDK, a Cosmos driver, or a Key Vault client linked in.

&FFI PROTOCOL

JSON in, JSON out, over a C ABI. Each request is a JSON object of op-specific args. Each response is a JSON object; errors carry an error field with a verbatim message. The C string returned by every export is freed through the shared stryke_free_cstring symbol.

# every export resolves the shared credential, builds a per-call
# service client, and runs on the shared tokio runtime
azure__blob_get('{"container":"data","name":"hello.txt","account":"acme"}')
  -> {"container":"data","name":"hello.txt","body":"hi","content_length":2}

# handler errors are surfaced, never thrown across the ABI
azure__blob_get('{}')  ->  {"error":"missing container"}

/SCOPE

See the README's service map and usage sections for the authoritative scope. The package is intentionally narrower than the underlying SDK — the goal is "useful from a shell pipeline", not "complete API coverage". Cosmos queries are single-partition (an SDK constraint); live, credential-backed round-trips are exercised manually against a real subscription.

#PROJECT METADATA