Azure Well Architected Framework at a glance

The Azure Well Architected Framework focuses on a pattern of thinking about workloads in the cloud in order to make them run as best as possible, taking full advantage of what cloud scaling and capacity brings whilst achieving business tasks as efficiently as possible. The important thing to remember here is that the framework looks at what levers or pillars of optimisation are best to apply or exercise on specifically the workloads running in our cloud, where a workload is a collection of cloud applications, data and compute infrastructure that together attempt to achieve a business goal. These pillars are categorised as Cost Optimisation, Operational Excellence, Performance Efficiency, Reliability and Security.

Specifically:

• Operational Excellence - are our human driven and human first processes leaning into what we wish to achieve for our software service. Are we aligned on using CI/CD, Devops, tagging resources, organising and naming our resources in a way that makes sense to our business and application.
• Reliability - is the entire system in question fault tolerant, able to gracefully fail and able to report issues accordingly upon failures and data source absences. Can the system self-heal and self-recover as reliable cloud systems should do
• Performance Efficiency - is our service able to adjust to the different kinds of demands from users and other related loads onto it as a whole and able to scale to production quickly where needed
• Cost Optimisation - can we get the best compute resource to support our goals at the best possible pricing without unnecessary expenses appearing from larger scaling.
• Security - is our infrastructure in our architecture adhering to best security practices. Is our data encrypted in transit, in use and at rest

How to look at an Azure Workload

An Architecture of an example workload on Azure might be the following:

Here, this would be an example of a workload to achieve the goal of building a multiple-agent workflow automation solution by using Microsoft Agent Framework. That's the workload - and so with that we can customise the resources to our best ability but at the core, we will want to make sure that in achieving that goal, we choose services and infrastructure that meet the five pillars of a Well Architected system on Azure.

This workload according to Microsoft aims to allow employees to access a web front end to manage automated solutions that are supposed to carry out tasks through the use of AI Agents that are in turn orchestrated by a central 'Container Apps API" in the form of a Container Apps Instance. In the workflow, the users require a web front end to access the management panel to make requests and set parameters. The requests are routed to Knowledge sources and other tools to achieve the desired outcomes of the front end.

From just the outlined workflow, we can identify and piece together a Well Architected set of services that fulfil or hit the goals in the best form to achieve a front end, data persistence, container image management and persistence, HTTP request processing , AI service management. For example:

🌐Azure App Service -> secure and reliable for running web app front ends (Security and Reliability)

📦Azure Container Apps -> cheap and cost effective (Cost Optimisation and Performance Efficiency)

🛠Azure Foundry - centralised repository for AI capabilities (Operational Excellence )

🤖Azure Foundry Agent Service - integrates well and securely with best practice agentic behaviour (Operational Excellence and Security)

🦺Azure Container Registry - available and highly reliable SLA from Microsoft (Reliability)

By choosing services, it has been determined here that these services are a well-informed choice to act on the five pillars that we discussed and drive our architecture to be Well Architected. And as with the Well Architected Framework, there are tradeoffs to be thought about when make one choice over the other, for example there is no reason why we couldn't remove Azure Container Apps for API Requests too and use App Service for this job - at points it becomes about making sure our choices fit best with the rest of the other services more than the other choice.