Serverless functions are any functions of an application that are hosted and run on a cloud serverless platform, such as AWS Lambda, GCP Cloud Functions, or Azure Functions. A serverless function is typically designed with one single purpose in mind, and it will run (and consume compute resources) only when triggered.
Serverless functions allow developers to ignore the intricacies of provisioning and managing specific machines to run their applications on the cloud. Instead, the cloud provider who operates the serverless function service (such as AWS Lambda) takes care of provisioning and managing machines, and scaling up and down automatically based on the frequency with which the function is being called.
Aside from the convenience of not having to worry about the details of servers, serverless functions can also save developers money, because each function in an application is run and scaled independently, and developers are billed only for the compute they actually use.
If, for example, a developer has an application with four main features but users typically only use one of them, serverless functions would allow for the functions associated with the popular feature to scale seamlessly while functions associated with the unused functions would remain available in case they were called, but would not be racking up any server charges while they remained dormant.
There are a variety of reasons you might not want to use serverless features for your application. Among them:
Latency – when a once-dormant function gets called for the first time in a while, it can take a while to start up, depending on the specifics of your application and the cloud services you’re using. This is known as a “cold start”, and it can cause high latency in your application if you’re not able to avoid or mitigate it.
Observability – due to their nature, it can sometimes be challenging to debug issues with serverless functions in production.
Vendor control – while handing the complexities of server provisioning and management over to cloud vendors has its advantages, it also means that developers can’t control those things. It can also sometimes limit the ease with which you can implement technology from outside that vendor’s ecosystem into your application architecture.
There can also be a bit of a learning curve for some developers, as event-driven architectures and serverless functions are relatively new. This can be both an advantage and a disadvantage – it may take developers longer to wrap their heads around for the first time, but it could also help with hiring as many developers prefer working with cutting-edge technologies, and see work in event-driven development with serverless functions as valuable experience.