What is Serverless?
Hello, I’ve recently gone serverless and wanted to share my experiences with you. Alongside the reasons why I chose to and why you may, or may not want to go serverless!
This is really hard to define, it now encompasses so many services and methods such as:
• Functions As a Service (FaaS) e.g. AWS Lambda which function as your API endpoints
• Backend As a Service (BaaS) e.g. Firebase
• Platform As a Service (Paas) e.g. Heruko
• Authentication Services e.g. Auth0
• And many more…
The definition I’ve come to is:
Anything where you don’t have to worry about the underlying server e.g. applying updates, patches, dealing with networking etc.
Generally speaking it should be stateless and event driven.
Advantages of Serverless
This is one of the biggest advantages as rather than paying for a server which is on all the time, you only pay for the amount of traffic/requests your API or site receives. This is ideal for the majority of applications which aren’t getting constant traffic.
Most platforms offer a free tier for a certain amount of traffic, e.g. Functions As a Service which would act as your API, generally you get 1 million requests a month free! Which is awesome because you can run your application for very little cost.
Another advantage is for development speed, because the provider deals with setting up/patching servers and a lot of the operating costs associated with running a service, it means you can focus on just your application logic.
It also means that it’s super quick to get started! You could set up a function by the time you’ve read this blog!
One great take on this idea of getting going really quickly and iterating quickly comes from a serverless focussed company called Zeit, their serverless platform is called Now! They are amazing because you can use the command now and deploy functions and websites, straight away!
This means you can easily iterate, update and add new features really quickly.<.span>
Disadvantages of Serverless
Provider Lock In/Reliance
Because the nature of serverless is that you work on top of a provider, you are both reliant on them being up/working (often covered by an SLA) and relatively locked into their platform.
It does require work to change provider e.g. moving from Azure to AWS. Each company provides its own set of integrations and ways of working, so you would have to spend time migrating your Functions for example.
You are also bound by the limits that the provider sets on your Function e.g. Memory, CPU and Time bounds.
This can be a mixed bag, with a variety of tools available. I’ve used several providers and found some tooling is better than others. Azure’s tooling particularly around Functions, is great especially with VS Code extensions.
Initially its quite simple, for example the below is standard for AWS implementation:
However, when your application begins to grow in features and requirements the architecture can become very complex, with many tens of Lambdas especially if Lambdas become triggered by events across your stack.
You have to be quite disciplined and plan properly as you grow and require more Lambdas.
Spin Up Time
Also known as ‘cold start time’ is the delay caused if your functions haven’t been run in a while. This can be a snagging point for some people depending on your application, especially as often the first interaction with your API tends to be login/signup endpoint.
However, this is getting better all the time and varies across providers.
Switching from Express
Previously I used Express JS to serve up my web page and also API endpoints. This ran in an Azure App Service, however as I was only receiving occasional hits. I changed over to Azure Functions for the API endpoints to reduce my costs and served up the website via Azure Blob Service.
This was pretty straightforward. I also discovered this from Firebase which lets you change over with very little code changes.
One of the snagging points was all the headers I wanted to set on the response and on the website. I had to add a response wrapper around the Functions response, it also meant applying custom rules on the CDN serving up the static site. This was okay however it does mean keeping two sets of quite complex custom headers in sync.
I had approximately 30 endpoints, and decided for simplicity to add them all into one repo for the time being, however you could split them up into a monorepo or many repos.
Serverless is new and shiny, and you should definitely try it out and there is lots to try!
Try out the different services to find out which one suits you application, the way you work and establish if it is a suitable use case for your application.
I’m going to write some follow up blogs on some of my favourite services I’ve tried (will update with links):
• Azure Functions