In the previous blog you came across the benefits of Serverless architecture. However, one should realize the challenges/drawbacks that Serverless could bring in and hence the architecture is not ideal for all use cases. It is ideal for specific use cases on which I shall provide more details in the next article.
Here are some of the drawbacks of going Serverless:
Vendor lock-in
Serverless applications that you write depends on auto-provisioning and management of infrastructural needs by the cloud service providers, thereby leading to dependency on almost everything such as platform needed to develop, test, and deploy, non-functional needs such as monitoring, logging, scaling, portability and others. However, framework such as serverless.com is making an attempt to address the portability concerns between the providers.
Lack of Standardization
Despite so many vendors in the Serverless market, there has been no attempt made in the creation of Standards around the architecture.
Cold Startup Time
Any Serverless platform need some time to serve the first request. This problem is called as cold-start. For e.g., platform running functions that are written in Java, requires some time to start the JVM before it can start serving the request. This is the reason why Serverless is not ideal for long running applications.
Architecture Complexity
Complexity with Serverless grows when you start adding FaaS or BaaS that brings in additional overhead of defining the communication patterns and network calls between them. This communication overhead is neither local nor in-process but remote, and platforms doesn’t guarantee that all your functions are running on the same server.
Debugging, Logging and Monitoring
With no control on the underlying Server, you have to rely on the built-in logging and monitoring capabilities of the providers. With less or almost nil customization, debugging and troubleshooting techniques could be time consuming and less efficient.
Providers have their own built-in logging mechanism, for e.g., AWS Lambda uses AWS CloudWatch for writing logs using the standard logging frameworks that specific languages has (log4j for Java). Similarly, built-in monitoring capabilities are provided by providers.
Integration Testing of disparate Serverless functions
Unit testing is not an issue, however the integrating testing of various functions in use is an issue.
Library Duplication for each function
You have to package all required libraries into the function, leading to bulkier functions and time consuming build process.
Access to Infrastructure
Limited access to file system, and other hardware resources