What is Serverless Architecture? What are its criticisms and drawbacks?
Serverless architectures refer to applications that significantly depend on third-party services (knows as Backend as a Service or “BaaS”) or on custom code that’s run in ephemeral containers (Function as a Service or “FaaS”), the best known vendor host of which currently is AWS Lambda.
Despite the name, it does not actually involve running code without servers. The name “serverless computing” is used because the business or person that owns the system does not have to purchase, rent or provision servers or virtual machines for the back-end code to run on.
Serverless code can be used in conjunction with code written in traditional server style, such as microservices. For example, part of a web application could be written as microservices and another part could be written as serverless code. Alternatively, an application could be written that uses no provisioned servers at all, being completely serverless.
FaaS provides a platform allowing the developers to execute code in response to events without the complexity of building and maintaining the infrastructure. The 3rd party apps or services would manage the server-side logic and state.
Drawbacks of Serverless computing :
1. Problems due to third-party API system
Vendor control, multitenancy problems, vendor lock-in and security concerns are some of the problems due to the use of 3rd party APIs. Giving up system control while implementing APIs can lead to system downtime, forced API upgrades, loss of functionality, unexpected limits and cost changes.
2. Lack of operational tools
The developers are dependent on vendors for debugging and monitoring tools. Debugging Distributed Systems is difficult and usually requires access to a significant amount of relevant metrics to identify the root cause.
3. Architectural complexity
Decisions about how small (granular) the function should be, takes time to assess, implement and test. There should be a balance between the number of functions should an application call. It gets cumbersome to manage too many functions and ignoring granularity will end up creating mini-monoliths.
AWS Lambda, for now, limits you to how many concurrent executions you can be running of all your lambdas. The problem here is that this limit is across your whole AWS account. Some organizations use the same AWS account for both production and testing. That means if someone, somewhere, in your organization does a new type of load test and starts trying to execute 1000 concurrent Lambda functions you’ll accidentally Denial of service (DoS) your production applications.
4. Implementation drawbacks
Integration testing Serverless Apps is tough. The units of integration with Serverless FaaS (i.e. each function) are a lot smaller than with other architectures and therefore we rely on integration testing a lot more than we may do with other architectural styles. Problems related to deployment, versioning and packaging also exist. You may need to deploy a FaaS artifact separately for every function in your entire logical application. It also means you can’t atomically deploy a group of functions and there’s no concept of versioned applications so atomic rollback isn’t an option. You may need to turn off whatever event source is triggering the functions, deploy the whole group, and then turn the event source back on.
More details on Serverless computing, framework and pros/cons of serverless architecture are published on our blog -
