|
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.<ref name='techcrunch-lambda'/> It can even be more cost-efficient than provisioning an [[autoscaling|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{{spaced en dash}}; the cloud provider is responsible for ensuring that the capacity meets the demand.<ref name='techcrunch-lambda'/><ref name='techcrunch-azure'/>
=== Programming model ===
In serverless computing, the units of code exposed to the outside world are simple [[subroutine|functions]]{{spaced. en dash}} forFor 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 structure]]s at the option of the programmer. This means that typically, the programmer does not have to worry about [[multithreading (software)|multithreading]] or directly handling [[HTTP]] requests in their code, simplifying the task of back-end software development.
== Disadvantages ==
=== Performance ===
Infrequently-used serverless code may suffer from greater response [[latency (engineering)|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 in use{{spaced en dash}} (for example, the [[Java (programming language)|Java]] runtime,) in the case of Java code{{spaced en dash}}use requires a significant amount of time to start up, thatwhich will introduce latency into the request handling the next time a request is made to that piece of code. However, not all code is latency-sensitive -; for example, [[batch processing]] operations run by [[cron job]]s might not be significantly affected by small, infrequent latencies such as this.
==== Resource limits ====
=== Monitoring and debugging ===
Diagnosing performance or excessive resource usage problems with serverless code may be more challengingdifficult than with traditional server code, because although entire functions can be timed,<ref name='lambda-api-gateway'>{{cite web|url=http://www.forbes.com/sites/janakirammsv/2015/07/16/paas-vendors-watch-out-amazon-is-all-set-to-disrupt-the-market/|title=PaaS Vendors, Watch Out! Amazon Is All Set To Disrupt the Market|last=MSV|first=Janakiram|date=16 July 2015|accessdate=10 July 2016}}</ref> there is typically no ability to dig into more detail andby attachattaching [[profiling (computer programming)|profilers]], [[debugger]]s or [[Application Performance Management|APM]] tools. - andFurthermore, the environment in which the code runs is typically not [[open source]], so its performance characteristics cannot be precisely replicated in a [[Deployment environment#Development|local environment]]. However, Amazon plans to provide AWS Lambda support in its APM and tracing technology called ''AWS X-Ray''.<ref>{{cite web|url=https://aws.amazon.com/blogs/aws/aws-x-ray-see-inside-of-your-distributed-application/|title=AWS X-Ray - See Inside of Your Distributed Application|date=1 Dec 2016|accessdate=6 Dec 2016|last=Barr|first=Jeff|publisher=Amazon.com}}</ref>
== See also ==
|
