Welcome to Serverless
“Serverless architecture allows you to run your programs on the cloud without a server.”
The cloud and virtualization enabled a lot of companies to come up with an architecture pattern called the SaaS (Software as a service). Serverless architecture eventually stemmed from SaaS.
The serverless architecture allows developers to run their programs on the cloud as functions. Developers write functions and push it to the cloud. This approach abstracts infrastructure and platform details away from the developer and allows to concentrate purely on solving problems. Serverless also means on-demand, your programs will be loaded on the fly without your intervention. FaaS is the most popular implementation of the serverless architecture. FaaS enables developers to handle individual requests in total isolation. FaaS is also ephemeral in nature and hence stateless. To persist data they will need to use external storages like Databases. They are also event triggered in nature.
Traditional vs Serverless
In traditional architecture, all the components of a system are typically wrapped in a cluster or VMs. There would also be a local network where each of the components would be able to talk to each other.
In Serverless architecture, the client would typically talk to the multitude of functions when and where necessary. In this setup, developers would never need to worry about the underlying servers.
Pros of Serverless Architecture
Business - Pricing
In Serverless architecture, your app runs on an on-demand basis and unlike traditional architecture, you don’t have to pay for 24x7. This results in a huge reduced server bill.
Pricing is calculated on the basis on the amount of RAM you choose and the amount of time (mostly in seconds) your program runs. Concurrency has no extra costs.
Business - Hiring Backend Engineers
Due to the lack of need to maintain infrastructure, the need to hire backend engineers also goes down.
Business - Process Agility
Multiple functions and individual deployments or rolls out means small, scalable delivery, increasing flexibility.
Developer - Environments
Setting up multiple environments is as easy as executing one command. This would end up being a change in one env variable or even simpler if you turn to Serverless frameworks, it will end up being deploy app-dev and deploy app-prod and voila!
Developer - Scaling Up
Scaling up with Serverless architecture could not be easier, in AWS Lambda its as simple as filling up an input box in the GUI related to concurrency limit. However, there are some scenarios that you might encounter where scaling up can be tricky, for example, in cases where you need more control over the new instances or replicas of your program.
Developer - Monitoring
Monitoring a function when compared to monitoring a microservice or a monolith is much simpler and also most of the time leads to simpler debugging and fixes as well.
User - Feature Adoption
Because of the fast roll-out process and scaling up nature, users can be delivered new features at a much faster rate.
User - Own Storage
This kind of architecture could support more user-provided storage like Dropbox and GDrive.
User - Client Side Caching
A popular adoption for front end applications when using Serverless architecture is to use some sort of caching like service workers. These kind of apps tend to offer a better offline UX in general.
Cons of Serverless Architecture
Business - Vendor Lock-In
Using FaaS means using vendor related libraries. This causes a vendor lock-in. There are some FaaS which are merging nowadays which are cloud agnostic ( Ex: KNative )
Business - Security Risk
If you end up opening too many gateways for the multitude of your functions, this could lead to an overall higher risk of security. It could also get tricky to maintain security in the first place.
Developer - Networking
In Serverless architecture, your resources won't be allocated a static IP and hence you must set up an API gateway as a must for the outside world to access. In some scenarios, this might be a limitation.
Developer - 3rd Party Dependencies
Since you will not have system level access, working with 3rd party dependencies is tricky.
The workaround is to have the dependencies bundled along with your app which bloats your package in turn.
Developer - Timeouts
Most FaaS providers have a timeout limit, AWS Lambda used to have a hard timeout of 300 seconds ( I believe now it’s about 900 seconds - a huge improvement ) and you might run into uses cases where this might not be sufficient and eventually limiting. Most likely the use cases would be if you are dependent on external calls for completing tasks.
Developer - Testing Locally
Because these functions are designed to work in the cloud, testing them locally could be tricky, the workaround is to have a developer environment in the cloud itself.
Developer - Architectural Complexity
Breaking a big app into a large number of smaller functions tends to add to architectural complexity. Hence using FaaS is not suggested for huge apps.
User - Latency
FaaS has a well-acknowledged problem called the cold boot or latency issue. Most of the FaaS providers null out the existence of your app when not in use, and this means when needed on demand for the first time, the latency for the end user could be high due to internal bootstrapping.
Serverless frameworks come in handy when dealing with Serverless apps in the form of easing things on the developer's end.
Advantages of Serverless frameworks include
- Scalable APIs
- Cloud Provider Agnostic
- Easy deployments
- Data Processing
- Easy Automation