Serverless functions are a cornerstone of modern cloud computing, widely adopted across industries for their ability to simplify application deployment and management. Newer functions eliminate the need for server provisioning or infrastructure maintenance, letting developers focus solely on writing and deploying code.
Major cloud providers like AWS, Microsoft, and Google offer serverless functions, making this option accessible to a broad audience.
Serverless functions are particularly effective for small-scale tasks such as analyzing images or processing events from IoT devices. Functions can be deployed quickly and scaled effortlessly in response to demand, making them ideal for scenarios where workloads are unpredictable or vary significantly over time.
When serverless functions shine and when they don’t
Serverless functions excel in scenarios where tasks are simple, isolated, and event-driven. Functions are well-suited for ad hoc applications that require rapid deployment and do not involve complex data processing or long-running workflows.
Serverless functions are ideal for automating real-time responses, such as processing data from IoT sensors or managing lightweight backend processes like user authentication and image resizing.
However, their suitability for complex workflows is questionable. Concerns arise when serverless functions are used in scenarios involving persistent, mission-critical data, such as airline operations.
Airlines manage vast amounts of data related to flights, passengers, baggage, gate assignments, and crew scheduling, requiring high reliability and the ability to process large volumes of events quickly and accurately.
In such environments, the limitations of serverless functions become apparent. The need for frequent data access and updates from external databases can introduce latency, particularly in workflows involving multiple interconnected processes.
Overheads associated with dynamic resource allocation in serverless architectures further compounds these latency issues, potentially hindering performance.
The hidden flaws and limitations holding serverless functions back
One fundamental challenge with serverless functions is the overhead incurred when computing resources are allocated on demand. This delay, known as “cold start” latency, can be particularly problematic in time-sensitive applications. Additionally, serverless functions are stateless, requiring data to be fetched from external sources for each invocation, which further exacerbates latency issues.
The absence of local, in-memory caching necessitates data retrieval over the network, leading to slower processing times.
As applications scale, serverless functions can introduce architectural challenges that hinder long-term maintainability. Difficulty comes from enforcing a clear separation of concerns within the codebase can lead to duplication across multiple functions, making the system more complex and harder to manage.
The stateless nature of serverless functions also complicates the management of shared state and data consistency, which are critical in complex workflows involving multiple interdependent processes.
The dark side of serverless functions
Serverless functions operate in a dynamic environment where resources are provisioned and deprovisioned on demand. It can lead to unpredictable behaviors, such as timeouts and quota limits, which are not typically encountered in traditional architectures.
Developers must implement comprehensive error handling and retry mechanisms to mitigate these issues, adding complexity to the application development process.
A smarter approach, bringing code to the data for better performance
In-memory computing is an alternative that brings code closer to the data, reducing the need for constant data retrieval from external sources. It is an approach that uses scalable in-memory data grids, where data is stored in primary memory across a cluster of servers, allowing functions to execute directly on the data without the latency introduced by external data stores.
In-memory computing also offers high scalability, with the ability to handle very large workloads by adding nodes to the cluster as the workload increases. The distributed nature of in-memory data grids ensures that even the most demanding applications maintain high performance as they grow.
Redundancy provided by replicating data across multiple nodes minimizes the risk of data loss and ensures continuous operation even in the event of a node failure.
In-memory computing is the secret sauce for complex workflows
In-memory computing not only improves performance but also addresses the architectural challenges associated with serverless functions. When combining the strengths of data-structure stores and actor models, in-memory computing helps developers structure their code more effectively, reducing duplication and improving maintainability.
One key advantage of in-memory computing is its ability to restrict processing on objects to methods defined by their data types. This helps prevent code duplication that often occurs when multiple serverless functions are created for different aspects of the same workflow.
When centralizing logic within the data grid, in-memory computing simplifies development and reduces the risk of errors. Additionally, it eliminates the need for object locking, a common challenge in systems relying on persistent data stores, by allowing data to be processed directly in memory.
AWS Lambda vs. ScaleOut Digital Twins in real-world testing
In the serverless implementation, an event controller triggers a Lambda function for each flight cancellation. Subsequently, a ‘passenger lambda’ function is invoked to handle the rebooking of passengers. It is a function that updates the passenger’s information, removes them from the original flight, and adds them to the new flight, requiring locking mechanisms to synchronize access to the Dynamo DB objects.
How AWS Lambda handles workflows
AWS Lambda handles the cancellation and rebooking process by breaking it down into discrete functions that are triggered by specific events. Each function operates independently, retrieving and updating data in DynamoDB.
While this approach is flexible and scalable for smaller workloads, it introduces latency due to the need for repeated data retrieval and synchronization across functions.
A closer look at the Digital twin strategy in action
In contrast, the ScaleOut Digital Twins implementation dynamically creates in-memory objects for flights and passengers as they are accessed from DynamoDB. Messages are sent between these objects to handle the cancellation and rebooking processes, with each passenger object autonomously managing its rebooking.
Why Digital Twins crush serverless in speed and scalability
Benchmarking results clearly demonstrate the superiority of in-memory computing for this type of workflow. The ScaleOut Digital Twins processed 25 flight cancellations with 100 passengers per flight 11 times faster than AWS Lambda. While the serverless approach struggled to scale beyond the target workload of canceling 250 flights with 250 passengers each, the Digital Twin implementation handled double this workload (500 flights) without difficulty.
Results clearly show the limitations of serverless functions for large-scale, complex workflows. In contrast, the ScaleOut Digital Twins’ ability to process data directly in memory without the need for external synchronization supports more efficient handling of larger workloads.
Final thoughts
While serverless functions offer advantages for small, ad hoc applications, they may fall short when managing complex workflows involving large volumes of data that require high scalability. Limitations in latency, overhead, and architectural complexity can make serverless functions less suitable for high-stakes operations.
In-memory computing, by bringing code closer to the data, offers a compelling alternative that addresses many challenges associated with serverless architectures.
When reducing data motion, improving processing speed, and simplifying architecture, in-memory computing provides a more efficient and scalable solution for complex workflows. Understanding these trade-offs is critical in making informed decisions about the technologies to deploy as organizations push the boundaries of their applications.
