Function as a service
Function as a service (FaaS) is a category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure typically associated with developing and launching an app.[1] Building an application following this model is one way of achieving a "serverless" architecture, and is typically used when building microservices applications.
FaaS was initially offered by various start-ups circa 2010, such as PiCloud.[2]
AWS Lambda[3] was the first FaaS offering by a large public cloud vendor, followed by Google Cloud Functions, Microsoft Azure Functions, IBM/Apache's OpenWhisk (open source) in 2016 and Oracle Cloud Fn (open source) in 2017.
Use cases
Use cases for FaaS are associated with "on-demand" functionality that enables the supporting infrastructure to be powered down and not incur charges when not in use. Examples include data processing (e.g., batch processing, stream processing, extract-transform-load (ETL)), Internet of things (IoT) services for Internet-connected devices, mobile applications, and web applications.[4] Another real-world use case can be creating APIs for already built applications without breaking down or modifying the current or existing functionality of the application.
Anti-patterns
The "Grain of Sand Anti-pattern" refers to the creation of excessively small components (e.g., functions) within a system, often resulting in increased complexity, operational overhead, and performance inefficiencies. [5] "Lambda Pinball" is a related anti-pattern that can occur in serverless architectures when functions (e.g., AWS Lambda, Azure Functions) excessively invoke each other in fragmented chains, leading to latency, debugging and testing challenges, and reduced observability. [6] These anti-patterns are associated with the formation of a distributed monolith.
These anti-patterns are often addressed through the application of clear domain boundaries, which distinguish between public and published interfaces. [6] [7] Public interfaces are technically accessible interfaces, such as methods, classes, API endpoints, or triggers, but they do not come with formal stability guarantees. In contrast, published interfaces involve an explicit stability contract, including formal versioning, thorough documentation, a defined deprecation policy, and often support for backward compatibility. Published interfaces may also require maintaining multiple versions simultaneously and adhering to formal deprecation processes when breaking changes are introduced. [7]
Fragmented chains of function calls are often observed in systems where serverless components (functions) interact with other resources in complex patterns, sometimes described as spaghetti architecture or a distributed monolith. In contrast, systems exhibiting clearer boundaries typically organize serverless components into cohesive groups, where internal public interfaces manage inter-component communication, and published interfaces define communication across group boundaries. This distinction highlights differences in stability guarantees and maintenance commitments, contributing to reduced dependency complexity. [6] [7]
Additionally, patterns associated with excessive serverless function chaining are sometimes addressed through architectural strategies that emphasize native service integrations instead of individual functions, a concept referred to as the functionless mindset. However, this approach is noted to involve a steeper learning curve, and integration limitations may vary even within the same cloud vendor ecosystem. [8]
Portability issues
Function as a service workloads may encounter migration obstacles due to service lock-in from tight vendor integrations. Hexagonal architecture can facilitate workload portability. [9]
Comparison with PaaS application hosting services
Platform as a service (PaaS) application hosting services is similar to FaaS in that they also hide "servers" from developers. However, such hosting services typically always have at least one server process running that receives external requests. Scaling is achieved by booting up more server processes, which the developer is typically charged directly for. Consequently, scalability remains visible to the developer.[10]
By contrast, FaaS does not require any server process constantly being run. While an initial request may take longer to be handled than an application hosting platform (up to several seconds[11]), caching may enable subsequent requests to be handled within milliseconds. As developers only pay for function execution time (and no process idle time), lower costs at higher scalability can be achieved (at the cost of latency).
See also
References
- ^ Fowler, Martin (4 August 2016). "Serverless Architectures". Retrieved 26 January 2018.
- ^ "PiCloud Launches Serverless Computing Platform To The Public".
- ^ "Release: AWS Lambda on 2014-11-13". Amazon Web Service. Retrieved 26 February 2017.
- ^ "AWS Lambda – Serverless Compute - Amazon Web Services". Amazon Web Services, Inc. Retrieved 2018-05-04.
- ^ Richards, Mark (2015). Microservices AntiPatterns and Pitfalls. O'REILLY.
- ^ a b c "TECHNOLOGY RADAR VOL. 21 An opinionated guide to technology" (PDF). Technology Radar. 21. ThoughtWorks.
- ^ a b c Fowler, Martin (March/April 2002). "Public versus Published Interfaces" (PDF). IEEE SOFTWARE.
{{cite journal}}: Check date values in:|date=(help)CS1 maint: date and year (link) - ^ Brisals, Sheen. Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions. O'Reilly Media. ISBN 978-1098141936.
- ^ Cui, Yan (2020). Serverless Architectures on AWS (2nd ed.). Manning. ISBN 978-1617295423.
- ^ Avram, Abel (25 June 2016). "FaaS, PaaS, and the Benefits of the Serverless Architecture". InfoQ.
- ^ "Dealing with cold starts in AWS Lambda". 17 April 2018.
