When it comes to building applications, developers normally have a host of other server management tasks they need to carry out in order to deploy their code, such as defining resources for processing and storage, patching, load balancing, and more. All of these extra items lead to longer provisioning times and additional operational overhead that ultimately slows down development teams. 

Serverless computing attempts to provide an invisible “serverless” experience for developers, eliminating the need to think about servers or anything an application might need to run. Instead, the service provider does all the work behind the scenes to ensure you have the resources to execute your code and meet requirements without being charged for idle capacity. 

Think of serverless like getting water to your home. You could dig your own well, test the water quality, and install and maintain all the external plumbing needed to run it into the house. Or, you can connect to your city’s main water supply. You just turn the water tap and get as much water as you want exactly when you need it, and the city sends you a monthly bill for the exact amount of water you consume. 

Similarly, cloud providers automatically spin up the infrastructure resources and runtime environments needed to execute your serverless apps and automatically scale back down to zero when the execution is complete. Typically, you are charged based on the resources during the execution time. However, this can vary depending on the service and the vendor. 

But wait, don’t other types of cloud computing provide on-demand resources on a pay-as-you-go basis? It’s true that cloud service models like Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) also provide on-demand access to computing resources. 

However, the cloud infrastructure allocated to you remains active even if you’re not using it. It’s also your responsibility to scale server capacity or configure your applications to scale up or down in response to user demand. 

Serverless architectures are event-driven. Under this model, the provider only gives you resources when an event triggers your code to run and will scale instantly and automatically to requests.

One of the biggest disadvantages of serverless computing is that it is still a relatively new technology. As a result, it is not yet suitable to meet all potential use cases. 

It’s also clear that some of the current weaknesses that exist will be solved over time as serverless computing continues to evolve. In particular, a lot of work is already being done on open source implementations of serverless and finding ways to make cloud services more open to make solutions portable across different platforms and environments. 

• Limited use case suitability: Serverless architectures are not always suitable for applications with specific requirements, such as long-running processes or very low latency needs
• Performance constraints: Serverless functions may experience cold starts (delayed initial execution) and may have limitations on execution time and memory
• Vendor lock-in: Migrating serverless applications between cloud providers can be complex due to differences in APIs and configurations
• Reduced server visibility: Developers have limited visibility into the underlying infrastructure, making it difficult to troubleshoot performance issues or optimize resource utilization
• Slow startup: Serverless functions can sometimes experience a "cold start" where there is a delay in invoking the function, which can impact latency