Recently we’ve embarked on some work to tag and categorize our resource groups in Azure at work. One of the benefits of this was exposing which applications are burning through cash at an incredible rate and which are very cheap. Whilst I knew that serverless apps are likely to be significantly cheaper than non-serverless apps, particularly ones that aren’t under heavy load, I admit I was surprised by just how much cheaper one of our apps was.

This app (I discussed it in a talk here: https://www.youtube.com/watch?v=bynECqz5_vs) has 4 environments, sends thousands of messages a day and executes quite complex filtering logic on top of having a full user-friendly frontend. It costs £65 a year to host. It never requires maintenance beyond code changes. For comparison, 4 environments of an S1 Azure App Service and S0 Azure SQL Database would cost £3139 a year to host, which also require little maintenance except for monitoring for utilization (i.e. is the app running at 90% constantly and dropping requests).

So how did this app achieve such bargain basement prices? It is entirely down to architectural choices, and the fact that the average utilization of a serverfull app is very low, particularly if it is an internal business application (e.g. not customer facing).

The first architectural decision we made which saved big money was to host the entire front end as a static web app built in React on a storage account. If you’re curious about how to do this, my first article will show you how. This React app then calls RESTful API’s hosted on Azure Functions to manage data. It’s common to build this sort of web app as an MVC app using a framework like ASP.NET or django - indeed you could even build a React app using ASP.NET API’s using an inbuilt Visual Studio template. By choosing not to do this, you save approximately £650 per year per environment, as you are able to ditch an App Service S1 plan and instead use a virtually free storage account (My blog has cost less than a couple of pounds to host since I first started).

Next, we can look at database technology. My app uses Table Storage, an incredibly cheap and fast database technology from Azure. It’s got limited features, and certainly isn’t suitable for everything, but given that until recently it powered the Office licensing system and currently powers haveibeenpwned, it’s pretty good. Table storage’s advantage is that you only pay for the storage and operations - but there’s no cold start for those operations and they are fantastically cheap. The rate for operations is £0.000269 per 10,000 transactions, so you’d have to be slamming the service to start increasing your bill significantly. A standard approach instead of this would be to use Azure SQL PaaS, perhaps using Entity Framework or another ORM from your MVC app. The minimum price for a S0 SQL server is £132 per year per environment.

So we achieve the same result for our customers, have even less maintenance to do, get virtually infinite scalability in the face of usage spikes and save bundles of cash? Sounds suspicious, and there are indeed some caveats:

• Your bill for a serverless app will increase with usage - so these savings may not be as high if your utilization of your existing services is high. Something to remember about this though is that your bill actually increases with usage for ‘serverfull’ apps - it just scales in big chunks as you upgrade from 1 core to 2 or 4 (or from S1 to S2 or S3).
• You currently do lose something in tooling - setting up an ASP.NET Core solution in Visual Studio with EF Core and SQL Server is a few clicks. This approach requires a bit more thinking and work.

This work ties in to a larger ideal of Serverless which I’ve started calling Serverless Minimalism. In a serverless architecture we use exactly what we need to to complete the job at hand, nothing more. We are minimalist in both resource usage and boilerplate/extraneous services.

In other forms of architecture we clutter our apps with unnecessarily wasteful services that run all the time, like leaving your car running on your drive overnight so that you can save yourself the few seconds of starting the engine in the morning.

We can also load up far more code than we need to do a simple job. In the extreme example of comparing to an IaaS world running apps on a virtual machine, how much of that operating systems source code do you think you need to use to serve up some JSON? 0.5%? Less? And what is the rest of it doing? Sitting there, awaiting a hack and burning system resources that you could use for serving your customers.

In these wasteful architectures, not only do we pay the cost price, but the planet also does. By spinning up a permanently on resource that you then use barely 10% of the toal capacity of, your cloud provider is emitting CO2 on your behalf. Azure uses offsets, and has a great ambition to go carbon negative, but it’s well-known that offsets are not perfect and either way that is energy that could be used for something else or not produced in the first place.

Contrast this with a Serverless Architecture. You choose the most efficient tools for the job, serving static sites out of storage or CDN and loading up just the minimal amount of processing you need to complete backend work and spinning down afterwards. Rather than making our own service, we use shared managed services. Every element of the architecture has one purpose and just completes that singular purpose.

In summary, I’ve proven with a real-life production app that you can save thousands of pounds a year by using serverless instead of serverfull architectures because you only use the resources you need rather than wasting massive amounts of electricity, carbon dioxide and money by leaving servers running all the time. In the process you reduce your incidental security surface area and increase out of the box scalability.