The main advantage of the serverless paradigm is that your code doesn't need to run all the time.
When requests come in, your code boots up to serve them. If many requests come in, many instances of your code spin up. If traffic winds down, so do your functions.
As a consequence of this:
You don't pay for code running all day long, even when no traffic comes in.
You don't have to worry about long-lived processes becoming unresponsive and needing to get restarted by hand.
You don't have to set up health checks or readiness checks of any sort, because there's no process instance to worry about.
You have a very predictable way of understanding how your application scales. For each request, there is a new separate and discrete function invocation (also known as the 1:1 model).
Crucially, each lambda "instance" can only be busy with only one request at a time, which means that your function will be booting up (and later shutting down) constantly. A fresh function instantiation is known as a cold boot.
After the function responds, it'll stay hot so that it can be re-used again, in the event that a new request comes in shortly after that.
With this reality in mind, Now attempts to help you in a few key ways:
Builders like @now/node compile and compress your source code and its dependencies (e.g., require or import statements) so that you avoid unnecessary overhead. This is symmetrical to how frontend developers bundle and compress their code before sending it out for production web pages.
As a side effect, using builders that only ship the code that gets used reduces the surface of error, encourages better security and gets rid of nasty surprises.
The monorepo strategy encourages setting up discrete entrypoints for different parts of your application. This ensures that a cold instantiation for, for example, route /a doesn't have to pay the penalty of initializing the code of /b, which could be less accessible or even an old deprecated version.
Limits can sometimes be discouraging, but they can also be a forcing function to prevent unintended consequences, such as slow response times or increased cloud bills.
To understand the hidden cost of shipping a lot of code, one needs to look no further than the web platform.
A web browser is not too dissimilar to the serverless environment. The process or container (the browser tab) is instantiated, code is downloaded, parsed and interpreted. If you refresh (twice on Chrome), you can think of the "function" as being hot, due to caching strategies in browsers.
We can also draw from the web platform's attention to the code size problem to understand that there's a cost to parsing and evaluating:
Source — While servers will be much faster at processing through code, these same principles all apply.