// Content

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.

In my spare time, I work on a pet project called Theatreers. The aim of this is a microservice based platform focused on Theatre / Musical Theatre (bringing a few of my passion areas together). I've recently re-architected the project to align to a multi-region serverless technology stack.

Consider this scenario. You are managing a software project using Azure DevOps, and you have multiple teams working towards a common cadence. Perhaps that cadence is managed by a central team. To gain the most value from your sprint planning, you would need to associate the iterations from the project level with each individual team. This is a scenario that I have for my fictitious Theatreers project, but also a scenario I encountered recently with a colleague. I have been helping them setup an Azure DevOps project to track the development of IP and collateral, so that they can more accurately forecast what they expect to land and show the value being delivered by the team.

Cloud Governance seems to have come up a few times over the past few weeks, so I wanted to post a short, sharp blog about it!

Scalability is one of the common areas where I have seen common misconceptions, when customers begin building on the platform.

In case you had not already heard, Logic Apps have now reached general availability on Azure (or read an MSDN article by Jeff Hollan on the topic).