Serverless computing is considered the future(if not already the present) of application deployment.
It is widely popular in microservices architecture which speaks in the favour of small, isolated and stateless applications.
Here I will introduce serverless computing in the most beginner friendly way and leave you with already curated resources from Microsoft to explore further.
Definition (key phrases from Wikipedia):
- cloud provider allocates machine resources on demand
- when an app is not in use, there are no computing resources allocated to the app
- pricing is based on the actual amount of resources consumed by an application
Traditional application deployment includes:
- Buying or renting servers.
- Keeping them updated.
- Taking care of availability and security.
- Paying for them even if nobody uses them.
- Add more servers if people get fond of your application.
How is serverless different?
- Cloud provider takes care of the servers.
- Security and availability are the provider's responsibility.
- Pay only for the time when the services are in use.
- Service scales up and down instantly(almost) as per the load.
What are the popular serverless products?
- AWS Lambda
- Azure Functions
- Google Cloud Functions
- Code being executed is typically called "function"
- Functions are stateless - they cannot hold data across requests like in-memory objects. Any persistence needs to be handled with the help of connected services like a database or file storage.
- Functions are started using triggers - types of triggers include HTTP(s) requests, events and cron-jobs. Events is a vague type which can include a huge list of possibilites from changing a row in a DB to getting an error in logs of another application.
- The function is deployed and started - for e.g. a command like "node server.js" is executed on a random machine.
- When the request has been attended to, the function is available to be shut down.
- The provider could be lazy here and may keep it on for some more time.
- If another request comes in the meantime, it can go to the same server which was already running. If no requests for some time, the server cleans up.
This leads to some important observations:
You can never be sure if consequent requests will lead to the same server - therefore, as mentioned above, treat functions as stateless - the design should not rely on any state being maintained on the server.
The first request may take some time (cold start) - there will be a delay in attending to the first request if there are no servers already running. (typically 100ms to a few seconds)
Best practice - keep functions lighter for quicker deployments and start-up time.
There are a lot of boring reasons but one reason should be enough - Money 💰
- Serverless is the cheapest way to deploy a backend application.
- There are free quotas every month based on the number of requests and the pricing tier.
No popularity = No bill
Fun fact: We deployed a few functions on Azure for a popular global website and it cost us 8 USD for 3 months. The e-commerce sale made due to those functions was around 100,000 USD.
Thank you for reading.
If this gets you interested about Serverless, you can check out these resources from Azure.
Deploy your own function in a free sandbox - https://docs.microsoft.com/en-in/learn/modules/create-serverless-logic-with-azure-functions
In depth modules for learning - https://docs.microsoft.com/en-in/learn/paths/create-serverless-applications
If you want to connect with me, you can find me on Twitter