👋 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!
What is 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
Cost
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 you API or site receive. 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.
A great example of this comes from Troy Hunt who runs Have I Been Pwned, he wrote this really insightful blog on how he runs a service that receives millions of requests for a few dollars!
Development Speed
Another advantage is for development speed, because the provider deals with setting up/patching servers and a lot of the operation 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, whose serverless platform is called Now! Who are amazing because you can use the command now and deploy functions and websites, straight away!
This means you can easily iterate, updating, adding new features really quickly.
Disadvantages of Serverless
Provider Lock In/Reliance
Because of the nature of serverless in 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 do work to migrate 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.
Tooling
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.
Zeit is a serverless company that has some really cool tooling, and doing some really interesting things particularly around Node.JS, e.g. NCC which is web pack but for server side applications.
Architecture
Initially its quite simple, for example the below is standard for AWS implementation.
Reference: http://blog.tonyfendall.com/2015/12/serverless-architectures-using-aws-lambda/
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 do proper planning 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 was using Express JS to serve up my web page and also API endpoints. This was running in an Azure App Service, however as I was only receiving occasional hits, so to reduce my costs I changed over to Azure Functions for the API endpoints and serve 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 ~30 endpoints, and decided for simplicity to add them all in one repo for now, however you could split them up into a monorepo or many repos.
Conclusion
Serverless is new and shiny, and you should definitely try it out and there is lots to try!
You should try out many of the different services to find which one suits your application and the way you work and if it is a suitable use case for you application!
I’m going to write some follow up blogs on some of my favourite services I’ve tried (will update with links):
- Firebase
- Zeit
- Azure Functions
Top comments (0)