Azure Myth 3: You don’t need requirements in the Cloud… Or do you? - Azure MythBusters

Azure Myth 3: You don’t need requirements in the Cloud… Or do you? - Azure MythBusters

2019-08-20

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)

2019-07-13 · 4 min

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?

2016-09-29 · 4 min

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

2016-08-26 · 5 min

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.