Did you miss part one and part two of this multi-part series on ‘Cost Optimisation’?

I’ll focus on ‘Architectural Cost Optimisation’ in this final part of the series.

In prior articles, I have discussed foundational primitives, which are what you can change and tune in the cloud without changing your applications.

But you know what? Architectures should constantly evolve to deliver business efficiency improvements and cost savings.

If you are an architect or developer reading this, you are unbelievably lucky because you have new levers to pull every day.

In 2023, the two major Hyperscalers (Azure and AWS) released over 2,000 new feature updates and/or new services.

You can pull them up or down. It is all about choice. But isn’t it cool with intelligent decisions, you can pull different levers and get different outcomes?

You can implement code changes. That is often the best way to fix problems. I can recall countless times that I have spoken to a customer or an internal stakeholder about an application that runs terribly, and rather than fix it, we are using infrastructure as a band-aid.

In part 3 of this series, I will illustrate that perhaps, more than ever, you should just fix the application first, then climb the cloud maturity curve and reduce the cost to serve.

Today, with many options available to architects, there are way more decisions to be made than ever before. On the one hand, that’s challenging because you need to learn more, but the flip side is that it’s great because you’ve got more choices and you can make more finely honed decisions, which you can test in real-time to see if they make sense.

The public cloud has been a game changer. With resources now available on demand, you can experiment and optimise regularly, eliminating the long development and procurement cycles of the past.

I’ll share some tricks and tips you can use to reduce costs by improving your architecture.

Eliminate your web server tier and use static web-apps

Getting rid of your web servers. Has that thought ever crossed your mind?
Most organisations have web servers that they manage, but do you really need them? What are they doing? It’s time to modernise.

These days with modern web frameworks, you can eliminate your web-server tier. They are costly and increase your security surface attack area. With the era of compute at the edge (Azure Front Door / CloudFlare Workers / Akamai Edge Workers / CloudFront Functions), are your web servers providing value or are you spending most of your time patching, upgrading and looking after them?

A modern approach to take is static web-apps

It’s 2024. The world runs on Javascript (ECMA) based frameworks and this approach opens up a world of new opportunities.

You make API calls, invoke an SDK (Azure and AWS JavaScript), call API Gateways (Azure API-M and Amazon API Gateway) and more.

Static Web Apps support JavaScript and TypeScript front-end apps, including those developed with popular frameworks such as Vue.js, React, Angular, and more. Single Page Apps (SPA’s) are fast becoming the norm in cloud-based development.

You’re not patching servers, and there are no scaling rules to worry about. It just works. The next question is, what does that cost me to run? Here is an example using Microsoft Azure, with costs similar to Amazon Web Services and Google Cloud.

Comparing Azure Static Apps vs. Virtual Machines

As mentioned in part-one (Infrastructure Optimisation), the operational costs to administer often need to be calculated. With this approach, you’re not patching web servers anymore, not doing capacity planning and not having to worry so much about security scanning because the pipeline is cleaner and more straightforward.

Static WebApps, I challenge everyone here today to take a look and consider the possibilities if you genuinely need those Apache, NginX, or IIS machines around?

Database Economic Architectures

Not everything is SQL or NoSQL. You may have heard the proverb, “All roads lead to Rome”. In the application world “Rome” is often your relational database. Your goal as a modern cloud architect is to reduce CRUD calls to their minimum.

One approach is to use a noSQL database and caching to accelerate delivery and drive down costs.

If you look at any web-scale application, you will see caching everywhere. It is the new normal, and we need to take advantage of it. Do not confuse your transactional database with your analytical database. 

There is a reason why a reporting service exists and why a relational database engine exists. For the same reasons that you would often separate these workloads, there will often be hotspots in your databases. 

These hotspots are giveaways indicating where refactoring or employing a more suitable tool could provide a better outcome.

I am not saying relational databases perform poorly or that we should move everything to Cosmos DB, MongoDB, or DynamoDB because every solution has pros and cons.

Caching the right parts of your application in an in-memory cache or using noSQL can be a game changer.

As traffic and demands on your app increase, scale performance simply and cost-effectively. Add a quick caching layer such as Redis to the application architecture to handle thousands of simultaneous users with near-instant speed, all with the benefits of a fully managed service.

While this diagram is from Microsoft, I want to share some learnings from my time at seek.com.au. With around 20k concurrent users, storing session state in a relational database became costly, ensuring the relational database could support such high user concurrency with low latency.

The performance and cost benefits to the business were plain to see in moving to an in-memory cache. Developers are paying attention, and the recent (2023) Stack Overflow Developer Survey clearly shows the popularity of NoSQL and in-memory caches.

Image Source: https://survey.stackoverflow.co/2023/#section-most-popular-technologies-databases

The Cost Impact of Different Architecture Methods - Using An Example Application

Like all technology, architectures must evolve. Let’s talk in real terms and build an application to demonstrate the approach. This application will illustrate how you can deliver the same functionality and the same business outcome in multiple different ways, all with very different cost profiles. 

I am calling the application, ‘Toilet Finder’. I will use various types of compute but leave the MySQL database as a constant for comparison purposes.

In Australia, the Australian Government publishes a dataset of all the public toilets in Australia which includes various properties such as location, number of toilets and features such as baby change tables. 

This dataset is a CSV that contains 18,408 records (2024), and we are going to create a microservice that, when presented with a postcode (querystring) it will return a JSON payload of all of the public toilets for that postcode.

Before we look at our deployment topologies, let’s look at the Python code in which we will be executing. Below is a very simple snippet of code. It uses the built-in webserver in Python called Bottle. 

There is a route for /postcode and some basic validation to check if the postcode is four digits long.

Method 1: Typical VM Deployment

The picture below depicts deploying this solution using virtual machines (VM’s). As we want this to be reliable, we will need to use multiple VM’s in a VM Scale Set / Auto Scaling Group and even using modest B2Ms (2vCPU) burstable instances my monthly compute cost will be $154USD (May 2024 / Australia-East).

While this topology is scalable, reliable, and familiar, it is also storage and operationally heavy. The administrator will still need to patch and manage servers.

2x B2Ms (2vCPU) : Monthly Cost = $154USD – May 2024 | Australia East

Method 2: Container Deployment

The picture below depicts how you could deploy this solution using Containers. By evolving past our VMs, we are going to realise faster scale-ups and scale-downs. It is going to be more reliable, and it's a container. By using Azure Container Instances, I will pay based on my consumption only. 

I no longer need to maintain and manage VMs but instead use a docker file that states how to build my containers. I am hosting this in Azure Container Registry, which is executed by Azure Container Instances.

1GB Memory + 1 x vCPU X 4 Hour Run Time Duration : Monthly Cost = $0.22USD –  May 2024 | Australia East

Method 3: Functions and Event Driven Architecture

The picture below depicts how you could deploy this solution using Azure Functions, and it is similar if you are using AWS Lambda. Like our container offering, it is lightweight, requires no server patching, and, given our modest load, fits within the free tier.

It is worth noting there will be a first hit / cold start penalty, which you can see in the demo below. However, this isn’t an issue for workloads with consistent traffic profiles.

200 000 Executions, 100ms execution time : Monthly Cost = $0USD  – The first 400,000 GB/s of execution and 1,000,000 executions are free - May 2024

Video Demonstration

In the video below, you will see a demonstration of all three methods of delivering the same business outcome at three very different cost profiles. This is a fun example; however, imagine the cost optimisation benefits if it is scaled for an enterprise.

VMs, Containers, and Functions all provide you, as builders, with methods to create the same outcomes, but I want you to think about the economy of your architecture.

Is this top of your mind?

Summary – Economy, The Next Dimension Of Cloud Architecture

As I close out this multi-part series, I want you to get into the habit of regularly reviewing your architecture and demanding the same or better outcome at a lower cost.

Architectures should evolve during a system’s lifetime and radical changes are possible, driven by economics (transition cost + operational cost).

Public cloud brings a magnitude of opportunities to builders and architects. There are a raft of new levers that you can pull and twist to architect for the new world and reduce costs.

Climb the cloud maturity curve and achieve the same or better outcome at a lower cost.

Architectures can evolve, but they need to make sense, and with new tools and levers being released daily, the cost of change is only reducing.