Azure architecture looks easy when everything works.The real test starts when dependencies fail, regions become unavailable, traffic spikes, assumptions turn out to be wrong, requirements change, and someone eventually asks the uncomfortable question: why did we design it this way in the first place?In this episode of M365.FM, Mirko Peters talks with Mike Martin [MVP] about what Azure architecture looks like when it has to survive real production conditions rather than just look good on a diagram.Mike brings decades of experience across development, infrastructure, architecture, leadership, coaching, training, and Microsoft Azure. One of his strongest observations is that many of the problems architects face today are not actually new. DNS still breaks. IP dependencies still matter. Costs still become a problem. Integrations still fail. Dependencies still disappear at the worst possible moment.What has changed is the level of complexity we build around those problems.
FROM VISUAL BASIC TO MODERN AZURE ARCHITECTURE
Mike looks back at nearly three decades in IT, starting as a Visual Basic developer in the 1990s and moving through distributed systems, networking, enterprise software, infrastructure, and eventually Azure.His key observation is simple: the industry keeps solving many of the same fundamental problems, but the architectures around them have become much more complex.Modern systems have moved from client-server applications to distributed architectures, cloud platforms, containers, microservices, Kubernetes, hybrid environments, and now AI-assisted development.That creates enormous possibilities, but it also creates a new risk: overengineering.Mike argues that many teams today make simple problems unnecessarily complicated. Good architecture is often not about adding more technology. It is about knowing what not to add.
WHAT DOES AN AZURE ARCHITECT ACTUALLY DO?
For Mike, architecture is not about choosing the largest number of Azure services or producing an impressive diagram.It is about understanding which components belong together, which ones should be avoided, which ones are necessary, and how to build something that remains maintainable, scalable, secure, and resilient.Architecture includes much more than compute.
• Identity
• Networking
• Data flows
• Security
• Monitoring
• Integration
• Dependencies
• Scalability
• Operations
• Recovery
• Deployment
• CostMike also challenges the idea that cloud-native automatically means Kubernetes or containers.Azure provides many managed and native services that can solve problems without introducing unnecessary operational overhead.The architect’s role is to understand the complete solution and choose the simplest architecture that still satisfies the real requirements.
START WITH BUSINESS REQUIREMENTS, NOT AZURE SERVICES
One of the most important lessons in this episode is simple: do not start with technology.Before deciding between Azure Kubernetes Service, App Service, Azure Functions, containers, Service Bus, or another platform, teams should first understand what the solution actually needs to do.Questions to ask:
• Is it internal or customer-facing?
• How many users will depend on it?
• Does it need to scale globally?
• How long can it be unavailable?
• How much data can the business afford to lose?
• Which compliance requirements apply?
• What happens if the application disappears for several hours?
• Who is affected?
• What level of operational support is required?These questions lead directly into concepts such as SLAs, SLOs, RTOs, and RPOs.They also determine whether the architecture should be single-region, multi-region, active-active, active-passive, or something much simpler.
RTO AND RPO WITHOUT THE BUZZWORDS
RTO and RPO are often discussed as technical acronyms, but their real meaning is business-oriented.
• RTO — Recovery Time Objective: How quickly must the system return after a failure?
• RPO — Recovery Point Objective: How much data loss is acceptable?A system used for non-critical monitoring may tolerate several hours of downtime or lost data.A system supporting first responders, financial operations, commerce, or critical infrastructure may require recovery in minutes.The important point is that these numbers should not be invented by the architect.They should come from the actual business impact of failure.Once those requirements are understood, they can be translated into technical design decisions.
RESILIENCE IS NOT THE SAME AS HIGH AVAILABILITYMike uses a simple analogy to explain the difference between availability and resilience.A highly available system may have another component ready to take over when the primary one fails.A resilient system is designed to absorb problems, continue functioning, recover gracefully, and return to normal without collapsing completely.That distinction matters.An application can technically be available while still pro...
