Azure Myth 4: Azure is Magical! Management in the cloud compared with on-premises - Azure MythBuster
Azure automates many underlying infrastructure concerns, but it does not make management decisions for you — you still define scalability boundaries, resilience configurations, and the correct IaaS/PaaS/SaaS model for each workload.
Scalability comes in two forms: scale-out (adding more instances, ideal for stateless workloads) and scale-up (increasing a VM’s CPU/RAM, suitable for applications that cannot run across multiple instances). Virtual Machines require you to provision and remove instances manually or via scripting; Virtual Machine Scale Sets expose a slider-style auto-scale rule so the platform handles the fleet. Azure Functions on a consumption plan abstracts all of that away, but you still choose between consumption and App Service plans based on workload characteristics.
Resilience requires explicit opt-in at two levels: availability sets distribute VMs across fault domains (power/networking racks) and update domains within a data centre, while availability zones spread VMs across physically separate data centres within a region. Neither is applied automatically — you must deploy VMs into the set or zone. For PaaS services such as Azure Functions, cross-region resilience requires deploying Function Apps in multiple regions and routing traffic between them with Azure Traffic Manager, which does not happen by default. These decisions directly affect cost, so requirements — especially RTO, RPO, and SLA targets — must be defined before selecting a resilience approach.
Related Content
Azure Myth 3: You don’t need requirements in the Cloud… Or do you? - Azure MythBusters
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.
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.