Pros and Cons of Serverless Computing. FaaS comparison: AWS Lambda vs Azure Functions vs Google Functions
In 2014, Amazon wanted to fix the issue for event-based processing. Some customers used EC2 but the costs were too high and inflexible. SQS/SNS was too complicated for simple use cases, like an action when an S3 image was uploaded. So they came up with the AWS Lambda solution; they were not the first, but they were the first successful serverless computing implementation.
Serverless computing is a concept/model where the developers build an application and they don’t care about the underlying infrastructure. It is similar to a PaaS but you only pay when the resources are used. On a PaaS like Heroku, you pay even if the application is not used and you have to choose a package to run the code.
On FaaS, autoscale is there by default; there is no need to prepay dynos, etc. Behind the buzzword, there are still servers, but they are not your concern; the developer pays only for the function calls. All the installations, optimizations and security updates of infrastructure are performed by the FaaS operator. So servers are not used only from the point of view of the developer, but behind the FaaS are servers, containers, etc.
Most serverless applications have to adhere to an Event-Driven Architecture (EDA). This will allow for a more responsive application because these systems are by design asynchronous at an unpredictable scale. In terms of developer workflow, the developer has the role of developing, building and deploying the application. He does not have to worry about the infrastructure and scaling. With a framework like Serverless, the process of building and deployment can be more flexible and allows for abstraction of certain elements like the FaaS provider. Unfortunately, not yet being a standard for FaaS, it is not possible to build an entire application in an abstract way, so it will work on all three big providers.
On an FaaS deployment, the costs are dependent on how much you use certain resources like RAM, CPU, network or per number of requests. So if you don’t use any resources, the costs of running are zero. See comparison for costs for all providers.
In terms of security, some aspects will be handled by the FaaS operator, but this doesn’t mean that your application will be bug free of security issues; you still have to develop a secure application and follow best practices. Below is a table showing what vulnerabilities from OWASP Top 10 (2013 list) are handled by the FaaS operator and what should be the developer's responsibility.
| OWASP Vulnerability | Developer | FaaS operator |
|
A1 - Injection |
X | |
|
A2 - Broken Authentication and Session Management |
X - FaaS is stateless but developers have to make sure that they will not use custom auth protocols | |
|
A3 - Cross-Site Scripting (XSS) |
X - Mostly a frontend issue but in the hands of developers | |
|
A4 - Insecure Direct Object References |
X | |
|
A5 - Security Misconfiguration |
X | |
|
A6 - Sensitive Data Exposure |
X | |
|
A7 - Missing Function Level Access Control |
X | |
|
A8 - Cross Site Request Forgery (CSRF) |
X | |
|
A9 - Using Known Vulnerable Components |
X |
X |
|
A10 - Unvalidated Redirects and Forwards |
X |
All the advantages/disadvantages of FaaS are described below:
Pros of serverless computing:
-
costs - you pay only for what resources you use.
-
management of infrastructure - Buying and configuring servers is costly in terms of initial investment and specialised staff required
-
security of infrastructure - no need to worry about Linux, Tomcat updates - see Equifax breach where a security update is having a heavy toll on their business
-
easy deployment - developers don’t have to wait for OPS, DBA, etc.
-
scalable & HA - Amazon, Microsoft and Google are better at scaling than anything you can hire
Cons of serverless computing:
-
latency - FaaS adds some latency so for a Fintech high-performance application, maybe it is not the best idea to use FaaS
-
limits - memory (1500MB on AWS), execution time (300 secs on AWS, 500 secs on Google)
-
no local stored data - your application has to be stateless, so for most of them this is really a good thing but it is a limit nevertheless
-
monitoring & debugging - how you debug/test locally, offline ? There are solutions that are maturing but at this moment it is still a limitation
-
new technologies always have risks associated with them like lack of tools, stability of frameworks, libraries, etc.
-
vendor lock-in - you depend on AWS, Azure. What if Microsoft goes bankrupt in 3 years ?
A badly programmed function can increase the costs a lot. To avoid this situation, monitoring and testing is critical. 3rd party solutions for AWS Lambda like Dashbird and IOpipe, are helping developers to have a better picture of what is happening and the costs associated. For functions that require a long execution time, with AWS it is possible to map an API Gateway endpoint to an EC2 instance and run it as long as required.
Another challenge for security is how you manage the access to the Lambda infrastructure without providing an IAM key with Administrator privileges.
Managing a complex application with many endpoints can be challenging in microservices and EDA architecture, but with a framework like Serverless, the application can be structured and defined.
A couple of available FaaS frameworks:
- Serverless is one of the most popular frameworks:
- Functions can be structured in a yaml file and the application can be deployed entirely or only some functions from the application
- It is trying to add as much abstraction as possible, so developers will develop an FaaS application. In the configuration, you can modify to run the application on multiple FaaS operators like AWS, Google, Azure, OpenWhisk, Kubeless, Webtasks and Spotinst.
- Apex framework
- It is adding support for Go, Rust, and Clojure via Node.js shim
- kubeless is a Kubernetes-native serverless framework
- Sparta is a Go framework for AWS Lambda microservices
Below is a timeline of the compared services and their launch dates:
Nov 2014 AWS Lambda announced at AWS re:Invent
Feb 2016 Google Functions announced in preview and beta in 2017
Mar 2016 Azure Functions are introduced
There are other providers out there like IBM Cloud Functions, Webtask from Auth0, Iron.io, but for the sake of simplicity, we’ll compare only the biggest three.
| Feature/Providers | AWS Lambda | Azure Functions | Google Functions |
| Languages support | Node.js, Java, C#, Python, Ruby, C++ | Node.js, C#, F#, Python, PHP, Java | Node.js |
| Languages support with 3rd party | Any progrmaming language with Runtime API | With batch files can run anything | |
| Monitoring | Cloudwatch, Dashbird, Thundra, IOpipe | Azure Application Insights | Stackdriver Monitoring |
| Pricing | $0.20/million requests with 1 million requests per month for free | $0.000016/GBs, 400,000 GBs/month for free -- $0.20/million executions, with 1 million executions/month for free | $0.40/million invocations with 2 million invocations for free — $0.0000025/GB-sec with 400,00 GB-sec/month for free — $0.0000100/GHz-sec with 200,000 GHz-sec/month for free |
| Limits | Memory allocation range: Min. 128 MB / Max. 3008 MB Ephemeral disk capacity ("/tmp" space): 512 MB Maximum execution duration per request: 900 seconds | Allows only 10 concurrent executions per function No limitations on max. execution time limit | Number of functions: 1000 Max function duration: 540 seconds Function calls per second: 1,000,000 per 100 seconds |
FaaS and serverless computing are not beta or cool. They are used in production by companies like Nordstrom, Thomson Reuters, AOL, Netflix and Coca Cola.
FaaS proposes a type of architecture that developers have to adapt. It is a new way to build, deploy and manage code. it is a new mindset, similar to microservices, that has many benefits for big and small applications.
I think some kickstart tools to start a project that will auto-configure some services (DynamoDB, SES, SQS, SNS, etc) will be helpful for new developers. The Serverless framework should be able to do this with ease as it is based on CloudFormation templates.
A big advantage for an architecture based on serverless is around the availability of developers. As we know, today it is hard to find good developers and even harder to find good developers in a specific programming language. With serverless computing, some functions can be on Nodejs, but in six months when new features are launched, new functions can be developed with Java. This kind of flexibility has disavantages in terms of productivity, but the lack of developers is a bigger disavantage because that feature will not get developed at all.
Below are some updates on the serverless topic since this article was written.
Azure launched a premium plan for enterprise workloads. Some features such as custom instance size (which permits up to 14Gb of RAM) are a welcomed addition. This should help migrate existing applications to serverless. Also, the premium plan is trying to fix the issue with cold starts, but this is achieved with a pre-warmed instance, which will increase costs.
Amazon added some new features in Lambda such as Layers, Runtime API and bigger limits (I updated them on the comparison table).
By using Layers, you can group the libraries and dependencies of a function. This will decrease the size of the function code and speed up the deployment of updated functions.
Now there are new runtimes supported on AWS Lambda: Ruby, C++ and Rust. This was possible with the Runtime API, an interface that developers can use to write functions in any programming language they want.
Also Amazon launched DynamoDB On-Demand, a true serverless database. Developers don't need to specify capacity and currently the pricing is per read/write requests.
