!!! Overview [1][2]
[{$pagename}] is an [Event-triggered], [ephemeral] and [stateless] [cloud]-based [architecture] that dynamically allocates machine [resources]. [{$pagename}] uses servers; they are just not yours.

[{$pagename}] is an [Architecture] and there’s no one clear view of what ‘[{$pagename}]’ is, and that isn't helped by it really coming to mean two different but overlapping areas:

* [{$pagename}] was first used to describe [applications] that significantly or fully depend on [third-party] [applications] / services ("in the [cloud|Cloud computing]") to manage server-side logic and [state]. These are typically "rich [client]" [applications] (think single page web apps, or mobile apps) that use the vast ecosystem of [cloud computing] accessible [databases] (like Parse, Firebase), [authentication] services ([Auth0], [AWS Cognito]), etc. These types of services have been previously described as ‘(Mobile) [Backend as a Service]’, and we will be using ‘[BaaS]’ as a shorthand.
* [{$pagename}] can also mean [applications] where some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in [stateless] [Containers] that are [event-triggered], ephemeral (may only last for one invocation), and fully managed by a [Third-party]. (Thanks to ThoughtWorks for their definition in their most recent [Tech Radar|https://www.thoughtworks.com/radar/techniques/serverless-architecture|target='_blank'].) 

Both of these imply [Cloud computing] and remember the real definition of [Cloud computing] is: "Other people's computers"

One way to think of this is [Functions as a Service] ([FaaS])'.

!! Why Serverless? 
When developing an [application], your prime goal is to focus on the problem you are trying to solve. Ultimately, it means that all work you need to do that is not directly linked to your goal needs to be minimized or, better, eliminated.

If there is a surge in the usage of your [app], ideally it shouldn’t make any difference to your users. In reality, though, they might expect slowness, a drop in responsiveness and even no service at all if your [server] crashes. In order to prevent scenarios like this, you need to invest in good infrastructure. Unfortunately, maintaining such a robust infrastructure is time-consuming and expensive.

Some aspects of [{$pagename}] for this dilemma:
* Scales out-of-the-box ([Elasticity])
* [Payment] based on usage
* [Cloud Service Provider] lock-ins vs [employee] lock-ins - The main problem is that changing personnel is way more difficult than changing a cloud provider. So if you decide to switch technologies or are not satisfied with the current status of your company’s infrastructure, you will likely have a hard time. However, by adopting a serverless strategy, if you ever need to change providers you can expect a less painful experience.
* [Development Team] experience - It goes without saying that developers… well, like to develop. If you take from them the responsibility to overlook the infrastructure, they will get more productive by keeping their eyes on the end goal, i.e., creating an awesome app. A stressful working environment can kill devs productivity and actual care for their well being will bring you collateral improvements.

[{$pagename}] makes sense when:
* You need Little control over your server
* Short computations - [Functions as a Service] are [Event-triggered], which means that they are called when something happens (for example, when a user is created). [{$pagename}] providers will set a maximum time limit your function can run to avoid that a single call drains all machine’s memory.  If your [application] performs long and expensive computations, going serverless may be a problem for you.
* Small throughput - One advantage of [{$pagename}] is that you are billed per function request and not by uptime (like traditional [Virtual Machine]). [{$pagename}] May not be well suited for applications with too many requests per second.
* No data persistence - [{$pagename}] is [Stateless] computing. Do not count on any [DataStore]. You may be able to read data from an [API]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Serverless Architectures|http://martinfowler.com/articles/serverless.html|target='_blank'] - based on information obtained 2016-10-13
* [#2] - [The Comprehensive Guide to Serverless Architecture|https://www.simform.com/serverless-architecture-guide/|target='_blank'] - based on information obtained 2017-12-15