There are some cons to take into consideration when evaluating the adoption of serverless computing:

• Possible loss of performance: If the code is not used very frequently, then latency problems may occur in its execution. These are prominent in comparison to cases in which it is in continuous execution on a server, a virtual machine, or a container. This happens because (contrary to what occurs when using autoscaling policies) with the serverless model, the cloud provider often deallocates resources completely if the code is not used. This implies that if the runtime takes some time to start, then additional latency is inevitably created in the initial start phase.
• Stateless mode: Serverless functions operate in stateless mode. This means that if you want to add logic to save some elements, such as parameters to pass as arguments to a different function, then you need to add a persistent storage component to the application flow and link the events to each other. For example, Amazon provides an additional tool called AWS Step Functions, which coordinates and manages the status of all microservices and distributed components of serverless applications.
• Limit to resources: Serverless computing is not suitable for some types of workloads or use cases, particularly with high-performance ones and for the limits on the use of resources that are imposed by the cloud provider (for example, AWS limits the number of concurrent runs of Lambda functions). These are both due to the difficulty in provisioning the number of desired servers in a limited and fixed period of time.
• Debugging and monitoring: If you rely on non-open source solutions, then the developers will depend on vendors for debugging and monitoring applications, and therefore, will not be able to diagnose any problems in detail by using additional profilers or debuggers. Thus, they will have to rely on the tools provided by their respective providers.