CloudChat

Conversations about building software and designing architecture in the cloud natively.

Ep. 33 - Route of All Evil 06/08/2026

Ep. 32 - Rolling, Rolling, Rolling… 05/11/2026

Ep. 32 - Rolling, Rolling, Rolling… Logs are ground truth — high-fidelity, event-level data that anchor observability alongside metrics and traces. Carl and Brandon argue the biggest mistake teams make is treating “more logs” as “better logs.” If everything is logged, nothing is useful, and they both share recent troubleshooting sessions where verbose, unstructured output forced them into KQL gymnastics just to find the actual error. Brandon walks through a 503 that turned out to be a database fault hidden one layer down, and Carl recounts a customer whose “unplanned” VM reboots were actually planned Kubernetes node maintenance — a story you can only untangle by correlating infrastructure and platform logs. Along the way they cover the six log sources worth thinking about (application, infrastructure, platform/managed service, security, audit, and access logs), with a detour into a customer whose minute-long latency vanished once infra logs revealed a VPN routing New York users through Texas. The middle of the episode is a clinic on log hygiene. Carl walks through log levels — debug/verbose, info, warn, error, fatal — and the distinction Brandon draws between an exception (a code construct) and an error (a log level): a caught exception is an error, an uncaught one becomes fatal. They make the case for structured logging into stores like Kusto or via OpenTelemetry so keys can be projected, indexed, and fed directly into dashboards, and Brandon’s tip on not pre-computing expensive log arguments is a reminder that a disabled verbose call still costs CPU if you build its message eagerly. Centralized logging pipelines beat rolling your own helper class — log4-anything frameworks exist for a reason — and UTC alone won’t save you when scaled-out instances drift apart in time. Correlation and trace IDs, especially parent/child IDs from OpenTelemetry, are the thread that stitches a single user’s journey back together across microservices. Carl and Brandon close on cost and discipline. Logging budgets balloon fast, so production should not be running verbose, retention should be tiered (a month of exceptions is plenty once the fix ships), duplicate destinations like Log Analytics plus Event Hubs plus a storage account should pick one source of truth, and Application Insights-style sampling can collapse repetitive traffic into representative events. Compliance logs that sit for years belong in cold or frozen storage tiers where the access pattern actually matches the cost. Their do’s and don’ts land on a simple posture: log with intent, redact secrets and connection strings, standardize across teams, and — especially if AI agents are writing your code — make sure the logging conventions travel with the work. Point an agent at a recent run and ask where the gaps and noise are; it’s a fast way to audit whether your logs are actually doing their job. Links Observability and logging concepts Logging frameworks Azure platform logging Security and supply chain Visit us at: /episode/index/show/dfd84fca-7055-4605-98ce-3b0f8cbd6e15/id/41286580

Ep. 31 - AI All the Things? 04/06/2026

Ep. 31 - AI All the Things? Traditional sprint ceremonies start getting in the way when AI-assisted development outpaces the cadence they were built for. Carl and Brandon unpack why that happens and what to do about it — starting with the basics. Brandon defines context windows, distinguishes original vibe coding from the sloppy way the term is used today, and walks through the software factory model where requirements, source code, and tests live in separate repos. Carl shares how he continuously refines his Copilot instructions file, instructs the agent to detect and document recurring patterns, and leans on intent-based prompting over tactical step-by-step descriptions — a three-sentence prompt describing preset themes and macOS Focus Mode integration wrote his Swift UI code nearly flawlessly. Both hosts dig into context management: plan mode to review before implementing, the “Ralph Wiggum” pattern of starting fresh sessions with just the plan, and Architectural Decision Records that give future sessions a trail to follow. Different models suit different jobs — Claude for architecture, Codex for implementation — and MCP servers let those models reach Git and GitHub without a copy-paste workflow. Brandon argues AI is a tool like the Internet — some roles will shift, but learning and adapting has always been the core tech-industry skill. Carl backs that up with a study showing senior engineers only see productivity gains when they change their process, not when they bolt AI onto the old one. On the junior side, Carl mentors a developer to focus on data structures and algorithms — not for the implementation details, but for knowing when to apply them. An MIT study pegs realistic job displacement at around 11.7 percent, and cases like Box’s layoffs look more like post-COVID overcorrection than proof that AI is replacing everyone. Links AI-Assisted Development Development Concepts Tools Mentioned Visit us at: /episode/index/show/dfd84fca-7055-4605-98ce-3b0f8cbd6e15/id/40741635

Ep. 30 - Local‑First Lifeboats: Architecting for Post‑EOL Usability 02/02/2026

Ep. 30 - Local‑First Lifeboats: Architecting for Post‑EOL Usability This episode is about designing for the last day, not just the launch day. Carl kicks off with the Bose SoundTouch situation: a vendor moves toward EOL on a cloud-tethered API, users push back, and the outcome (at least in spirit) becomes a blueprint we wish was more common: keep the hardware useful by enabling local control paths and leaning on protocols that already work without your cloud. From there we broaden the conversation to the bigger problem: products and services that do something totally reasonable in a LAN suddenly need a round trip to the internet just to respond to a button press. Carl and Brandon talk through concrete “this actually happened” examples and what good looks like. Belkin’s Wemo sunset email is a solid reference: clear dates, repeated notices, and a reality check that local APIs and ecosystems like HomeKit and Matter can keep devices working even when a vendor endpoint is shut off. We contrast that with the messier side of the industry: thermostats and other home gear that still function locally, but lose their main value when the cloud connection is removed, and cloud-only platforms like Stadia where “no backend” means “hard stop” (with the one bright spot being things like refunds and a final firmware update to unlock a controller for normal Bluetooth use). On the builder side, we get practical about how to retire things without surprising your users. We cover technical signaling (Deprecation and Sunset headers), the need for human-friendly comms beyond “put it in the docs,” and the architecture patterns that make “minimum viable offline” real: local-first state, local discovery and control surfaces, and fallbacks that do not require re-pairing or re-auth when identity systems go away. We also touch on SaaS escrow and continuity as a way to build trust (especially for startups) and close with a simple gut check: if your cloud disappeared tonight, what can your users still do tomorrow morning? Links News and examples we discussed API deprecation and shutdown mechanics Smart-home protocols and “local-first” connectivity Tools and patterns Contracts and continuity Other links of interest Visit us at: /episode/index/show/dfd84fca-7055-4605-98ce-3b0f8cbd6e15/id/39959455