
Azure Myth 3: You don’t need requirements in the Cloud… Or do you? - Azure MythBusters
Requirements are not optional in the cloud — they are the primary driver of every architectural decision. The FastTrack for Azure team frames requirements gathering using an Aim-Plan-Do approach: first understand the scenario (e-commerce, healthcare, etc.) to surface compliance obligations, data sovereignty rules, and contractual SLAs; then let those requirements determine which Azure services and configurations are appropriate.
The episode demonstrates composite SLA calculation for a multi-tier web application (SQL Database + Queue + Web App), showing how multiplying individual service SLAs reveals whether a single-region deployment meets the target. Reference architectures from the Azure Architecture Center illustrate the progression: a basic single-region web app satisfies moderate availability; adding CDN, DNS, and additional tiers addresses scalability and higher availability requirements. Over-fitting requirements results in unnecessarily complex, expensive designs, while under-fitting leaves the solution unfit for purpose.
Related Content
Deploying a multi-region Serverless API Layer (Part 1)
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.
Are you thinking of scalability in your cloud application?
Scalability is one of the common areas where I have seen common misconceptions, when customers begin building on the platform.
Approaching Resilience in Azure Solutions
I mentioned in Building Solutions in the Cloud that I would be writing a series of blog posts on the areas of risk that I have seen since I have been providing guidance around Azure. In this post, I will provide some thoughts on how you can consider resilience within the context of your own solution or application.