Introduction
Earlier, the definition of serverless architecture was bounded to applications dependent on third party services in the cloud that manage the server-side logic and state.
Now it is defined by stateless compute containers and designed for an event-driven solution. In a microservice architecture, monolithic applications are broken down into smaller services so you can develop, manage and scale them independently.
And FaaS takes that step further by breaking applications to the level of functions and events.
AWS Lambda lets you run an application without rigging or managing servers. It is an event-driven computing platform. The code is executed in Lambda upon configured event trigger.
A simple use case could be that when an image is uploaded into Amazon Simple Storage Service (S3), a Lambda function could automatically resize the image for mobile, tablet, desktop devices. The event that triggers the Lambda function is the file being uploaded to S3. Lambda then executes the function of resizing the image.
AWS Lambda is the perfect example of serverless architecture – computing execution layer in the cloud where providers manage the resources. It employs Function as a Service (“FaaS”) model of cloud computing. This allows you to build and run applications and services without managing infrastructure. Google Cloud Functions, Iron.io, Serverless, IBM’s OpenWhisk project, and Azure Functions are some popular examples of serverless platforms.
Let’s look at the benefits and drawbacks of serverless architecture, specifically AWS Lambda.
Benefits
You are not running your app for 24/7 anymore, and you’ll be charged against the time that your functions were running. Such architectures remove the need for the traditional ‘always on’ server system sitting behind an application, significantly reducing operational cost and complexity.
If you build and manage your own FaaS infrastructure, it’s all about optimisation of resources (From an IT/ops perspective) which translates to reduced cost – a major reason to go serverless.
Faster Development:
Product engineers can innovate rapidly as serverless architecture has alleviated the problems of system engineering. Thus you spend less time on operational issues – makes devops life easier.
Technology stack can be updated in a flexible manner. Identity management, storage are some examples of the concerns of internet applications which are exposed to FaaS or handled by middleware. Engineers can concentrate on the actual business logic of the application.
Easier Operational Management:
Automatic scaling functionality of FaaS not only reduces computational cost but also reduces operational management overheads.
Serverless platform provides a clear separation between infrastructure services and applications running on top of the platform.
System Engineers can focus on managing the core services such as databases and load balancers while product engineers manage the functions running on top of the platform.
Bundling and deploying the FaaS architecture is pretty straightforward and simple when compared to deploying an entire server. Continuous integration, continuous delivery or containerization tools are not required. Developers can write the code directly in the vendor console.
Thus a completely serverless solution like AWS Lambda will not require system administration.
Scaling benefits of FaaS beyond costs:
Given an influx of events, AWS scales up Lambda events to take all incoming traffic. On the upside, it works as a great cron job service.
Lambda scales the batches with SQS jobs, picks them off the queue, processes work, and then shuts all the way off again when it is done. No EC2 spin up is required.
Since scaling is taken care of by the vendor, with FaaS hosted apps you don’t have to consider the number of concurrent requests you can handle before running out of memory. This is done for each request/event. A significant increase in load in downstream databases and non-FaaS components will have to be handled.
Reduction in Operational Costs:
The basic advantage of this technology is that you only pay for the time your function executes and the resources it needs to execute.
AWS Lambda bills you only for the time when the FaaS function is called. It means you are charged 95% less compared to running a server for an entire month. It allows operational cost reduction.
Drawbacks
There are few things which can’t be achieved with this kind of architecture, like keeping a web-socket connection open for a bot. There can be vendor control issues, multi-tenancy problems, vendor lock-in and security concerns, due to third-party API system.
System downtime while implementing APIs, unexpected limits, usage cost rate changes, forced API upgrades, and loss of functionality are some of the drawbacks of giving up system control to platform vendors.
State
The in-process or host created state will not be available to subsequent invocations. FaaS functions have significant restrictions when it comes to the local state. Stateful backing service, typically a database (e.g. S3, Redis) is required to store any data that needs to persist.
DoS (Denial of Service)
AWS Lambda, currently, limits you to 1000 concurrent executions you can be running of all your lambdas. Your whole AWS account has this limit, and If you try to load test while using same AWS account for both production and test, you will accidentally cause DOS on your production.
Execution Duration
AWS Lambda functions are aborted if they run for longer than 5 minutes. There are tasks which run for more than the given limit, like converting a video file format.
Startup Latency
It may take a while for a FaaS function to respond, specially JVM-implemented functions on AWS. It may take more than 10 seconds to start up. API/micro-service will almost always be able to respond faster since it can keep connections to databases and other things open and ready.
Testing
Unit testing Serverless Apps is simple for multiple reasons. There aren’t a lot of custom libraries or interfaces to implement. You just have to code. Integration testing is rather hard for Serverless Apps. At present most of the vendors do not provide a local implementation that you can use so you’re forced to use the regular production implementation.
This means for all your integration/acceptance tests, you would be deploying remotely and testing using remote systems. Less configuration, cross-account execution limits impact on how you test
Deployment / Packaging / Versioning
Currently, the feature of bundling up a set of functions into an application is lacking. Since you would need to deploy a FaaS artifact separately for every function in your entire logical application. Deploying 20 FaaS functions on JVM means deploying your JAR 20 times. You can’t atomically deploy a group of functions. You have to turn off the event source which is triggering the functions, deploy the whole group, and then turn the event source back on.
Zero-downtime applications cannot afford this. There are no means to atomically roll back the applications as they are not versioned.
Monitoring and Debugging:
At present, you are stuck on the monitoring and debugging side with whatever the vendor provides. It is very basic with AWS Lambda, which suits some cases but what we really need in this area are open APIs and the ability for third-party services to help out.
Summary
Serverless is a style of architecture where we rely to a smaller extent than usual, on running our own server-side systems as part of our applications. We do this through two techniques – Backend as a Service (BaaS), where we tightly integrate the third party remote application services directly into the front-end of our apps, and Functions as a Service (FaaS), which moves server-side code from long-running components to ephemeral function instances.
Serverless architecture is not the correct approach for every problem, so be chary of anyone who says it will replace all of our existing architectures. And be even more careful if you take the plunge into serverless systems now, especially in the FaaS realm.
While there are riches (of scaling and saved deployment effort) to be plundered, there exist dragons (of debugging, monitoring) lurking right around the next corner.
Those benefits shouldn’t be quickly dismissed however since there are significant positive aspects to Serverless Architecture, including easier operational management, reduced operational and development costs.
The reduced feedback loop of creating new code components is the most important benefit of all. It is largely because there is a value in serving technology to the end user as soon as possible to get early feedback. Also, the reduced time-to-market that comes with Serverless fits right with this philosophy.
I would like to know your thoughts on serverless architecture and AWS Lambda.