I’ve been an advocate of AWS Lambda ever since I found out about it. It’s just unfortunate that I’ve only really been able to make use of it in the last few months in a commercial context.
The advantage of Lambda is that you have a simple function based response to a request (which can be exposed via API Gateway) and can code for a specific use case. This might sound unimportant, or even trivial if you build on a framework like Django or Express or something but it isn’t.
The framework approach relies on a “server”. Nowadays this would be a compute instance usually based on linux architecture, and essentially is a virtual machine that you can “spin up” at any time.
The idea of spinning up servers is still amazing to those people who think that you should be in control of your own hardware and data centres. It’s great to say “I need another machine” and one is there.
When you go serverless/Lambda style solution, it’s much easier. There’s no spinning up, as AWS does that for you. You’re only bothered about the functionality.
And here’s the thing… you don’t have to care about anything other than the functionality. You don’t have to care about code backup, downtime, server maintenance, security updates etc. It’s remarkable. It sounds amazing.
It is amazing.
The startup I’m CTO of has been serverless for months. We’ve had several hundred thousand users utilising our services without the need for worrying about scaling capacity or security… or anything. It just worked.
Then we inherited another site to go along with our services. The site is Wordpress based (not my favourite) and sitting on an AWS instance. And the headaches and stress were huge.
The original devs had put the database on the same server instead of using RDS. They’d used non-standard (for the linux version) installs of apache, and PHP and a couple of other things too.
And there was no backup scenario… at all!
So, my first job was to create a backup and regular backups of the site. Which is easier said than done.
It’s a headache. Updating a linux version, and checking something isn’t broken, when you wouldn’t know if it was broken anyway?
We had to test rebooting as well, and when we rebooted, the entire site went down… because someone had not saved the iptables setup properly… which meant the site was down.
All in all more than a day of time was lost to just making sure we could get the system running if it went down.
Conversely, we’ve never had to worry about any of that with the AWS Lambda functions at all.
It just works
It’s also got tests.
So if we change stuff it is easy to check that it’s going to work.
So, next time you’re wondering if serverless architectures are the way to go, factor in the cost of maintenance of servers, rather than the cost of development, and you’ll realise that long term, the serverless route is almost certainly a better way to go.