This serverless architecture has the following characteristics: pay to resources used and cloud provider is responsible per running and scale out and scale in based needs.
Another thing word serverless means no server, no true because you need one server to run code, in this case i believe this name is to call focus and because too no need know server where is running your code.
Many times when people talk about serverless architecture the lambda function is referenced, but any anothers services can be considered serverless for example: firebase, s3, faunadb and more.
In house many time before people running servers in house where all responsibility the company, you need take care internet link, electricity, maintain OS updated and another responsibilities. But one big disadvantage is when you need to scale your application you need to increment hardware or purchase another server machine takes a lot of time. This is one problem because you need to scale your application to spike at 12pm for example.
IAAS is knowledge with infrastructure as a service where many cloud providers with: aws, gcp and azure offer services. Using IAAS you pay per resource that you need for example: if you need running one web application you use an ec2 instance.
IAAS allows the choice of resource hardware or modify resource hardware quickly and easily. In Many cases you need to scale your application when receive spike access at 12pm exist ways allow create copies of the web application in other machines quickly.
Paas is knowledge of the platform as a service, where Heroku is a good example. The paas is one evolution of the IAAS. In this case you specific technology and send code to paas, paas is responsible for setting all things to your application running. Removing your responsibility settings all things to your application running.
Services model serverless pay what you use, different another solution above where you pay to the service running same no any interaction with service. The model you pay to use and scale up and down is the responsibility of the cloud provider. For example: firebase you pay what you use and if volume grows the firebase increases resource it or S3 is another example you pay to the file stored and download the file no need to worry about disk full because this is the responsibility of the s3 service.
The lambda function is one function of any programming language where one specific task is executed.
I think it is necessary to talk about lambda function or FAAS(function as a service) because many times when people talk about serverless architecture already associated with the lambda function, but when analyzing aspects of the serverless architecture you pay what you use and cloud providers manage your application for you. When I think about this, Firebase and S3 are serverless.
When and why use the lambda function?
Imagine that you have a service responsable send email to anyone, to prevent create all applications to only to send email and pay to run this application one ec2 monthly same application no receive any interaction some moments, already another moment you have huge volume the emails to send and you need scale this application to delivery all emails suitable time.
In this situation the lambda function is a great solution because you need to create only one function to send email, pay only what you use and the cloud provider scales up and down automatically the lambda function numbers when increasing the volume of email to send.
Too when you need execute task spend little time less than or equal 15 minutes, tasks eventually have spike execution and other times no have interactions and you don’t care responsibility the scale up and down your application you want give this responsibility to cloud provider and you focus logic the application.
You need to generate a report that takes a lot of time to generate. In this case no suitable use of the lambda function because the lambda function limit lifetime is 15 minutes in aws.
The websocket application is another example because after time the lambda function process is finished, so, websocket clients lose connection.
The api that uses database no scale resources automatically. The lambda function scales the application layer, but your database does not scale resources automatically. It's one problem, because each request creates one the lambda function execution each the lambda function creates a new connection to your database, if your database is not scale you can down your database. In this case is interesting use one database with scale based on demand like: dynamodb, faunadb or aurora serverless
Firstly let me explain what is the lambda function cold start, the cold start is time needed to the cloud provider in this case AWS get the lambda function code and put a docker container with code to run and after execute what you need. This occurs on the first time you interact with your lambda, after interactions no have cold start until the cloud provider kills the lambda function because no have interactions, in case this occurs the next interaction the lambda function will have the cold start again.
Now you are thinking what is the problem the cold start because only increase time little bit, if is not problem for you, ok, but exist situation where you have specific response time for example 5 seconds to response one request, in this situation to reduce the cold start execute following things:
- Use only dependencies necessaries because more and more dependencies more size will be the lambda function code more time spend put it to running in docker container
- Increment resources the lambda function only when necessary. Example: memory
- Using interpreted language like python, node.js and another because check types in runtime.
- Warm up the lambda function this way time to time interacte the lambda function to maintain warmed up. In this link https://www.serverless.com/blog/keep-your-lambdas-warm/ you have one example about this.
- Vendor lock.
- Limit timeout 15 minutes.
- Limit memory 10GB.
- Can’t store files in disk because you will lose the file.
- High volume connections because create one execution of the lambda function that creates a new connection on the database.
- More complex implements tests in application.
- You will have problems when using some dependency OS, because the lambda function running in docker, docker container is light. So install only packages necessaries.
- Development environment needs components from the cloud provider.
- Deploy the code manually or you need to use cloudformation or terraform.
- A lambda function is one function isolated from another code in the application. When you change code the lambda function has no impact on another lambda function that occurs in a monolith application.
- The cloud provider is responsible scale up and down After deploying the application your team no need managed it is the responsibility of the cloud provider.
- Low cost because you pay what you use
Can’t store file in disk: because after time execution the lambda function finishes and you can lose file storage in disk. To resolve this problem using storage solutions like S3.
Development environment need components of the cloud provider: exist a project that simulates the cloud provider services locally, this project named localstack. https://github.com/localstack/localstack
Deploy the code manually: you can resolve this problem using a serverless framework. This tool simplifies your deploy because this tool reads serverless.yml file where all needed settings are to deploy the lambda function. Link of serverless framework: https://www.serverless.com/
High volume connections because create one execution of the lambda function that creates a new connection on the database: in this situation you need some database to scale your resource on demand like Dynamodb.
More complex implements tests in application: the lambda function is an event trigger, so when one event triggers the lambda function executes code with the event data. In this case you can implement unit tests mocking event the lambda faction will receive to prevent use of the cloud services.
Take care how to use the lambda function because the cost is the sum of the following things: how many times executed the lambda function, time each execute the lambda function code and resource allocated to execute this lambda function.
Another thing necessary take care is when you use the lambda function you scale application layer, but some moment this capacity the application layer scale can be cause the problem in database layer because create many connection on database or you communicate third service and third service have limit request per time or third service no prepare receive huge volume request, case no prepared you can down third service.
These are something you stay warned about when you think about using the lambda function(serverless architecture).
I believe this post I explained a little bit of what I know about the serverless architecture, what it means, and explains that services like Firebase or S3 are serverless, not only the lambda function(FAAS).
Talked more focus about the lambda function, when and where to use it, when not to use it and explain the advantages and disadvantages and keep in mind it is not a silver bullet, exist sceneries correct to use it, sceneries wrong to apply the lambda function.