Content deleted Content added
m v2.05b - Bot T21 CW#557 - Fix errors for CW project (Missing whitespace before a link) |
Citation bot (talk | contribs) Add: doi, pages, issue, volume, date, article-number, publisher, authors 1-2. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 411/967 |
||
| (31 intermediate revisions by 13 users not shown) | |||
Line 1:
{{Short description|Cloud computing model}}
'''Serverless computing''' is "a cloud service category in which the customer can use different cloud capability types without the customer having to provision, deploy and manage either hardware or software resources, other than providing customer application code or providing customer data. Serverless computing represents a form of virtualized computing." according to [[International Organization for Standardization|ISO]]/IEC 22123-2.<ref name=":1">{{Cite journal |title=ISO/IEC 22123-2:2023 (E) - Information technology — Cloud computing — Part 2: Concepts |journal=International Standard |pages=25}}</ref> Serverless computing is a broad ecosystem that includes the cloud provider, [[Function as a service|Function as a Service]] (FaaS), managed services, tools, frameworks, engineers, stakeholders, and other interconnected elements, according to Sheen Brisals.<ref name=":2">{{Cite book |last=Brisals |first=Sheen |title=Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions |publisher=O'Reilly Media |isbn=978-1098141936}}</ref>
== Overview ==
''Serverless'' is a [[misnomer]] in the sense that servers are still used by cloud service providers to execute code for [[Developer (software)|developers]]. The definition of serverless computing has evolved over time, leading to varied interpretations. According to Ben Kehoe, serverless represents a spectrum rather than a rigid definition. Emphasis should shift from strict definitions and specific technologies to adopting a serverless mindset, focusing on leveraging serverless solutions to address business challenges.<ref>{{Cite book |last1=Emison |first1=Joseph |title=Serverless as a Game Changer How to Get the Most Out of the Cloud |year=2023 |publisher=Addison-Wesley Professional |isbn=9780137392551}}</ref>
Serverless computing does not eliminate complexity but shifts much of it from the operations team to the development team. However, this shift is not absolute, as operations teams continue to manage aspects such as identity and access management (IAM), networking, security policies, and cost optimization. Additionally, while breaking down applications into finer-grained components can increase management complexity, the relationship between granularity and management difficulty is not strictly linear. There is often an optimal level of modularization where the benefits outweigh the added management overhead.<ref>{{Cite book |title=The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise |publisher=O'Reilly Media |year=2020 |isbn=978-1492077541}}</ref><ref name=":2" />
According to Yan Cui, serverless should be adopted only when it helps to deliver customer value faster. And while adopting, organizations should take small steps and de-risk along the way.<ref name=":0">{{Cite book |last=Cui |first=Yan |title=Serverless Architectures on AWS |publisher=Manning |year=2020 |isbn=978-1617295423 |edition=2nd}}</ref>
==
Serverless applications are prone to [[fallacies of distributed computing]]. In addition, they are prone to the following fallacies:<ref>{{Cite book |last=Richards |first=Mark |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |date=March 3, 2020 |isbn=978-1492043454 |edition=1st}}</ref><ref>{{Cite book |last=Richards |first=Mark |title=Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures |publisher=O'Reilly Media |year=2021 |isbn=978-1492086895 |edition=1st}}</ref>▼
▲Serverless applications are prone to [[fallacies of distributed computing]]. In addition, they are prone to following fallacies:<ref>{{Cite book |last=Richards |first=Mark |title=Fundamentals of Software Architecture: An Engineering Approach |publisher=O'Reilly Media |date=March 3, 2020 |isbn=978-1492043454 |edition=1st}}</ref><ref>{{Cite book |last=Richards |first=Mark |title=Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures |publisher=O'Reilly Media |year=2021 |isbn=978-1492086895 |edition=1st}}</ref>
* [[Version control|Versioning]] is simple
* [[Compensating transaction]]s always work
* [[Observability (software)|Observability]] is optional
=== Performance ===▼
=== Monitoring and debugging ===
Monitoring and debugging serverless applications can present unique challenges due to their distributed, event-driven nature and proprietary environments. Traditional tools may fall short, making it difficult to track execution flows across services. However, modern solutions such as distributed tracing tools (e.g., AWS X-Ray, Datadog), centralized logging, and cloud-agnostic observability platforms are mitigating these challenges. Emerging technologies like OpenTelemetry, AI-powered anomaly detection, and serverless-specific frameworks are further improving visibility and root cause analysis. While challenges persist, advancements in monitoring and debugging tools are steadily addressing these limitations.<ref>{{Cite book |title=Distributed Tracing in Practice: Instrumenting, Analyzing, and Debugging Microservice |publisher=O'Reilly Media |isbn=978-1492056638}}</ref><ref>{{Cite book |title=Cloud-Native Observability with OpenTelemetry: Learn to gain visibility into systems by combining tracing, metrics, and logging with OpenTelemetry |isbn=978-1801077705}}</ref>
=== Security ===
According to [[OWASP]], serverless applications are vulnerable to variations of traditional attacks, insecure code, and some serverless-specific attacks (like Denial of Wallet<ref>{{Cite journal |
=== Vendor lock-in ===▼
Serverless computing is provided as a third-party service. Applications and software that run in the serverless environment are by default locked to a specific cloud vendor. This issue is exacerbated in serverless computing, as with its increased level of abstraction, public vendors only allow customers to upload code to a FaaS platform without the authority to configure underlying environments. More importantly, when considering a more complex workflow that includes Backend-as-a-Service (BaaS), a BaaS offering can typically only natively trigger a FaaS offering from the same provider. This makes the workload migration in serverless computing virtually impossible. Therefore, considering how to design and deploy serverless workflows from a [[multi-cloud]] perspective seems promising and is starting to prevail{{When|date=June 2024}}.<ref>{{Cite book |last1=Aske |first1=Austin |last2=Zhao |first2=Xinghui |title=Proceedings of the 47th International Conference on Parallel Processing Companion |chapter=Supporting Multi-Provider Serverless Computing on the Edge |date=2018-08-13 |chapter-url=https://doi.org/10.1145/3229710.3229742 |series=ICPP Workshops '18 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1–6 |doi=10.1145/3229710.3229742 |isbn=978-1-4503-6523-9|s2cid=195348799 }}</ref><ref>{{Cite book |last1=Baarzi |first1=Ataollah Fatahi |last2=Kesidis |first2=George |last3=Joe-Wong |first3=Carlee |last4=Shahrad |first4=Mohammad |title=Proceedings of the ACM Symposium on Cloud Computing |chapter=On Merits and Viability of Multi-Cloud Serverless |date=2021-11-01 |chapter-url=https://doi.org/10.1145/3472883.3487002 |series=SoCC '21 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=600–608 |doi=10.1145/3472883.3487002 |isbn=978-1-4503-8638-8|s2cid=239890130 }}</ref><ref>{{Cite book |last1=Zhao |first1=Haidong |last2=Benomar |first2=Zakaria |last3=Pfandzelter |first3=Tobias |last4=Georgantas |first4=Nikolaos |title=2022 IEEE/ACM 15th International Conference on Utility and Cloud Computing (UCC) |chapter=Supporting Multi-Cloud in Serverless Computing |date=2022-12-06 |chapter-url=https://ieeexplore.ieee.org/document/10061782/references#references |pages=285–290 |doi=10.1109/UCC56403.2022.00051|arxiv=2209.09367 |isbn=978-1-6654-6087-3 |s2cid=252383217 }}</ref>▼
Serverless computing may not be ideal for certain [[high-performance computing]] (HPC) workloads due to resource limits often imposed by cloud providers, including maximum memory, CPU, and runtime restrictions. For workloads requiring sustained or predictable resource usage, bulk-provisioned servers can sometimes be more cost-effective than the pay-per-use model typical of serverless platforms. However, serverless computing is increasingly capable of supporting specific HPC workloads, particularly those that are highly parallelizable and event-driven, by leveraging its scalability and elasticity. The suitability of serverless computing for HPC continues to evolve with advancements in cloud technologies.<ref>{{Cite book |title=Serverless Computing: Principles and Paradigms |date=12 May 2023 |publisher=Springer |isbn=978-3031266324}}</ref><ref>{{Cite book |last1=Foster |first1=Ian |last2=Gannon |first2=Dennis B. |title=Cloud Computing for Science and Engineering (Scientific and Engineering Computation) |date=29 September 2017 |publisher=MIT Press |isbn=978-0262037242}}</ref><ref name="hellersteinFaleiro2019">{{Citation|last1=Hellerstein |first1=Joseph |last2=Faleiro |first2=Jose |last3=Gonzalez |first3=Joseph |last4=Schleier-Smith |first4=Johann |last5=Screekanti |first5=Vikram |last6=Tumanov |first6=Alexey |last7=Wu |first7=Chenggang |year=2019 |title=Serverless Computing: One Step Forward, Two Steps Back |arxiv=1812.03651}}</ref>
==
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.<ref name=":5">{{Cite book |last=Richards |first=Mark |title=Microservices AntiPatterns and Pitfalls |date=2015 |publisher=O'REILLY |publication-date=2015}}</ref> "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.<ref name=":3">{{Cite journal |title=TECHNOLOGY RADAR VOL. 21 An opinionated guide to technology |url=https://www.thoughtworks.com/content/dam/thoughtworks/documents/radar/2019/11/tr_technology_radar_vol_21_en.pdf |journal=Technology Radar |publisher=ThoughtWorks |volume=21}}</ref> 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.<ref name=":3" /><ref name=":4">{{Cite journal |last=Fowler |first=Martin |date=March–April 2002 |title=Public versus Published Interfaces |url=https://martinfowler.com/ieeeSoftware/published.pdf |journal=IEEE Software |volume=19 |issue=2 |pages=18–19 |doi=10.1109/52.991326 }}</ref> 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.<ref name=":4" />
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.<ref name=":3" /><ref name=":4" />
▲=== Vendor lock-in ===
▲Serverless computing is provided as a third-party service. Applications and software that run in the serverless environment are by default locked to a specific cloud vendor. This issue is exacerbated in serverless computing, as with its increased level of abstraction, public vendors only allow customers to upload code to a FaaS platform without the authority to configure underlying environments. More importantly, when considering a more complex workflow that includes Backend-as-a-Service (BaaS), a BaaS offering can typically only natively trigger a FaaS offering from the same provider. This makes the workload migration in serverless computing virtually impossible. Therefore, considering how to design and deploy serverless workflows from a [[multi-cloud]] perspective seems promising and is starting to prevail{{When|date=June 2024}}.<ref>{{Cite book |last1=Aske |first1=Austin |last2=Zhao |first2=Xinghui |title=Proceedings of the 47th International Conference on Parallel Processing Companion |chapter=Supporting Multi-Provider Serverless Computing on the Edge |date=2018-08-13 |chapter-url=https://doi.org/10.1145/3229710.3229742 |series=ICPP Workshops '18 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=1–6 |doi=10.1145/3229710.3229742 |isbn=978-1-4503-6523-9|s2cid=195348799 }}</ref><ref>{{Cite book |last1=Baarzi |first1=Ataollah Fatahi |last2=Kesidis |first2=George |last3=Joe-Wong |first3=Carlee |last4=Shahrad |first4=Mohammad |title=Proceedings of the ACM Symposium on Cloud Computing |chapter=On Merits and Viability of Multi-Cloud Serverless |date=2021-11-01 |chapter-url=https://doi.org/10.1145/3472883.3487002 |series=SoCC '21 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=600–608 |doi=10.1145/3472883.3487002 |isbn=978-1-4503-8638-8|s2cid=239890130 }}</ref><ref>{{Cite book |last1=Zhao |first1=Haidong |last2=Benomar |first2=Zakaria |last3=Pfandzelter |first3=Tobias |last4=Georgantas |first4=Nikolaos |title=2022 IEEE/ACM 15th International Conference on Utility and Cloud Computing (UCC) |chapter=Supporting Multi-Cloud in Serverless Computing |date=2022-12-06 |chapter-url=https://ieeexplore.ieee.org/document/10061782/references#references |pages=285–290 |doi=10.1109/UCC56403.2022.00051|arxiv=2209.09367 |isbn=978-1-6654-6087-3 |s2cid=252383217 }}</ref>
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.<ref name=":2" />
Reporting on serverless databases presents challenges, as retrieving data for a reporting service can either break the [[Domain-driven design|bounded contexts]], reduce the timeliness of the data, or do both. This applies regardless of whether data is pulled directly from databases, retrieved via HTTP, or collected in batches. Mark Richards refers to this as the "''Reach-in Reporting Antipattern"''.<ref name=":5" /> A possible alternative to this approach is for databases to asynchronously push the necessary data to the reporting service instead of the reporting service pulling it. While this method requires a separate contract between services and the reporting service and can be complex to implement, it helps preserve bounded contexts while maintaining a high level of data timeliness.<ref name=":5" />
== Principles ==
According to Yan Cui, ephemeral resources should be kept together to achieve a high [[Cohesion (computer science)|cohesion]]. However, shared resources that have a long spin-up time (e.g. [[AWS RDS]] cluster) and landing zone should have their own separate [[Repository (version control)|repository]], [[deployment pipeline]] and stack. <ref name=":0" />▼
Adopting [[DevSecOps]] practices can help improve the use and security of serverless technologies.<ref>{{Cite book |last=Katzer |first=Jason |title=Learning Serverless: Design, Develop, and Deploy with Confidence |publisher=O'Reilly Media |year=2020 |isbn=978-1492057017}}</ref>
In serverless applications, the distinction between infrastructure and business logic is often blurred, with applications typically distributed across multiple services. To maximize the effectiveness of testing, integration testing is emphasized for serverless applications.<ref name=":0" /> Additionally, to facilitate debugging and implementation, [[Orchestration (computing)|orchestration]] is used within the [[Domain-driven design|bounded context]], while [[Service choreography|choreography]] is employed between different bounded contexts.<ref name=":0" />
▲
== See also ==
| |||