Content deleted Content added
"Standards" should not be categorized as a disadvantage. Additionally, I fact-checked and found that the mentioned Framework AE360 is not specifically about serverless computing and is a relatively obscure entity. I have also removed the text citing unreliable sources. |
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 |
||
| (13 intermediate revisions by 8 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
== 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.
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.
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>
* [[Version control|Versioning]] is simple
Line 21 ⟶ 19:
=== 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 |last1=Kelly |first1=Daniel |last2=Glavin |first2=Frank G. |last3=Barrett |first3=Enda |date=2021-08-01 |title=Denial of wallet—Defining a looming threat to serverless computing |url=https://linkinghub.elsevier.com/retrieve/pii/S221421262100079X |journal=Journal of Information Security and Applications |volume=60 |
=== Vendor lock-in ===
Line 30 ⟶ 28:
== High Performance Computing ==
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.
== 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.
These anti-patterns are often addressed through the application of clear ___domain boundaries, which distinguish between public and published interfaces.
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.
▲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 |year=2002 |title=Public versus Published Interfaces |url=https://martinfowler.com/ieeeSoftware/published.pdf |journal=IEEE Software}}</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" />
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.
▲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" />
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" />
▲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" />
== Principles ==
Adopting [[DevSecOps]] practices can help improve the use and security of serverless technologies.
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.
Ephemeral resources are typically kept together to maintain high [[Cohesion (computer science)|cohesion]]. However, shared resources with long spin-up times, such as [[AWS RDS]] clusters and landing zones, are often managed in separate repositories, [[deployment pipeline]], and stacks.
== See also ==
| |||