Architecture and Cost: Running the Numbers

It has become a truism (because it’s true) that cloud costs directly flow from architectural decisions. If, for example, you choose to build an N-tier application on Azure using virtual machines, and a database hosted on a VM, your runtime costs will be different (i.e., higher) than if you use cloud native tooling such as Azure functions and a platform (PaaS) database.

As a design principle, choosing platform services over VMs is a good starting doctrine but it’s still important to estimate your potential costs and, within your design, select the correct tiers and savings plans to fit the requirement while optimizing usage from a cost efficiency point of view (part of a FinOps practice).

Consider this design, taken from Microsoft’s cloud native guidance documentation:

Azure App Modernization Proposed Architecture

This design is offered as an example of a cloud-native architecture which, using containers deployed within Azure Kubernetes Service, can be utilized to port applications to the cloud without resorting to virtual machines.

The key elements of this architecture are:

I won’t discuss Power BI (proposed for the visualization layer) or Azure Synapse Link because Power BI isn’t a core element of the design and Synapse Link is a service aspect of Synapse.

This design looks solid enough and certainly reflects modern, cloud-first principles; but, what is the estimated cost?

To answer this question, let’s turn to the Azure Pricing Calculator, which gives us the ability to plug design elements into a cost estimate engine (with data, presumably, from the price sheet API which provides retail pricing data) . Each service’s runtime cost is for the US-East region with a 1 year reservation. I chose fairly simple configurations to create a baseline. The screenshots are from the Pricing Calculator.

A Walkthrough of the Architecture, Using the Azure Pricing Calculator

Content Delivery Configuration

Here’s the Content Delivery instance (note the option to choose region served or ‘static zone’ and data transfer rate, among other things):

The next architectural element to consider is Azure Kubernetes Service; pricing is determined by the selected node type (Windows or Linux), the instance tier and number of deployed instances:

Azure Kubernetes Service Pricing Options

Application Insights, part of Azure Monitoring, is priced by the data ingested as part of the logging process:

Application Insights Pricing Options

Azure Functions, a serverless development platform, is priced according to the selected tier, instance type and number of instances used for the computational backend:

Azure Functions Pricing

Notification Hubs pricing is based on the number of pushes (for example, updates from the app to users on mobile devices):

Notification Hubs Pricing

Here’s the pricing element for the solution’s database elements, Azure Database for PostgreSQL, Redis Cache and Cosmos DB:

Azure Database for PostgreSQL
Azure Cache for Redis
Azure Cosmos DB

Completing the design components is Azure Synapse Analytics, a suite of services, which are combined to form a unified platform offering including data warehousing, ETL, machine learning and analytics elements. Synapse is sufficiently complex from a cost management perspective that I wrote an entire article about it.

Getting back to our design, here are the Synapse elements as configured in the pricing calculator:

Azure Synapse Analytics Elements

Looking at the Totals

Now that we’ve walked through the design using the Pricing Calculator, let’s take a look at the totals, which were downloaded as an Excel spreadsheet:

The design, presented as an estimated cost total

The estimated total is 6,407.27 USD which isn’t cheap but, depending on factors such as unit economics (i.e., the relation of the solution’s runtime cost to other cost considerations such as budget and revenue targets) may be acceptable or, even a bargain.

For cloud architects, it’s important to incorporate cost efficiency considerations into design decisions. This doesn’t mean always choosing the less expensive option but expanding the factors under review to include cost relative to business objectives. With cloud solutions, the temptation is to over-provision (even when configuring for elasticity) but as night follows day, that leads to excessive bills which are becoming harder to justify and are impossible to obscure (thanks billing API).

On Azure, using the Pricing Calculator to estimate a design’s runtime cost and select service elements – such as whether to use Azure Synapse and if so, what components and at what tier – is a powerful tool.

%d bloggers like this: