Hubbry Logo
Serverless computingServerless computingMain
Open search
Serverless computing
Community hub
Serverless computing
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Serverless computing
Serverless computing
Serverless computing
View on Wikipedia
from Wikipedia

Serverless computing is "a cloud service category where 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 ISO/IEC 22123-2.[1] Serverless computing is a broad ecosystem that includes the cloud provider, Function as a Service (FaaS), managed services, tools, frameworks, engineers, stakeholders, and other interconnected elements, according to Sheen Brisals.[2]

Overview

[edit]

Serverless is a misnomer in the sense that servers are still used by cloud service providers to execute code for 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.[3]

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.[4][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.[5]

Challenges

[edit]

Serverless applications are prone to fallacies of distributed computing. In addition, they are prone to the following fallacies:[6][7]

Monitoring and debugging

[edit]

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.[8][9]

Security

[edit]

According to OWASP, serverless applications are vulnerable to variations of traditional attacks, insecure code, and some serverless-specific attacks (like Denial of Wallet[10]). So, the risks have changed and attack prevention requires a shift in mindset.[11][12]

Vendor lock-in

[edit]

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 could mitigate this.[13][14][15]

High Performance Computing

[edit]

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.[16][17][18]

Anti-patterns

[edit]

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.[19] "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.[20] 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.[20][21] 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.[21]

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.[20][21]

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.[2]

Reporting on serverless databases presents challenges, as retrieving data for a reporting service can either break the 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".[19] 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.[19]

Principles

[edit]

Adopting DevSecOps practices can help improve the use and security of serverless technologies.[22]

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.[5] Additionally, to facilitate debugging and implementation, orchestration is used within the bounded context, while choreography is employed between different bounded contexts.[5]

Ephemeral resources are typically kept together to maintain high 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.[5]

See also

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Serverless computing

View on Grokipedia
from Grokipedia
Serverless computing is a execution model in which providers dynamically manage the allocation, provisioning, and scaling of compute resources, enabling developers to build and run applications and services without the need to manage underlying servers or . This approach abstracts away operational complexities such as server maintenance, , and elasticity, allowing developers to focus solely on writing code while the provider handles resource optimization and billing based on actual usage, typically measured in compute time, , and storage. Unlike traditional infrastructure-as-a-service (IaaS) or platform-as-a-service (PaaS) models, serverless is inherently event-driven, allocating resources only when triggered by specific events like requests or database changes, and scaling automatically to zero during idle periods. The concept of serverless computing emerged in the early as an evolution from earlier paradigms like in mainframes (1960s), (1990s), and general (2000s), addressing the limitations of manual server provisioning and high operational costs in dynamic workloads. A pivotal milestone was the 2014 launch of , the first widely adopted (FaaS) platform, which popularized the term "serverless" despite the presence of servers managed entirely by the provider. Since then, major cloud providers like Google Cloud and have introduced comparable offerings, such as Cloud Functions and Azure Functions, fostering widespread adoption for , APIs, and event-driven architectures. By 2023, serverless had become a core component of modern cloud ecosystems, supporting diverse applications from web backends to pipelines. At its core, serverless computing encompasses two primary models: , where developers deploy discrete functions that execute in response to events, and , which provides managed backend services like databases, authentication, and storage via APIs. Functions are typically stateless, short-lived, and executed in isolated environments, with providers ensuring and through multi-tenancy isolation. Key benefits include enhanced developer productivity by eliminating , cost efficiency through pay-per-use pricing that avoids charges for idle resources, and seamless to handle variable loads without over-provisioning. Notable use cases span real-time data processing, such as analyzing data in hours rather than weeks, and rapid . Despite its advantages, serverless computing faces challenges including cold-start latencies—delays in initializing functions for the first time—which can impact performance for latency-sensitive applications, as well as security concerns related to shared isolation. and limitations in supporting long-running or stateful workloads also persist, prompting ongoing research into hybrid models and optimizations for emerging fields like artificial intelligence and . As of 2025, serverless continues to evolve, with projections indicating its role in enabling more agile, efficient cloud-native development across industries.

Introduction

Definition and Core Concepts

Serverless computing is a cloud-native development model in which cloud providers dynamically manage the allocation and provisioning of servers, enabling developers to build and deploy applications without handling underlying infrastructure tasks. In this paradigm, developers focus exclusively on writing code, while the provider assumes responsibility for operating systems, server maintenance, patching, and scaling. This abstraction allows for the creation of event-driven applications that respond to triggers such as HTTP requests or database changes, without the need for persistent server instances. At its core, serverless computing relies on three primary abstractions: pay-per-use billing, automatic scaling, and the elimination of server provisioning and maintenance. Under the pay-per-use model, users are charged only for the compute resources—such as and —actually consumed during execution, with no costs incurred for idle periods. Automatic scaling ensures that resources expand or contract instantaneously based on demand, handling everything from zero to thousands of concurrent invocations seamlessly. By removing the need for developers to provision or maintain servers, this model shifts operational burdens to the cloud provider, fostering greater developer productivity and application agility. Serverless computing differs markedly from other cloud paradigms like (IaaS) and (PaaS). IaaS provides virtualized servers and storage that users must configure and manage, while PaaS offers a managed platform for running applications continuously but still requires oversight of runtime environments and scaling policies. In contrast, serverless extends this abstraction further by eliminating even the platform layer, executing code only on-demand without persistent . Importantly, the term "serverless" does not imply the absence of servers but rather the absence of server management by the developer; servers still exist and are operated entirely by the cloud provider behind the scenes. This nomenclature highlights the model's emphasis on invisibility of infrastructure, allowing developers to prioritize logic and business value over operational concerns.

History and Evolution

The origins of serverless computing are intertwined with the advent of modern cloud infrastructure, beginning with the launch of (AWS) in March 2006, which introduced scalable, on-demand computing resources and pioneered the shift away from traditional server management. This foundational development enabled subsequent abstractions in compute delivery, setting the stage for event-driven execution models that would define serverless paradigms. A pivotal occurred in November 2014 when AWS unveiled Amazon Lambda at its re:Invent conference, introducing the first widely adopted (FaaS) platform that allowed developers to execute code in response to events without provisioning servers. Lambda's pay-per-use model and seamless integration with other AWS services quickly demonstrated the viability of serverless for real-world applications, sparking industry interest in abstracted compute. The mid-2010s saw rapid proliferation as competitors followed suit. Microsoft announced the general availability of Azure Functions in November 2016, extending serverless capabilities to its ecosystem with support for multiple languages and triggers. Google Cloud Functions entered beta in March 2017, focusing on lightweight, event-driven functions integrated with Google services like Pub/Sub. Concurrently, open-source efforts emerged to democratize serverless beyond proprietary clouds; OpenFaaS, initiated in 2016, provided a framework for deploying functions on Kubernetes and other platforms, emphasizing portability. By 2018, the ecosystem matured further with Google's announcement of Knative, a Kubernetes-based project that standardized serverless workloads for container orchestration, facilitating easier deployment across environments. Key announcements at events like AWS re:Invent continued to drive innovation, including expansions such as Lambda@Edge in 2017, which brought serverless execution to content delivery networks for low-latency edge processing. Entering the , serverless computing evolved toward multi-cloud compatibility and edge deployments, enabled by tools like Knative for hybrid environments and growing support for distributed execution. Adoption transitioned from niche use in architectures to mainstream integration by 2023, with organizations across AWS, Azure, and Google Cloud reporting 3-7% year-over-year growth in serverless workloads. As of 2025, serverless adoption has accelerated, particularly in enterprise workloads and integrations with and , with the global market projected to reach USD 52.13 billion by 2030 growing at a (CAGR) of 14.1% from 2025. In October 2025, Knative achieved graduated status within the (CNCF), underscoring its maturity for production use in serverless and event-driven applications.

Architecture and Execution Model

Function as a Service (FaaS)

(FaaS) represents the core compute paradigm within serverless computing, enabling developers to deploy and execute individual units of code, known as functions, in response to specific triggers without provisioning or managing underlying servers. In this model, developers upload code snippets that are invoked by events such as HTTP requests, database changes, or entries, with the cloud provider handling the provisioning of runtime environments on demand. This event-driven approach abstracts away concerns, allowing functions to scale automatically based on incoming requests. The mechanics of FaaS involve packaging application logic into discrete, stateless functions that are triggered asynchronously or synchronously. For instance, an HTTP-triggered function might process API calls, while a queue-triggered one handles background tasks from services like Amazon SQS. Upon invocation, the platform dynamically allocates a containerized runtime environment tailored to the function's and dependencies, executing the code in isolation before tearing it down to free resources. This on-demand provisioning ensures that functions only consume resources during active execution, typically lasting from milliseconds to a few minutes, promoting efficient utilization in variable workloads. The execution lifecycle of a FaaS function encompasses three primary phases: invocation, execution, and teardown. Invocation occurs when an event matches the function's trigger configuration, queuing the request for ; the platform then initializes or reuses a warm instance if available. During execution, the function runs within allocated compute resources, with durations constrained to prevent indefinite resource holds— for example, up to 15 minutes in . Teardown follows completion, where the runtime environment is terminated or idled, releasing and CPU; this ephemerality ensures , requiring functions to avoid in-memory state persistence. Concurrency models govern parallel executions, such as 's default limit of 1,000 concurrent executions per region across all functions, which can be adjusted via reserved or provisioned concurrency to manage throttling. Major cloud providers implement FaaS with tailored features to support diverse development needs. AWS Lambda, a pioneering service, supports languages including , Python, , and , with configurable memory from 128 MB to 10,240 MB and a maximum execution timeout of 15 minutes. Google Cloud Functions (2nd generation) accommodates , Python, Go, , , PHP, and .NET, offering up to 32 GiB of memory per function and timeouts of up to 60 minutes for both HTTP and event-driven invocations. Azure Functions provides support for C#, , Python, , , and , with memory limits up to 1.5 GB on the Consumption plan and execution timeouts extending to 10 minutes. These providers emphasize polyglot runtimes and adjustable resource allocations to optimize for short-lived, event-responsive workloads. To compose complex workflows from individual FaaS functions, orchestration tools like AWS Step Functions enable stateful coordination, defining sequences, parallels, or conditionals across invocations while handling retries and errors. This integration allows developers to build resilient, multi-step applications, such as order processing pipelines, by visually modeling state machines that invoke functions as needed.

Backend as a Service (BaaS) and Integration

(BaaS) refers to a model that provides fully managed backend infrastructure and services, allowing developers to build applications without writing or maintaining custom server-side code. In serverless computing, BaaS acts as a complementary layer to (FaaS) by offering pre-built, scalable services accessible via APIs, such as databases, storage, and user management tools. This approach enables developers to focus on frontend logic and application features while the provider handles scalability, security, and operational overhead. Prominent examples include Google Firebase, which integrates authentication and real-time databases, and (AWS) Cognito for identity management. Key components of BaaS in serverless architectures include managed databases, mechanisms, and tools. Managed databases like provide storage with automatic scaling and , supporting key-value and data models without the need for or server provisioning. services, such as those using and JSON Web Tokens (JWT), are handled by platforms like AWS Cognito or , which manage user sign-up, sign-in, and through secure token issuance and validation. API gateways, exemplified by AWS API Gateway, facilitate the creation, deployment, and monitoring of RESTful or HTTP APIs, integrating seamlessly with other backend services to route requests and enforce policies like throttling and authorization. Integration patterns in BaaS often involve chaining FaaS functions with BaaS components through event triggers, enabling responsive and loosely coupled architectures. For instance, an function (FaaS) can be triggered by changes in a DynamoDB table (BaaS), processing updates and propagating them to other services like notification systems. Serverless APIs frequently leverage resolvers, as seen in AWS AppSync, where resolvers map GraphQL queries to backend data sources such as DynamoDB or Lambda functions, allowing efficient data fetching and real-time subscriptions without direct database connections from the client. Hybrid models combining FaaS and BaaS support full-stack serverless applications by orchestrating compute and data services in a unified . In these setups, FaaS handles dynamic logic while BaaS provides persistent storage and identity features, creating end-to-end applications like mobile backends or web services. A critical aspect is maintaining data consistency in distributed systems, where services like DynamoDB employ by default—ensuring replicas synchronize within one second or less after writes—though strongly consistent reads can be requested for scenarios requiring immediate accuracy at the cost of higher latency. This model balances availability and partition tolerance per the , with mechanisms like DynamoDB Streams aiding in event-driven consistency propagation across components.

Benefits and Operational Advantages

Scalability and Elasticity

Serverless computing inherently supports automatic scaling through horizontal provisioning of execution environments, enabling functions to respond to varying volumes without manual intervention. In platforms like , scaling occurs by creating additional execution environments—up to 1,000 per function every 10 seconds—based on incoming requests, allowing systems to handle bursts from zero to thousands of concurrent executions in seconds. This mechanism ensures that resources are allocated dynamically, with invoking code only when needed and scaling out to meet until account-level concurrency limits are reached. Similarly, Google Cloud Functions automatically scales HTTP-triggered functions rapidly in response to traffic, while background functions adjust more gradually, supporting a default of 100 instances (configurable up to 1,000) for second-generation functions. Elasticity in serverless architectures is achieved through instant provisioning and de-provisioning of resources, where unused execution environments are terminated after periods of inactivity to optimize efficiency. For instance, reuses warm environments for subsequent invocations and employs scaling governors, such as burst limits and gradual ramp-up rates, to prevent over-provisioning during sudden spikes while maintaining responsiveness. Provisioned concurrency in Lambda allows pre-warming of instances to minimize latency during predictable loads, and de-provisioning occurs seamlessly when demand drops, often scaling to zero instances. In Google Cloud Functions, elasticity is enhanced by configurable minimum and maximum instance settings, enabling scale-to-zero behavior for cost-effective idle periods and rapid expansion during active use. These features collectively reduce operational overhead by abstracting , allowing developers to focus on code rather than . One key advantage of serverless scalability is its ability to handle extreme traffic spikes with zero downtime, making it ideal for variable workloads like events. During Day 2022, AWS serverless components such as DynamoDB processed over 105 million requests per second, demonstrating seamless elasticity under peak global demand without infrastructure failures. Retailer leveraged to scale compute resources dynamically during COVID-19-induced traffic surges, equivalent to Black Friday volumes, ensuring uninterrupted service for millions of users. This automatic horizontal scaling prevents bottlenecks by distributing load across ephemeral instances, providing even during unpredictable bursts that could overwhelm traditional setups. However, serverless platforms impose limits and require configurations to manage effectively. AWS Lambda enforces regional quotas, such as a default account concurrency of 1,000 executions, with function-level reserved concurrency allowing customization to throttle or prioritize specific functions and avoid the noisy neighbor problem. Users can request quota increases, but scaling rates are governed to scale by up to 1,000 concurrent executions every 10 seconds per function for safety. In Google Cloud Functions, first-generation background functions support up to 3,000 concurrent invocations by default, while second-generation functions scale based on configurable instances and per-instance concurrency, with regional project limits on total memory and CPU to prevent overuse. These configurable limits enable fine-tuned elasticity while safeguarding against resource exhaustion, though exceeding them may require quota adjustments via provider consoles.

Cost Optimization and Efficiency

Serverless computing employs a pay-per-use billing model, where users are charged based on the number of function invocations and the duration of execution, rather than provisioning fixed resources. For instance, in , pricing includes $0.20 per 1 million requests and $0.0000166667 per GB-second of compute time, with duration rounded up to the nearest and now encompassing initialization phases as of August 2025. This granular approach ensures costs align directly with actual resource consumption, eliminating charges for idle time. The model delivers significant efficiency gains, particularly for bursty or unpredictable workloads, by avoiding the expenses of maintaining always-on virtual machines (VMs). Studies indicate serverless architectures can reduce total costs by 38% to 57% compared to traditional server-based models, factoring in infrastructure, development, and maintenance. For sporadic tasks, this translates to substantial savings, as organizations pay only for active execution rather than over-provisioned capacity that remains underutilized in VM setups. To further optimize costs, developers can minimize function duration through efficient code practices, such as reducing dependencies and optimizing algorithms, which directly lowers GB-second charges. Additionally, provisioned concurrency pre-warms execution environments to mitigate the cost implications of cold starts, ensuring consistent without excessive invocation overhead, though it incurs a fixed for reserved capacity. Total cost of ownership (TCO) in serverless benefits from diminished operational overhead, as providers handle infrastructure management, reducing the need for dedicated operations teams. However, TCO must account for potential fees from excessive invocations, such as in event-driven patterns that trigger functions more frequently than necessary, emphasizing the importance of architectural refinement to avoid unintended cost accumulation.

Challenges and Limitations

Performance Issues

One of the primary performance hurdles in serverless computing is the cold start latency, which occurs when a function requires provisioning a new execution environment, such as spinning up a or instance. This process involves downloading code packages, initializing the runtime, loading dependencies, and establishing network interfaces if applicable, leading to initial delays that can range from under 100 milliseconds to over 1 second in production workloads. Cold starts typically affect less than 1% of invocations in real-world deployments, but their impact is pronounced in latency-sensitive applications. Key factors exacerbating this latency include the choice of language runtime—interpreted languages like Python or initialize faster than compiled ones like due to reduced class loading overhead—and package size, where larger deployments (up to 250 MB unzipped) increase download and extraction times from object storage like Amazon S3. Serverless platforms impose strict execution limits to ensure resource efficiency and multi-tenancy, which can constrain throughput for compute-intensive or long-running tasks. For instance, enforces a maximum timeout of 900 seconds (15 minutes) per invocation, with configurable settings starting from 1 second, beyond which functions are terminated. Memory allocation ranges from 128 MB to 10,240 MB, and CPU power scales proportionally with memory—approximately 1.7 GHz equivalent per 1,769 MB—capping for memory-bound workloads and potentially throttling parallel processing. These constraints limit the suitability of serverless for tasks exceeding these bounds, such as complex simulations, forcing developers to decompose applications or offload to other services. Network overhead further compounds performance issues in serverless architectures, particularly through inter-service communications via APIs or message queues, which introduce additional latency in distributed workflows. In disaggregated environments, these calls—often over the public internet or virtual private clouds—contribute to elevated tail latency, defined as the 99th response time, due to variability in data transfer and queuing delays. Research on serverless clouds shows that such communication overhead can amplify tail latencies by factors related to bursty traffic and , making end-to-end predictability challenging for chained function executions. Monitoring distributed executions poses additional challenges, as serverless applications span multiple ephemeral functions and services, complicating the identification of performance bottlenecks. Tools like AWS X-Ray address this by providing end-to-end tracing, generating service maps, and analyzing request flows to pinpoint latency sources in real time, though enabling such adds minimal overhead to invocations. This visibility is essential for optimizing trace data across but requires careful configuration to avoid sampling biases in high-volume environments.

Security and Compliance Risks

In serverless computing, security operates under a shared responsibility model, where the cloud provider assumes responsibility for securing the underlying , including physical hardware, host operating systems, networking, and layers, while customers manage the security of their application code, data classification, encryption, and identity and access management (IAM) configurations. For example, in platforms like , the provider handles patching and configuration of the execution environment, but users must define IAM policies adhering to least-privilege principles to restrict function access to only necessary resources. Key risks include over-permissioned functions, where excessively broad IAM roles—such as those allowing wildcard (*) actions—can enable lateral movement or if a function is compromised. Secrets management introduces vulnerabilities when credentials are hardcoded in code or exposed via environment variables, increasing the potential for unauthorized access; services like AWS Secrets Manager mitigate this by providing encrypted storage, automatic rotation, and fine-grained IAM controls for retrieval. attacks further threaten serverless applications through compromised dependencies, with studies of public repositories revealing that up to 80% of components in platforms like Docker Hub contain over 100 outdated or vulnerable packages, such as those affected by critical CVEs in libraries like . Compliance challenges arise in multi-tenant serverless environments, where shared infrastructure heightens the need for data isolation to meet regulations like GDPR and HIPAA, which mandate strict controls on personal health information and data residency to prevent cross-tenant breaches. Auditing supports compliance through tools like AWS CloudTrail, which records calls and management events for operational , enabling analysis for regulatory adherence and incident response. Mitigations emphasize encryption of data at rest and in transit using provider-managed keys and protocols to protect sensitive information throughout its lifecycle. Integrating Web Application Firewalls (WAF) via gateways filters malicious inputs and enforces against abuse, while zero-trust architectures require continuous verification, , and isolated function permissions to minimize insider and threats.

Vendor Lock-in and Portability

Vendor lock-in in serverless computing arises primarily from the reliance on proprietary APIs and services offered by cloud providers, which create dependencies that hinder migration to alternative platforms. For instance, integrates seamlessly with AWS-specific event sources like S3 notifications and Gateway triggers, while Azure Functions uses distinct bindings for Azure Blob Storage and Event Hubs, necessitating code adaptations for cross-provider compatibility. Tooling differences further exacerbate this issue, as deployment configurations, runtime environments, and monitoring tools vary significantly between providers, often requiring reconfiguration of infrastructure-as-code scripts or pipelines. Additionally, data gravity—where accumulated data becomes tethered to a provider due to high egress fees—intensifies lock-in; for example, transferring 10 TB from AWS S3 incurs $891 in fees, compared to $239.76 for monthly storage, making portability economically prohibitive. Portability challenges in serverless environments stem from the need to rewrite triggers, integrations, and dependencies when switching providers, leading to substantial development effort and potential downtime. Empirical studies indicate that using native APIs results in higher refactoring demands; in one experiment involving migration from AWS to Google Cloud, native API adaptations required 24 lines of code changes per function, compared to just 10 with abstraction tools, highlighting up to 58% more effort without mitigation strategies. Surveys of serverless adopters reveal that 54% anticipate substantial refactoring for provider migrations, often involving rearchitecting event-driven workflows and state management to align with new platform semantics. These challenges not only increase migration costs but also introduce risks of incomplete portability, where certain workloads encounter "dead-ends" due to incompatible BaaS features. To address these issues, abstraction layers and open-source frameworks provide cloud-agnostic interfaces that decouple applications from provider-specific details, enabling easier multi-cloud deployments. The supports multiple providers including AWS, Azure, and Google Cloud through unified configurations, allowing developers to package functions as portable artifacts and switch backends with minimal code changes. OpenFaaS further enhances portability by building functions as OCI-compliant container images, deployable across clusters on any cloud or on-premises without rewriting, while abstracting scaling and event triggers. Standards like OpenAPI facilitate API-level by defining consistent service contracts, reducing the need for provider-specific client adaptations. For , tools like Terraform enable declarative provisioning of serverless resources across clouds, using provider-agnostic modules to handle functions, gateways, and storage consistently, thus mitigating lock-in through reproducible multi-cloud architectures. These solutions collectively promote workload distribution and vendor independence, though they require upfront investment in abstraction design.

Design Principles and Best Practices

Event-Driven Architecture

Event-driven architecture forms a foundational principle in serverless computing, where compute functions are invoked reactively in response to events generated by diverse sources, such as message queues, data streams, or publish-subscribe messaging systems. This paradigm decouples application components by treating events as the primary mechanism for communication, enabling systems to scale dynamically without continuous polling or tight integration between services. Typically, an event-driven serverless architecture comprises event sources that emit notifications, routers that filter and direct these events based on predefined rules, and destinations where functions or other handlers process them. Key patterns in event-driven serverless designs include and , which govern how services interact asynchronously. In , services operate independently by listening to and reacting to shared events without a central coordinator, promoting and reducing single points of failure. This contrasts with , where a central engine sequences and manages event flows across services, providing explicit control for complex, linear processes. For handling distributed transactions in event-driven systems, the pattern sequences local transactions with compensating actions to maintain consistency in the absence of traditional guarantees, often implemented via state machines in serverless . The adoption of event-driven principles in serverless yields significant benefits, including between components, which allows independent evolution and deployment of functions. Resilience is enhanced through built-in mechanisms like message and automatic retries, mitigating failures in transient environments. Additionally, this approach supports elastic scalability by buffering events during spikes, enabling functions to process workloads on demand without overprovisioning. To ensure interoperability across heterogeneous systems, event-driven serverless implementations often rely on standardized schemas, such as the CloudEvents specification introduced by the CNCF in 2018. CloudEvents defines a common structure for event metadata (e.g., source, type, time) and payload, facilitating portable event exchange between producers and consumers in cloud-native environments. This standard addresses fragmentation in event formats, promoting seamless integration in reactive systems while avoiding vendor-specific lock-in.

Stateless Design and Anti-Patterns

In serverless computing, functions operate under a strict stateless mandate, where each invocation is independent and does not retain memory of previous executions. This design principle ensures that the underlying platform can scale horizontally by distributing invocations across multiple instances without dependency on prior state, enhancing resilience and reducing coordination overhead. Any required state, such as user session data or application variables, must be explicitly stored and retrieved from external durable services, like for persistent or for caching. Violating this statelessness introduces several anti-patterns that undermine serverless benefits. One prevalent issue is storing session or temporary data in the function's in-memory environment, assuming persistence between calls; however, since functions may be reinitialized or terminated at any time, this leads to and inconsistent . Another anti-pattern involves designing long-running stateful processes within a single function, such as maintaining variables across extended operations, which often exceeds platform limits like the 15-minute timeout in or 10 minutes in Azure Functions (Consumption plan). The consequences of these anti-patterns are significant, including unpredictable scaling where load distribution fails due to state dependencies, resulting in throttled invocations or cascading errors. Debugging and monitoring become arduous, as transient environments make reproducing issues difficult, and costs escalate from inefficient resource usage during failed retries. For example, in session-based applications like real-time user interactions, in-memory state loss can cause abrupt session drops, leading to poor and reliability issues. To adhere to stateless , best practices emphasize externalizing all . Developers should implement idempotency mechanisms, using unique keys (e.g., transaction IDs) to ensure operations produce the same result on retries without side effects, as recommended for functions. For caching needs, integrate services like through to store transient data durably and access it efficiently across invocations. Functions should remain granular and single-purpose, with stateful elements offloaded to managed services, enabling reliable event-driven triggers for state updates.

Applications and Use Cases

Web and Mobile Applications

Serverless computing has enabled the development of scalable web applications by decoupling frontend and backend components, allowing developers to focus on code rather than management. In web applications, backends are commonly built using services like Amazon Gateway integrated with to handle RESTful or endpoints without provisioning servers. Gateway acts as a fully managed service that processes incoming HTTP requests, routes them to functions for execution, and returns responses, supporting features such as throttling, caching, and authentication. This setup allows for automatic scaling based on traffic, where invokes functions in response to events, ensuring for dynamic content delivery. Static website hosting in serverless architectures leverages like for storing frontend assets, combined with content delivery networks such as for global distribution and low-latency access. S3 buckets configured for static website hosting serve HTML, CSS, , and images directly, while CloudFront caches content at edge locations to reduce load times and handle traffic spikes without backend servers. This approach is particularly suited for single-page applications (SPAs) or progressive web apps (PWAs), where compute-intensive logic is offloaded to edge functions or integrated APIs. For mobile applications, serverless backends provide essential services like user , push notifications, and data without managing servers. Amazon Cognito offers serverless user , , and management, integrating seamlessly with mobile SDKs to handle sign-up, sign-in, and for millions of users via JWT tokens. Push notifications are facilitated by services like (FCM), which delivers real-time messages to and Android devices at scale, triggered by serverless functions in response to events such as user actions or database changes. Offline patterns in serverless mobile apps use client-side persistence, where local data is cached and synced bidirectionally with cloud databases like Realtime Database once connectivity is restored, ensuring resilient user experiences. For example, Cloud Functions can integrate with to handle custom backend logic for mobile apps, such as processing user events or integrating with other services. Real-world implementations demonstrate the effectiveness of serverless in web and mobile contexts. employs for serverless backend processes, such as processing millions of viewing requests and managing backups, enabling it to stream to over 300 million subscribers globally as of 2025 without provisioning capacity for peak loads. Similarly, Media Group uses functions to help editorial teams scale by templatizing and automating processes for its digital publishing platforms, serving over 80 million unique monthly readers. These examples highlight serverless , where architectures automatically handle surges—such as during viral events—scaling to millions of concurrent users by invoking functions on-demand and terminating them post-execution, thus optimizing resource utilization.

Data Processing and Analytics

Serverless computing facilitates efficient data processing and analytics by enabling event-driven (Extract, Transform, Load) pipelines that automatically scale to handle variable workloads without provisioning infrastructure. In such pipelines, data ingestion into can trigger functions to perform transformations, such as schema validation, , and partitioning, orchestrated by AWS Step Functions for workflow management and error handling. For instance, upon uploading CSV files to S3, Lambda validates data types and moves valid files to a staging area, while AWS Glue subsequently converts them to optimized format with partitioning by date, enabling faster queries for analytics tools like Amazon Athena. This approach ensures cost-effectiveness, as resources are invoked only when events occur, and supports integration with data catalogs for metadata management. For comparison, Functions can be used in similar event-driven ETL pipelines, integrating with Azure Blob Storage and Data Factory for scalable data transformations. For stream analytics, serverless platforms support real-time ingestion and processing of continuous data flows, leveraging services like Amazon Kinesis Data Streams integrated with to compute aggregates in near-real-time. processes records from Kinesis streams synchronously, using tumbling windows—fixed, non-overlapping time intervals up to 15 minutes—to group data and maintain state across invocations, such as calculating total sales or metrics every 30 seconds from point-of-sale streams. This enables applications like fraud detection or live dashboards, where scales automatically to match stream throughput without managing servers. A prominent example is IoT data , where AWS IoT Greengrass extends serverless capabilities to by allowing devices to filter, aggregate, and analyze sensor data locally before transmission to the cloud. Greengrass runs functions on edge devices to process and react to local events autonomously, reducing latency and bandwidth costs—for instance, aggregating telemetry from industrial sensors and exporting summarized insights to AWS IoT Core for further . Similarly, serverless log benefits from Amazon CloudWatch Logs integrated with Amazon Athena, enabling SQL queries on log data without data movement; Athena's connector maps log groups to schemas and streams to tables, supporting real-time analysis of access logs for insights like error rates or user patterns, often preprocessed by for efficiency. Key tools in this domain include AWS Glue, a fully managed, serverless ETL service that automates data discovery, preparation, and loading using , supporting over 70 data sources and formats. Glue crawlers catalog data in S3 or other stores, while its visual ETL interface and built-in transforms—like deduplication via FindMatches—streamline pipelines for , with jobs triggered by events or schedules to handle bursts scalably.

AI and Retrieval-Augmented Generation (RAG)

Serverless computing has become increasingly important in AI applications, particularly those leveraging Retrieval-Augmented Generation (RAG) for accurate, source-grounded responses. In RAG implementations, serverless functions such as AWS Lambda can handle event-driven retrieval from vector databases and integrate with foundation models like those in Amazon Bedrock to generate responses. This approach enables scalable, cost-efficient processing of AI queries without managing infrastructure. Organizations benefit from reduced hallucinations, improved accuracy, and verifiable responses through grounded retrieval. Key implementation considerations include selecting appropriate embedding models (e.g., OpenAI's text-embedding-ada-002), optimizing retrieval mechanisms for relevance, and evaluating response quality metrics. Implementation guides detail approaches for integrating serverless computing with modern AI architectures.

Comparisons and Ecosystem

Versus Traditional Cloud Models

Serverless computing represents a higher level of abstraction compared to Infrastructure as a Service (IaaS) models, such as Amazon EC2, where developers must provision and manage virtual machines (VMs) explicitly. In IaaS, scaling typically requires manual configuration of auto-scaling groups or overprovisioning to anticipate demand, leading to potential idle resources and higher operational overhead. Serverless platforms, by contrast, fully abstract VMs, automatically scaling individual functions in response to events and scaling to zero during inactivity, thereby eliminating server management tasks and enabling fine-grained resource utilization. This shift allows developers to deploy code without concern for underlying infrastructure, though it sacrifices direct control over hardware and networking configurations available in IaaS. Relative to (PaaS) environments like , serverless reduces platform-specific configuration even further by managing runtime provisioning entirely on the provider's side. PaaS offers automated scaling and deployment simplicity but often requires developers to handle application-level optimizations and incurs costs based on continuous instance runtime, regardless of actual usage. Serverless introduces more granular billing—typically per of execution and per invocation—potentially lowering costs for sporadic workloads, while PaaS billing aligns more closely with provisioned capacity over hours or days. However, this comes with trade-offs in , as PaaS provides broader platform insights compared to the function-centric monitoring in serverless. Overall, serverless enhances developer productivity by shifting focus from infrastructure orchestration to , fostering faster iteration in event-driven systems. Yet, it offers less control than IaaS or PaaS, particularly for custom optimizations or stateful workloads, making it ideal for decomposed into stateless functions but less suitable for tightly coupled monolithic architectures without decomposition. Migration paths from traditional models often employ the Strangler pattern, incrementally refactoring legacy VMs or monoliths by routing subsets of functionality to new serverless functions, allowing gradual replacement while maintaining system availability. This approach minimizes disruption but requires careful identification of modular components to avoid entanglement with legacy dependencies. When decomposing a monolithic application into serverless functions, several factors influence the number of functions required. Application complexity is a primary determinant; simple CRUD operations may necessitate fewer functions, whereas feature-rich applications with intricate workflows demand more to handle diverse responsibilities. Decomposition strategies strongly discourage the "mono-Lambda" anti-pattern, in which a single function manages multiple tasks, and instead advocate for the single-responsibility principle, assigning one function per endpoint or discrete task to enhance modularity and maintainability. For typical applications, this may result in 10-50 API routes, plus additional functions for authentication, processing, and background jobs. The granularity of decomposition further affects the count: finer-grained functions increase the total number, promoting better scalability and code reuse, while coarser-grained approaches reduce it but introduce risks of tight coupling and operational challenges.

Integration with High-Performance Computing

Serverless computing encounters significant challenges when adapting to (HPC) workloads, primarily due to execution time limits—such as the 15-minute maximum on —that conflict with the extended durations of HPC simulations, often lasting hours or days. These constraints hinder direct deployment of compute-intensive tasks like or climate modeling, leading to fragmented workflows and potential data transfer overheads. To mitigate this, platforms like AWS Batch offer job queuing and multi-node parallel processing, allowing serverless orchestration of long-running HPC jobs without managing underlying infrastructure. Hybrid models bridge these gaps by combining function-as-a-service (FaaS) with container-based systems, such as integrating with for GPU-accelerated tasks or using Knative on to deploy serverless functions alongside HPC clusters. For example, the rFaaS framework enables software resource disaggregation on supercomputers, co-locating short-lived serverless functions with batch-managed jobs to utilize idle CPU cores, memory, and GPUs via high-performance interconnects like RDMA, achieving up to 53% higher system utilization with minimal overhead (less than 5% for GPU sharing). Practical use cases demonstrate these integrations' viability, such as genomics simulations where processes protein sequence alignments using the Striped Smith-Waterman algorithm, partitioning tasks across hundreds of functions to deliver a 250x speedup over single-machine execution at under $1 total cost. Similarly, serverless supports bursty AI training workloads by elastically provisioning GPUs for intermittent high-demand phases, as seen in hybrid setups with for distributed model fine-tuning. Advancements in the have further propelled serverless HPC through specialized frameworks, including Wukong, which optimizes on platforms like via decentralized scheduling and data locality enhancements, accelerating jobs up to 68 times while reducing network I/O by orders of magnitude. Other tools, such as the ORNL framework for workflow adaptation, enable seamless migration of traditional HPC benchmarks to serverless environments, cutting CPU usage by 78% and by 74% without degradation in scientific simulations.

Future Directions

One prominent emerging trend in serverless computing is the extension of serverless paradigms to edge environments, enabling deployment on IoT devices and resource-constrained hardware for low-latency processing. AWS IoT Greengrass exemplifies this shift by supporting the execution of functions directly on edge devices, allowing local event-driven responses without constant cloud connectivity. In 2024, enhancements such as the introduction of AWS IoT Greengrass Nucleus Lite provided a lightweight, open-source runtime optimized for devices like smart home hubs and edge AI systems, reducing resource overhead and facilitating broader IoT adoption. These developments address challenges like intermittent connectivity in remote or mobile scenarios, promoting hybrid cloud-edge architectures. Integration of and (AI/ML) workflows represents another key innovation, particularly through serverless capabilities that eliminate infrastructure management for model deployment. Serverless , announced in preview at AWS re:Invent 2021 and generally available in 2022, allows users to serve ML models with automatic scaling based on traffic, handling variable workloads without provisioning servers. This facilitates efficient real-time in applications like recommendation systems or . Complementing this, serverless AutoML workflows are gaining traction, automating model selection, hyperparameter tuning, and deployment in event-driven pipelines; for instance, platforms like Google Cloud's Vertex AI integrate serverless execution to streamline end-to-end ML operations without dedicated compute resources. The rise of multi-cloud and hybrid serverless environments is driven by portable runtimes like (Wasm), which enable code execution across diverse infrastructures with minimal . WasmEdge, launched around 2020 as a lightweight, high-performance Wasm runtime, supports serverless functions in cloud-native, edge, and decentralized settings, offering up to 100 times faster startup than traditional containers and compatibility with ecosystems. Its extensibility allows seamless migration between providers, such as deploying functions from to Azure Functions, fostering greater interoperability in hybrid setups. Evolving standards are enhancing serverless interoperability, with specifications like CloudEvents providing a unified format for event data across platforms. The CloudEvents 1.0 specification, released in October 2019 under the (CNCF), defines common attributes for events—such as source, type, and time—enabling consistent declaration and delivery in serverless systems regardless of the underlying service. Adopted by major providers including AWS, Azure, and Google Cloud, it supports subsequent extensions like version 1.1, further improving event routing and integration in distributed architectures. A growing emerging trend is the integration of serverless computing with Retrieval-Augmented Generation (RAG) in AI applications, enabling scalable, event-driven retrieval and generation processes that reduce hallucinations and improve response accuracy through source-grounded outputs. Key considerations include embedding model selection, retrieval optimization, and response quality evaluation. For details on applications and use cases, see the "Applications and Use Cases" section.

Sustainability and Broader Impacts

Serverless computing's pay-per-use model enhances energy efficiency by eliminating idle , particularly for bursty or intermittent workloads where traditional virtual machines (VMs) remain active unnecessarily. Studies indicate that this approach can reduce by up to 70% compared to VM-based systems, with similar reductions in carbon emissions for event-driven applications. For instance, AWS reports up to 70% lower carbon footprints for serverless functions in suitable scenarios, while has observed a tenfold decrease in electric footprint through consumption-based utilization. These gains stem from fine-grained , allowing functions to scale precisely to demand and avoid the overhead of persistent servers. Beyond environmental benefits, serverless computing democratizes access to scalable , enabling startups to innovate without substantial upfront investments in hardware or expertise. By abstracting management, it lowers barriers for small teams, fostering and deployment that were previously feasible only for large enterprises. This shift also transforms roles, reducing the need for deep knowledge as providers handle provisioning, scaling, and , allowing developers to focus on application logic and business value. However, challenges persist, including rebound effects where the ease of scaling encourages higher overall usage, potentially offsetting efficiency gains and increasing total cloud energy demands. Additionally, the rapid pace of provider updates and hardware refreshes in serverless ecosystems can contribute to electronic waste (e-waste) from obsolete equipment, exacerbating the environmental footprint of cloud infrastructure. To address these, tools like the AWS Customer Tool, launched in 2022, provide metrics for estimating emissions from serverless workloads, including historical data from January 2022 onward, to help users optimize and track . In October 2025, AWS updated the tool to include Scope 3 emissions data, providing fuller visibility into the lifecycle carbon impact of serverless usage.

References

  1. https://aws.amazon.com/what-is/serverless-computing/
  2. https://cacm.acm.org/article/serverless-computing/
  3. https://cloud.google.com/discover/what-is-serverless-computing
  4. https://azure.microsoft.com/en-us/resources/cloud-computing-dictionary/what-is-paas
  5. https://www.redhat.com/en/topics/cloud-native-apps/what-is-serverless
  6. https://cloud.google.com/discover/types-of-cloud-computing
  7. https://aws.amazon.com/about-aws/our-origins/
  8. https://docs.aws.amazon.com/whitepapers/latest/aws-overview/introduction.html
  9. https://aws.amazon.com/about-aws/whats-new/2014/11/13/introducing-aws-lambda/
  10. https://aws.amazon.com/blogs/aws/aws-lambda-turns-ten-the-first-decade-of-serverless-innovation/
  11. https://azure.microsoft.com/en-us/blog/announcing-general-availability-of-azure-functions/
  12. https://cloud.google.com/blog/products/gcp/google-cloud-functions-a-serverless-environment-to-build-and-connect-cloud-services_13
  13. https://docs.openfaas.com/
  14. https://www.infoq.com/news/2018/07/knative-kubernetes-serverless/
  15. https://aws.amazon.com/blogs/aws/coming-soon-lambda-at-the-edge/
  16. https://www.cncf.io/announcements/2025/10/08/cloud-native-computing-foundation-announces-knatives-graduation/
  17. https://www.datadoghq.com/state-of-serverless/
  18. https://www.grandviewresearch.com/industry-analysis/serverless-computing-market-report
  19. https://www.ibm.com/think/topics/faas
  20. https://www.bmc.com/blogs/serverless-faas/
  21. https://www.geeksforgeeks.org/cloud-computing/serverless-computing-and-faas-model-the-next-stage-in-cloud-computing/
  22. https://ej-compute.org/index.php/compute/article/view/156
  23. https://www.researchgate.net/figure/Life-cycle-state-diagram-of-a-function-instance_fig1_359314029
  24. https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
  25. https://docs.aws.amazon.com/lambda/latest/dg/lambda-concurrency.html
  26. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
  27. https://docs.cloud.google.com/functions/quotas
  28. https://docs.cloud.google.com/run/docs/runtimes/function-runtimes
  29. https://learn.microsoft.com/en-us/azure/azure-functions/supported-languages
  30. https://learn.microsoft.com/en-us/azure/azure-functions/functions-scale
  31. https://aws.amazon.com/step-functions/
  32. https://docs.aws.amazon.com/step-functions/latest/dg/integrate-services.html
  33. https://www.cloudflare.com/learning/serverless/glossary/backend-as-a-service-baas/
  34. https://docs.aws.amazon.com/appsync/latest/devguide/resolver-components.html
  35. https://arxiv.org/abs/2209.09367
  36. https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html
  37. https://aws.amazon.com/blogs/database/build-scalable-event-driven-architectures-with-amazon-dynamodb-and-aws-lambda/
  38. https://docs.aws.amazon.com/lambda/latest/dg/scaling-behavior.html
  39. https://cloud.google.com/functions/quotas
  40. https://cloud.google.com/functions/docs/configuring/max-instances
  41. https://journalofcloudcomputing.springeropen.com/articles/10.1186/s13677-021-00253-7
  42. https://aws.amazon.com/blogs/industries/how-to-plan-for-peak-demand-on-an-aws-serverless-digital-commerce-platform/
  43. https://cloud.google.com/functions/docs/configuring/concurrency
  44. https://aws.amazon.com/lambda/pricing/
  45. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/cost-optimization.html
  46. https://d1.awsstatic.com/SMB/deloitte-tco-of-serverless-whitepaper-2022-smb-build-websites-and-apps-resource.pdf
  47. https://arxiv.org/pdf/2506.05836
  48. https://docs.aws.amazon.com/lambda/latest/dg/provisioned-concurrency.html
  49. https://d1.awsstatic.com/psc-digital/2023/gc-300/deloitte-tco-mod/determining-the-total-cost-of-ownership.pdf
  50. https://aws.amazon.com/blogs/compute/understanding-techniques-to-reduce-aws-lambda-costs-in-serverless-applications/
  51. https://aws.amazon.com/blogs/compute/operating-lambda-performance-optimization-part-1/
  52. https://aws.amazon.com/blogs/compute/understanding-and-remediating-cold-starts-an-aws-lambda-perspective/
  53. https://docs.aws.amazon.com/lambda/latest/dg/troubleshooting-configuration.html
  54. https://docs.aws.amazon.com/lambda/latest/dg/configuration-memory.html
  55. https://ustiugov.github.io/assets/files/STELLAR_ISWC21.pdf
  56. https://www.researchgate.net/publication/357820896_Analyzing_Tail_Latency_in_Serverless_Clouds_with_STeLLAR
  57. https://aws.amazon.com/xray/
  58. https://aws.amazon.com/compliance/shared-responsibility-model/
  59. https://cheatsheetseries.owasp.org/cheatsheets/Serverless_FaaS_Security_Cheat_Sheet.html
  60. https://aws.amazon.com/secrets-manager/
  61. https://arxiv.org/pdf/2510.17311
  62. https://www.researchgate.net/publication/391881668_SECURITY_AND_COMPLIANCE_CONSIDERATIONS_IN_SERVERLESS_DATA_ENGINEERING
  63. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/CloudTrail-compliance.html
  64. https://www.sysdig.com/learn-cloud-native/serverless-security-risks-and-best-practices
  65. https://www.imperva.com/blog/mitigating-attacks-in-serverless-environments/
  66. http://faculty.washington.edu/wlloyd/papers/MoCloudCom2023proof.pdf
  67. https://arxiv.org/pdf/2209.09367
  68. https://iaeme.com/MasterAdmin/Journal_uploads/IJCET/VOLUME_15_ISSUE_6/IJCET_15_06_083.pdf
  69. https://www.openfaas.com/
  70. https://www.hashicorp.com/en/resources/terraforming-in-a-serverless-world
  71. https://docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/event-driven-architectures.html
  72. https://learn.microsoft.com/en-us/azure/architecture/patterns/choreography
  73. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html
  74. https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/event-driven
  75. https://cloudevents.io/
  76. https://aws.amazon.com/blogs/architecture/converting-stateful-application-to-stateless-using-aws-services/
  77. https://www.fermyon.com/serverless-guide/statelessness
  78. https://learn.microsoft.com/en-us/azure/azure-functions/functions-best-practices
  79. https://aws.amazon.com/blogs/compute/operating-lambda-anti-patterns-in-event-driven-architectures-part-3/
  80. https://aws.amazon.com/blogs/architecture/mistakes-to-avoid-when-implementing-serverless-architecture-with-lambda/
  81. https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/anti-patterns
  82. https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html
  83. https://aws.amazon.com/blogs/compute/handling-lambda-functions-idempotency-with-aws-lambda-powertools/
  84. https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html
  85. https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html
  86. https://docs.aws.amazon.com/AmazonS3/latest/userguide/HostingWebsiteOnS3Setup.html
  87. https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-s3-amazon-cloudfront-a-match-made-in-the-cloud/
  88. https://firebase.google.com/docs/database/android/offline-capabilities
  89. https://cloud.google.com/functions/docs
  90. https://www.almabetter.com/bytes/articles/how-netflix-uses-aws-lambda-to-process-view-requests
  91. https://ir.netflix.net/ir-overview/profile/default.aspx
  92. https://aws.amazon.com/blogs/startups/how-bustle-leverages-aws-lambda-to-help-editorial-teams-scale/
  93. https://ideonmedia.com/ideon-media-announces-exclusive-ad-sales-representation-of-bustle-digital-group-bdg-in-canada/
  94. https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/orchestrate-an-etl-pipeline-with-validation-transformation-and-partitioning-using-aws-step-functions.html
  95. https://learn.microsoft.com/en-us/azure/azure-functions/functions-compare-logic-apps-ms-flow-webjobs
  96. https://aws.amazon.com/blogs/compute/using-aws-lambda-for-streaming-analytics/
  97. https://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.html
  98. https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html
  99. https://docs.aws.amazon.com/athena/latest/ug/connectors-cloudwatch.html
  100. https://aws.amazon.com/blogs/big-data/build-a-serverless-architecture-to-analyze-amazon-cloudfront-access-logs-using-aws-lambda-amazon-athena-and-amazon-kinesis-analytics/
  101. https://docs.aws.amazon.com/glue/latest/dg/what-is-glue.html
  102. https://aws.amazon.com/blogs/compute/building-a-serverless-document-chat-with-aws-lambda-and-amazon-bedrock/
  103. https://app.ailog.fr/en/blog/guides/rag-as-a-service
  104. https://aws.amazon.com/startups/learn/serverless-retrieval-augmented-generation-on-aws
  105. https://dl.acm.org/doi/10.1145/3510611
  106. https://www.infoq.com/articles/mvp-mva-legacy/
  107. https://medium.com/aws-serverless-microservices-with-patterns-best/decompose-lambda-functions-monolithic-microservices-vs-single-purposed-functions-f4b87465cb36
  108. https://www.infoq.com/articles/migrating-monoliths-to-microservices-with-decomposition/
  109. https://www.osti.gov/servlets/purl/2538241
  110. https://aws.amazon.com/batch/features/
  111. https://dl.acm.org/doi/pdf/10.1109/SCW63240.2024.00262
  112. https://arxiv.org/abs/2401.10852
  113. https://www.researchgate.net/publication/326732411_Serverless_computing_provides_on-demand_high_performance_computing_for_biomedical_research
  114. https://www.researchgate.net/publication/391903774_Serverless_GPU_Execution_Models_for_High-_Performance_Computing_in_Hybrid_Clouds
  115. https://www.ornl.gov/publication/enabling-hpc-scientific-workflows-serverless
  116. https://aws.amazon.com/greengrass/features/
  117. https://docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-v2-whats-new.html
  118. https://aws.amazon.com/about-aws/whats-new/2022/04/amazon-sagemaker-serverless-inference/
  119. https://eajournals.org/bjms/wp-content/uploads/sites/21/2025/04/The-Rise-of-Serverless-AI.pdf
  120. https://wasmedge.org/
  121. https://www.cncf.io/projects/wasmedge-runtime/
  122. https://www.cncf.io/announcements/2019/10/28/serverless-specification-cloudevents-reaches-version-1-0/
  123. https://aws.amazon.com/startups/learn/serverless-retrieval-augmented-generation-on-aws?lang=en-US
  124. https://www.mdpi.com/2071-1050/17/7/2999
  125. https://devblogs.microsoft.com/sustainable-software/how-azure-com-uses-serverless-functions-for-consumption-based-utilization-and-reduced-always-on-electric-footprint/
  126. https://aws.amazon.com/about-aws/whats-new/2025/10/aws-customer-carbon-footprint-tool-scope-3-emissions-data/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.