A Well-Architected Cloud Application

If "World Peace" is a beauty pageant contestant's most cliched answer, then "Well-Architected" is that of a cloud developer describing their app.

An app to deliver business value at quality relies on code and infrastructure. Most cloud service providers, by now, have gathered a wealth of experience & expertise on how best to develop different types of applications on their infrastructure and have provided guidance accordingly. Azure et al. have termed apps following such guidance are termed as "well-architected" and have been successful in providing a consistent experience for developers.

The Smaller Picture

Right from our first blog post, we have been progressively narrowing our focus. Back then, our proposed Architecture for the entire solution looked somewhat like 👇

Honey, Azure SWA shrunk the Architecture Diagram

In tech, of late, procrastination isn't that bad a thing - by me.

While we were muddling through our design, the good folks at Microsoft had raced ahead to release Azure Static Web Apps. Incorporating Azure SWA would consolidate our frontend and API, reducing management overhead, and in the process, also save us a pretty penny. To celebrate the occasion, Azure held a virtual event, Code to Scale[Some of the videos were great for diving into SWA]. And it was accompanied by a learning challenge, which I felt didn't quite build upon the sessions. For example, there were three mandatory modules on JS, Blazor, & Gatsby; a newbie would only be interested in only one[a choice would have been better]. Also missing were modules on local development with Azure SWA CLI and E2E testing with Playwright. I have created a MS Docs Learning Path for Azure SWA, which I will be updating in the coming weeks as I find more modules that are useful for Blazor WASM based Azure SWA.

For the 1st iteration "MVP", our erstwhile Architecture diagram has slimmed down considerably.

• Our frontend and API have fused into a single Azure-managed service. [Yo, imma also gonna be drinking some of that minimal API Kool-Aid.]

• We are taking a bet on .Net 6 vision. Because our deployment targets, in the coming iterations, will be devices like Laptops/Tabs[WinUI] and mobiles[MAUI]. We are doubling down on Blazor so that we can reuse a substantial part of our codebase as-is across these platforms. Cons: In the diagram, we indicate there is still NO native Application Insight integration for Blazor WASM, looks like Azure is still sitting on the fence for this one. A web app team is flying blind without user action and transaction telemetry.

• Also introducing Azure Event Grid, which will be the fulcrum of our event-based architecture.

• Azure Cosmos DB, as our data store, is a natural counterfoil for Azure SWA: faster app development, global scale, and is fully managed.

• The recently released SWA CLI should bolster our local coding experience, and we will attempt the entire development on WSL2 🤞.

Pillars of a Well-Architected Cloud Application

Both AWS and Azure agree that there are 5 "pillars" of a well-architected cloud application, while Google demurs that they are only 4 "principles". It brought back memories of the hilarious scene from History of the World where God gave Moses "actually" 15 commandments.😁

1. Cost Optimization
2. Operational Excellence
3. Performance Efficiency
4. Reliability
5. Security, Privacy, and Compliance [Psst: Azure and AWS just went with security, but I did not want Google to feel left out, so I have used their nomenclature 😉]

From a project management perspective, these pillars render themselves quite naturally as epics. And that's how we roll with them on our Azure Boards.

Cost Optimization

Google has four principles because it clubs Performance with Cost Estimation. While most of us dream of driving a Ferrari, but as an Indian, this car ad gets us, right to the last paise 😊 => my priority will be to keep a close watch on our cloud costs. Also, it provides Early Warning Signals [to borrow a financial term] for most Architectural issues.

Pricing Calculator

Before we write a single line of code and deploy artifacts, we must know how much this will cost us. Azure provides a handy tool to do just that: Azure pricing calculator

For cloud practitioners, architecture diagrams doubles up as a handy shopping list. - once again, by me.

Let's ring up our resources on the calculator [click here for the estimate]:

• Initially, we will be developing with the free version of the Azure SWA, but I'm opting for the run-rate of the Standard version because we will be using Custom Authentication [Auth0].

• Going with the serverless pricing of Cosmos DB and a modest 1 GB storage.

• Event Grid is free for the first 100,000 operations. I'm always amazed at these prices; 10 years ago, we would have been shelling a few lakhs for a fraction of such a service.

• With Key Vault, we come to the first service not offered in any of the Azure regions in India, as per the Pricing Calculator. But it's available in the Central India region [bug ???]
  

• For Azure Monitor, I have been liberal with the number of logs and metrics that are being captured because during the early days, you are trying to get familiar with your application. And this ties in with other pillars, which we will touch upon in forthcoming posts.
  

• We have attached the excel sheet estimate with the Pricing Calculator user story and checked it in our git repository.

The grand total comes to a very affordable ₹1,687.66 per month with no upfront payment.

Azure Cost Management [ACM]

With ACM, we can get a quick look at our costs with a detailed breakup. And more importantly, create a trackable budget via billing data/reports, and set up cost alerts.

For the MVP iteration, we have allocated a budget of ₹2000, a buffer of ~18% over our Pricing Calculator estimate. We have set a threshold alert for 75% of the actual cost and 110% of the forecasted budget.

At the day's end, our items on our Azure Boards are "shifting right" -> unlike in DevOps, good news in Project Management.

In our upcoming blog posts, we will start incorporating best practices from other pillars into our solution. Up next, though, I will be leaving my comfort zone to plunge into UI/UX wireframing and prototyping. Stay safe 💪.