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
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.
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
Explore Government Insights
Stay up to date with the latest thinking, trends, technologies and projects from our Government teamFind out more
- How I stopped patching and made my system more secure. Andrew Stock says that of the many benefits arising from serverless technology, removing the need for continuous patching is surely front and centre
- Selling serverless. When it comes to going serverless, Stephen Rolph and Paul McAninly say that the abundant benefits outweigh any teething problems
- The coming surge in serverless. ‘Serverless’ is far more than just the latest tech buzzword, says Chris Hesketh. It actually represents a new way of working that can deliver efficiency, cost savings and agility
- A question of agility. Government IT is on the move. Chris Hesketh explores why Agile by Design is finally taking root across public sector organisations
- Going Digital is one thing, Transformation is quite another. Mivy James explains why genuine transformation requires far more than just digitising outdated processes
- Adapting for Agile: Lessons from the frontline. Changing how an organisation works is not for the faint-hearted, says Iain Abernethy. Here, he shares a few lessons from years on the Agile frontline
- In control with Agile. Jenny Matthews explains how Agile working