Serverless computing, also known as function as a service (FaaS), is a cloud computing code execution model in which the cloud provider fully manages starting and stopping of a function's container platform as a service (PaaS) as necessary to serve requests, and requests are billed by an abstract measure of the resources required to satisfy the request, rather than per virtual machine, per hour.

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.

Serverless code can either be triggered by specific events (such as user registration with Amazon Cognito), or be configured to run behind an API management platform in order to expose it as a REST API endpoint.
The first 'pay as you go' code execution platform where developers simply wrote code online including billing at a functional level, creation of virtual resources by the system as needed, exposure of functions as APIs was Zimki in 2006. AWS Lambda, introduced by Amazon in November 2014, was the first major provider considered to have a serverless offering. AWS Lambda initially launched with Node.js as the only runtime,but as of 2016 it now officially supports Python, Java, C# and other languages such as Haskell can also be used by using Node.js as an invoker.

Google has released an alpha version of its serverless platform, which is called Google Cloud Functions, and supports Node.js.
IBM announced OpenWhisk as an open source serverless platform of its own at InterConnect 2016. In addition to supporting functions as a service, OpenWhisk offers features that include user-defined triggers, function execution rules, function composition via sequences, and a model for sharing assets via packages. OpenWhisk may be hosted on premise or hosted as a service as is the case with IBM Bluemix OpenWhisk; the source code is available on GitHub.At launch, OpenWhisk included support for Node.js and Swift, as well as black box functions (in any language or runtime) via Docker containers. It now officially also includes support for Python and Java as well.

Microsoft followed up in 2016 by announcing Azure Functions, a technology usable in both the Azure public cloud and on any other cloud environment, public or private. Azure functions have been generally available for production use since November 2016.

Serverless computing can be more cost-efficient just in terms of computing resources, than renting or purchasing a fixed quantity of servers, which generally involves periods of underutilisation or non-use. It can even be more cost-efficient than provisioning an autoscaling group, because even autoscaling groups are typically designed to have underutilisation to allow time for new instances to start up.
In addition, a serverless architecture means that developers and operations specialists do not need to spend time setting up and tuning autoscaling policies or systems; the cloud provider is responsible for ensuring that the capacity meets the demand.

In serverless computing, the units of code exposed to the outside world are simple functions. For example, in AWS Lambda, they are essentially functions that both consume and produce JSON, although they can make calls to other APIs, and the JSON may be automatically serialized from and deserialized to data structures at the option of the programmer. This means that typically, the programmer does not have to worry about multithreading or directly handling HTTP requests in their code, simplifying the task of back-end software development.

Infrequently-used serverless code may suffer from greater response latency than code that is continuously running on a dedicated server, virtual machine, or container. This is because, unlike with an autoscaling, the cloud provider typically "spins down" the serverless code completely when not in use. This means that if the runtime (for example, the Java runtime) in use requires a significant amount of time to start up, that will introduce latency into request handling. However, not all code is latency-sensitive; for example, batch processing operations run by cron jobs might not be significantly affected by small, infrequent latencies such as this.