// Content

Moving to the cloud shifts infrastructure spend from capital expenditure (CapEx) to operational expenditure (OpEx)—but only if you think about cost correctly from the start. This episode covers the cloud cost mindset: right-sizing, auto-scaling (scale out vs scale up), compute resource consolidation, governance through resource tagging and policy, pricing calculators, reserved instances, and how to build cost awareness into your architecture from day one.

Every cloud project starts with requirements. In this episode, Chris explores the critical pillars of cloud architecture: resilience (SLA, RTO, RPO, MTTR, MTBF), scalability, performance, and cost. Learn why defining requirements upfront—before drawing architecture diagrams—is essential, and how the same on-premises thinking about availability translates directly into the cloud.

This is the first recording, a brief teaser ahead of launching cloud with Chris. Stay tuned, and follow for more info!

A lot of people will take a round peg and try and push it into a square hole – or in this case, take their code and try and cram it into whatever service they happen to like at the time. There are specialised services on Azure, as well as some generic ones, but we’re going to talk about some of the more specialised compute services and what things you need to consider when using them.

Choosing the wrong Azure compute service leads to mismatched scaling behaviour, cost overruns, and avoidable management overhead. This Azure Mythbusters episode compares App Service, App Service Environment, Container Instances, AKS, Service Fabric, Azure Batch, Azure Functions, Logic Apps, Virtual Machines, and VM Scale Sets — highlighting decision factors such as stateful versus stateless workloads, latency requirements, compliance needs, and auto-scale granularity.

There are a lot of established cloud design patterns. These don’t all apply specifically to Azure, either – some of them apply intrinsically to cloud services, and some to general services and architectures. If you’ve been to the Azure Architecture Center before, and you’ve seen what used to be the patterns and practices guidance, I’d advise you to take another look. We’re adding new ones all the time as we see them, all of which are common patterns that Azure customers are using to isolate and work around things they see in applications to make them work better.

Cloud design patterns are abundant and well-documented on the Azure Architecture Center — from established patterns like cache-aside and materialized view to cloud-native ones like circuit breaker and health endpoint monitoring. This Azure Mythbusters episode tours the full pattern catalogue and deep-dives four key patterns: cache-aside, circuit breaker (open/half-open/closed states), health endpoint monitoring, and materialized view in CQRS/event sourcing scenarios.

Cloud is not inherently more expensive than on-premises once you account for hardware depreciation, power, cooling, and network costs — but it requires designing cost into your architecture from the start. This Azure Mythbusters episode examines fixed versus variable cost envelopes, auto-scaling strategies for spiky workloads like Black Friday traffic, the IaaS/PaaS/serverless cost spectrum, and cost as an implicit sixth pillar alongside the five pillars of software quality.

Moving workloads to Azure does not eliminate management decisions — scalability, resilience, and high availability all require deliberate configuration. This Azure Mythbusters episode contrasts scale-out via VM Scale Sets and auto-scale rules with scale-up by increasing VM SKU size, explains availability sets and availability zones, and shows how PaaS services like Azure Functions still require you to choose the right plan and design cross-region resilience with Traffic Manager.

Requirements remain essential when migrating to or building on Azure — from availability SLAs and RPO/RTO targets to compliance, data sovereignty, and cost. This Azure Mythbusters episode uses composite SLA calculations and Azure Architecture Center reference architectures to show how under- or over-specifying requirements directly shapes your design, region strategy, and overall cost.