标签：#devops

I've been running AI workloads on Azure Container Apps for over a year. Every time I spin up a new agent backend, the ritual is the same: create an environment, configure networking, set scaling rules, wire up health probes, then deploy the actual container. For a prototype agent that might live for a week, that's too much ceremony for what you get. ACA Express, which hit public preview in May 2026, kills most of that ceremony. And a separate but related announcement, Docker Compose for Agents, brings MCP gateways and model serving to standard ACA environments. They solve different problems and run on different infrastructure, but together they cover the full spectrum of agent deployment on Azure. Let me break down both. ACA Express: What It Actually Is Express is a new environment tier within Azure Container Apps. You bring a container image. Express handles provisioning, HTTPS, scaling (including scale-from-zero with subsecond cold starts), and resource allocation. No environment to manually provision through the portal. No networking to configure. No scaling rules to write. Under the hood, Express is built on ACA Sandboxes, a platform primitive that uses prewarmed pools to deliver that subsecond startup. This isn't the standard ACA cold-start experience with a fresh coat of paint. It's a different architecture. The tradeoffs are real. Express is HTTP workloads only, consumption CPU only. No GPU. No VNet integration. No Dapr. No service discovery between apps. No managed identity at runtime. No health probes. If you need any of those, standard ACA environments are still there. But for stateless HTTP agent backends, Express is dramatically faster to deploy and cheaper to run. Here's what it takes to get a container running: # Create an express environment az containerapp env create \ --name my-express-env \ --resource-group rg-my-agents \ --environment-mode express \ --logs-destination none # Deploy your app az containerapp create \ --name my-agent-api \ --resource

If you've trained a transformer in the last three years, your GPU spent most of its wall-clock time inside a matrix multiplication. The kernels doing that work were probably written by cuBLAS, generated by a compiler stack like Triton, or hand-assembled on top of NVIDIA's CUTLASS templates. CUTLASS is the one most people don't see directly, but it sits underneath a surprising amount of modern AI infrastructure — from FlashAttention to vLLM to several internal kernels inside PyTorch. What CUTLASS actually is CUTLASS — CUDA Templates for Linear Algebra Subroutines — is a header-only C++ template library NVIDIA publishes on GitHub under Apache 2.0. It is not a drop-in replacement for cuBLAS. cuBLAS gives you a closed-source binary with a stable API: you call cublasGemmEx and you get a tuned kernel. CUTLASS gives you the building blocks to write your own kernel, with control over tile sizes, data layouts, epilogues, and how the kernel decomposes work across the GPU's memory hierarchy. That control is the point. If you're building a custom inference engine and your projection layer needs to fuse a GEMM with a SiLU activation and a residual add, cuBLAS can't fuse the epilogue for you — you'd launch the GEMM, then a separate elementwise kernel, paying twice for global memory traffic. With CUTLASS, the epilogue is a template parameter. You write the fusion once, instantiate the template, and the compiler emits a single kernel. This is why CUTLASS shows up wherever standard cuBLAS shapes don't fit — unusual data types like FP8, custom epilogues, sparse or grouped GEMMs, attention-shaped matrix products. Anywhere the stock library doesn't have what someone needs and the performance ceiling matters, you tend to find a CUTLASS kernel. CUTLASS is not a productivity library. It is a kernel-author's library. If you're writing PyTorch model code, you'll never import cutlass directly — you'll consume kernels that were built on top of it. The audience here is people who write the ker

Why We Built JaisCloud — A Free, Single-Binary AWS Emulator in Go If you've ever tried to test AWS-dependent code locally, you've probably reached for LocalStack. It works — but it comes with baggage: Python runtime, Docker dependency, and the features most teams actually need locked behind a Pro subscription. JaisCloud is our answer to that problem. What is JaisCloud? JaisCloud is a free, open-source local AWS cloud emulator written entirely in Go. It implements the exact AWS wire protocols — Query/XML, JSON/Target, REST — so your existing SDK code points at JaisCloud and works unmodified. No shims, no proxy rewrites, no SDK patches. # Start it jaiscloud-aws start # Point your SDK at it export AWS_ENDPOINT_URL = http://localhost:4566 export AWS_ACCESS_KEY_ID = test export AWS_SECRET_ACCESS_KEY = test export AWS_REGION = us-east-1 # Your existing code works — no changes needed aws s3 mb s3://my-bucket aws sqs create-queue --queue-name my-queue The Problem With Existing Solutions JaisCloud LocalStack Community Moto Single static binary Yes No - Python + Docker No - Python library Zero runtime deps Yes No No Postgres persistence Yes Pro only No Real Spark/EMR execution Yes No No Apache Iceberg Yes No No Prometheus metrics Yes Pro only No State export / import Yes No No Deterministic time control Yes No No Written in Go Yes No No License Apache-2.0 Apache-2.0 Apache-2.0 Key Features Single Static Binary JaisCloud ships as a single Go binary per cloud. No Python, no Docker, no Node — just download and run. Works on laptop, CI runner, or Kubernetes pod. # Download and run — that is it ./jaiscloud-aws start # Or with Docker docker run --rm -p 4566:4566 rjaisval/jaiscloud-aws:latest Portable State Snapshots Export the complete emulator state — every resource, every account, every region to a single gzip tarball and restore it anywhere in milliseconds. # Capture a baseline jaiscloud-aws export -o baseline.tar.gz # Restore on a teammate's machine or CI runner jaiscloud-aws i

Platform Engineering Labs has announced a major update to its open-source Infrastructure-as-Code platform, formae, introducing full Kubernetes support, native Helm integration, direct .tfvars compatibility, and a new public plugin hub aimed at simplifying cloud-native infrastructure management By Craig Risi