Lately we hear about serverless everywhere, as a natural progression from monolith to microservices to serverless.
My favorite definition of Serverless is from urban dictionary
The name of a fad everyone loves to hate. Where the architectural model is shifted from running processes to running functions with *no control* or need to integrate with the operating system.
Why is no control so contested? As with any trade off, the answer is: it depends. Less control also means less responsibility, so is less control always a bad thing? If you are deploying simple, stateless, non-CPU intensive applications then a serverless architecture has a huge advantage: agility. Templated and reusable pieces let us spin up experimental apps very quickly without the responsibility of managing and patching any infrastructure at all.`
A big difference between microservices and serverless is their execution lifetime. A microservice is expected to be always available while serverless functions come alive when needed, execute, and terminate.
IaaC — Infra as as service is like renting the land and parking an RV on it to live in it. You own the RV and everything else in it to make it habitable.
PaaC — Platform as a service is like leasing a house and living in it. The owner takes care of the house and its improvements while the renter makes it livable.
FaaC — Function as a service is like staying in a hotel room whenever you need a place to stay.
- Only pay for the time it is executing.
- Our service doesn’t have to be up and running all the time.
- Increases development speed. Easy to build and deploy.
- Automatic scaling.
- Platform agnostic. Just build the business logic and move it to any platform provider.
- Decomposing the application into small functions might not always be the best solution.
- If there is a state that needs to be exchanged between functions, inter-function communication and some expensive plumbing is necessary.
- Complex error handling can be difficult. More operational overhead when maintaining 100s of functions.
- Using native libraries is difficult and not recommended.
- Memory, CPU and network are limited to what is provided.
If we have a simple, stateless, non CPU intensive applications are perfect for serveless. AWS recommends using lambdas for the following use cases
- File processing
- Stream processing
- A storage service to keep all the web assets (html, css, js, images).
- A distribution system to manage the caching and availability of the site.
- A DNS service to map custom domain to the cloud distribution system.
- API Gateway to expose API.
- Serverless functions to execute the business logic.
- Database to persist state. — Database can be SQL or document/key-value database. The selection depends on the way you interact with the data in the store. If the way we retrieve the information is always going to be the same, a document database like dynamodb works great. Watch Martin Fowler’s talk on noSQL to get an understanding.
This three tier architecture is provider agnostic and can be used in Google Cloud Platform or Azure Cloud Services or IBM Open Whisk.
Most serverless providers have similar solutions and functionality. The solution that works best will depend on what you, your team, and organization know and requirements of your application. If you have no constraints, I’d recommended getting started in AWS.
|AWS Lambda||Google Cloud Functions||Azure Functions|
|Pricing||1M/month free||2M/month free||1M/month free|
|Triggers||API, S3, DynamoDB||HTTP, Any GCF services (firebase, analytics, Pub/Sub, Storage)||API, Cron, Azure Events, Azure|
|Max execution time||15 mins||1 min - 9 mins(upgrades)||5 mins - 10 mins(upgrades)|
|Concurrency||1000 executions||Unlimited for HTTP. 1000 executions||Unlimited|
You are covered. There are many open source Serverless solutions out there!
Rohit Akiwatkar wrote a comprehensive article about the Serverless open source solutions.
- Serverless Architecture with AWS Lambda
- AWS multi-tier architecture
- Comparing serverless providers
- Serverless and open source- Where do we stand today
Next up: Understanding AWS Lambda