Serverless main benefits:
- Reduced time to market and quicker software release.
- Lower operational and development costs.
- A smaller cost to scale – there is no need for developers to implement code to scale and administrators do not need to upgrade existing servers or add additional ones.
- Works with agile development and allows developers to focus on code and to deliver faster.
- Fits with microservices, which can be implemented as functions.
- Reduces the complexity of software.
- Simplifies packaging and deployment and requires no system administration.
Drawback fo Serverless:
- Serverless is not efficient for long-running applications. In certain cases, using long tasks can be much more expensive than, for example, running a workload on a dedicated server or virtual machine.
- Vendor lock-in. Your application is completely dependent on a third-party provider. You do not have a full control of your application. Most likely, you cannot change your platform or provider without making significant changes to your application. Also, you are dependent on platform availability, and the platform’s API and costs can change. Needles to say, the existing FaaS implementations are not compatible with each other.
- Serverless (and microservice) architectures introduce additional overhead for function/microservice calls. There are no “local” operations; you cannot assume that two communicating functions are located on the same server.
- To utilize its resources more efficiently, a service provider may run software for several different customers on the same physical server (this is also known as “multitenancy”). Even if customers’ workloads are isolated in virtual machines or containers, there can be different bugs in the early stages of FaaS offerings. This can be a major security issue for your application if you work with sensitive data. Such potential bugs in a platform or failures in one customer’s code (a “noisy neighbor”) can affect the performance or availability of your application.
- In practice, it takes some time for a scalable serverless platform to handle a first request by your function. This problem is know as “cold start”—a platform needs to initialize internal resources (AWS Lambda, for example, needs to start a container). The platform may also release such resources (such as stopping the container) if there have been no requests to your function for a long time. One option to avoid the cold start is to make sure your function remains in an active state by sending periodic requests to your function.
- Some FaaS implementations—such as AWS Lambda—do not provide out-of-the-box tools to test functions locally (assuming that a developer will use the same cloud for testing). This is not an ideal decision, especially considering that you will pay for each function invocation. As a result, several third-party solutions are trying to fill this gap, enabling you to test functions locally.
- Different FaaS implementations provide different methods for logging in functions. For example, AWS Lambda allows writing logs to AWS CloudWatch using the standard frameworks for the specific language (Log4j for Java, console methods for Node.js, logging module for Python). It is completely up to the developer how to implement more advanced logging.
Feel free to contact E-SPIN for server less PaaS infrastructure, availability monitoring and security management.