It’s a numbers game

Chief Engineer of Futures at BAE Systems Applied Intelligence Read time: 3 mins
Engineers nowadays have to be even more multi-faceted than in previous generations. Andrew Stock explains why cost optimisation now ranks high among engineering disciplines
It’s a numbers game I’m writing this just at the very end of March. Even this year of all years, amidst the ongoing horrors of the pandemic and challenges of lockdown, it’s a time when Spring is in the air and some much needed lighter evenings begin to mark the true end of winter.
 
It’s also the period when my bank bombards me with reminders about the upcoming end of the tax year and the need to maximise my ISA allowance – chance would be a fine thing!
 
This focus on all things financial reminded me, though, of back when I first started out, and expenses and cost requirements did not exactly loom large.
 
Partly this was a consequence of my own need to better get to grips with building, deploying and supporting features – the day job, in other words. And also, the fact was that in a data centre environment, which is where I started work, costs were rarely something we were exposed to. Quite simply, in that sort of environment, you’d be lucky to know how much you were directly paying for the computers and an apportioned cost of the data centre costs, maintenance and so on.  All in all, it was very difficult to understand exactly what each item cost.
 
With serverless technology, however, it’s a whole new story.
 

Money matters

Serverless, as I explained in my last blog, offers both engineers and recipients numerous benefits, helping propel new applications and services from idea to impact without the constraints of servers. But it also gives us unprecedented visibility into the cost of every part of our system. With just a little effort we can see costs per feature per customer – something that was out of reach to those who came before us.
The granular nature of the billing also means that you’re rewarded for being frugal with resources. For example, in a “standard” system for resilience I might run two web servers so that if there’s a problem with one, the system can nevertheless continue running.
 
Let’s assume they are 60% busy normally but peak a bit higher. My costs are for those two servers 24/7. In a serverless environment, however, I’d only pay when someone accesses the system. This means that even if the unit cost is higher, I’m paying it less often so saving money, and that’s even without all the other savings in areas such as licensing, maintenance, patching and so on.
 
This is because serverless functions are billed based on how much memory is consumed and how long the function runs for. If I make my code twice as efficient then in a data centre, my servers are now running at 30% each, but I still need two for resilience. In the serverless case I save 50% of my compute costs, immediately.
 

A new discipline

As a result of these changes, serverless has enabled us to introduce a cost optimisation discipline to the engineering capability. Without affecting the offering to our clients, we can look at where we are spending money and make a Return on Investment calculation on the (engineer time) effort to make a change vs the expected improvements in cost, avoiding, for example, a scenario where 10 days of engineer time saves just £10 a month.
 
As an added bonus we also benefit from improvements made by the cloud provider. One of these was in December when AWS changed their billing from every 100 milliseconds to every millisecond without changing the overall price). On the face of it, not a big change, but imagine it like this: you want to rent a car for a short trip but the rental company only offers daily rental. You use the car for two hours, but pay for 24. However, if they changed to hourly rental, it would cost you just 1/12th of what it did, without any changes being made on your part.  In the AWS example, one company saved 40% overnight without making any changes!
 
We’re only at the start of the process of embedding cost optimisation as an everyday activity for our engineering teams, but there is also a lot to be gained from exploring it.
 
We can also imagine it being of use to product managers for per-usage based products to understand actual client metrics, what we’re charging them, and what it’s costing us to provide. We can even envisage bringing our colleagues in Accounts closer to the engineering so it’s included as part of their financial work – the potential is endless.
 
And certainly, when it comes to saving money, every little helps!
 

About the author
Andrew Stock is Chief Engineer of Futures at BAE Systems Applied Intelligence
andrew.stock3@baesystems.com
Government Insights Promo Block Image

Explore Government Insights

Stay up to date with the latest thinking, trends, technologies and projects from our Government team
Find out more
 

Recommended reading:

 
top
Andrew Stock Chief Engineer of Futures at BAE Systems Applied Intelligence 25 March 2021