Extending your SaaS platform with AWS Lambda
AWS Architecture BlogExtending your SaaS platform with AWS Lambdaby Hasan Tariq, Anton Aleksandrov, and Deepthi Chelupati | on22 AUG 2022| inAmazon DynamoDB,Amazon EventBridge,Architecture,Serverless|Permalink|ShareSoftware as a service (SaaS) providers continuously add new features and capabilities to their products to meet their growing customer needs. As enterprises adopt SaaS to reduce the total cost of ownership and focus on business priorities, they expect SaaS providers to enable customization capabilities.Many SaaS providers allow their customers (tenants) to provide customer-specific code that is triggered as part of various workflows by the SaaS platform. This extensibility model allows customers to customize system behavior and add rich integrations, while allowing SaaS providers to prioritize engineering resources on the core SaaS platform and avoid per-customer customizations.To simplify experience for enterprise developers to build on SaaS platforms, SaaS providers are offering the ability to host tenant’s code inside the SaaS platform. This blog provides architectural guidance for running custom code on SaaS platforms usingAWS serverless technologiesandAWS Lambdawithout the overhead of managing infrastructure on either the SaaS provider or customer side.Vendor-hosted extensionsWith vendor-hosted extensions, the SaaS platform runs the customer code in response to events that occur in the SaaS application. In this model, the heavy-lifting of managing and scaling the code launch environment is the responsibility of the SaaS provider.To host and run custom code, SaaS providers must consider isolating the environment that runs untrusted custom code from the core SaaS platform, as detailed in Figure 1. This introduces additional challenges to manage security, cost, and utilization.Figure 1. Distribution of responsibility between Customer and SaaS platform with vendor-hosted extensionsUsing AWS serverless services to run custom codeUsing AWS serverless technologies removes the tasks of infrastructure provisioning and management, as there are no servers to manage, and SaaS providers can take advantage of automatic scaling, high availability, and security, while only paying for value.Example use caseLet’s take an example of a simple SaaS to-do list application that supports the ability to initiate custom code when a new to-do item is added to the list. This application is used by customers who supply custom code to enrich the content of newly added to-do list items. The requirements for the solution consist of:Custom code provided by each tenant should run in isolation from all other tenants and from the SaaS core productTrack each customer’s usage and cost of AWS resourcesAbility to scale per customerSolution overviewThe SaaS application in Figure 2 is the core application used by customers, and each customer is considered a separate tenant. For the sake of brevity, we assume that the customer code was already stored in anAmazon Simple Storage Service (Amazon S3)bucket as part of the onboarding. When an eligible event is generated in the SaaS application as a result of user action, like a new to-do item added, it gets propagated down to securely launch the associated customer code.Figure 2. Example use case architectureWalkthrough of custom code runLet’s detail the initiation flow of custom code when a user adds a new to-do item:An event is generated in the SaaS application when a user performs an action, like adding a new to-do list item. To extend the SaaS application’s behavior, this event is linked to the custom code. Each event contains a tenant ID and any additional data passed as part of the payload. Each of these events is an “initiation request” for the custom code Lambda function.Amazon EventBridgeis used to decouple the SaaS Application from event processing implementation specifics. EventBridge makes it easier to build event-driven applications at scale and keeps the future prospect of adding additional consumers. In case of unexpected failure in any downstream service, EventBridge retries sending events a set number of times.EventBridge sends the event to anAmazon Simple Queue Service (Amazon SQS)queue as a message that is subsequently picked up by a Lambda function (Dispatcher) for further routing. Amazon SQS enables decoupling and scaling of microservices and also provides a buffer for the events that are awaiting processing.The Dispatcher polls the messages from SQS queue and is responsible for routing the events to respective tenants for further processing. The Dispatcher retrieves the tenant ID from the message and performs a lookup in the database (we recommendAmazon DynamoDBfor low latency), retrieves tenant SQS Amazon Resource Name (ARN) to determine which queue to route the event. To further improve performance, you can cache the tenant-to-queue mapping.The tenant SQS queue acts as a message store buffer and is configured as an event source for a Lambda function. UsingAmazon SQS as an event source for Lambdais a common pattern.Lambda executes the code uploaded by the tenant to perform the desired operation. Common utility and management code (including logging and telemetry code) is kept inLambda layersthat get added to every custom code Lambda function provisioned.After performing the desired operation on data, custom code Lambda returns a value back to the SaaS application. This completes the run cycle.This architecture allows SaaS applications to create a self-managed queue infrastructure for running custom code for tenants in parallel.Tenant code uploadThe SaaS platform can allow customers to upload code either through a user interface or using a command line interface that the SaaS provider provides to developers to facilitate uploading custom code to the SaaS platform. Uploaded code is saved in the custom code S3 bucket in .zip format that can be used to provision Lambda functions.Custom code Lambda provisioningThe tenant environment includes a tenant SQS queue and a Lambda function that polls launch requests from the queue. This Lambda function is built from two parts: (1) common code provided by the SaaS platform and (2) custom code provided by customers.The common code is responsible for bridging the SaaS platform and custom business logic provided by tenants. It “wraps” the custom code provided by the customer, so that custom code is fully abstracted from the processing implementation specifics. For example, we do not want custom code to know that the payload it is receiving comes from Amazon SQS or be aware of the destination where the launch response is sent. Two major parts the common code is responsible for are:Polling messages from the SQS queue and constructing a JSON payload that is sent an input to custom code.Once the custom code initiation is complete, the common code emits a notification with processing results back to the SaaS application. This can be done directly via EventBridge or Amazon SQS.This common code can be shared across tenants and deployed by the SaaS provider, either as a library or as a Lambda layer that gets added to the Lambda function.Each Lambda function initiation environment is fully isolated by using a combination ofopen-source and proprietary isolation technologies, it helps you to address the risk of cross-contamination. By having a separate Lambda function provisioned per-tenant, you achieve the highest level of isolation and benefit from being able to track per-tenant costs.ConclusionIn this blog post, we explored the need to extend SaaS platforms using custom code and why AWS serverless technologies—using Lambda and Amazon SQS—can be a good fit to accomplish that. We also looked at a solution architecture that can provide the necessary tenant isolation and is cost-effective for this use case.For more information on building applications with Lambda, visitServerless Land. For best practices on building SaaS applications, visitSaaS on AWS.Hasan TariqHasan Tariq is a Senior Solutions Architect at Amazon Web Services based in San Francisco. He works with the ISV customers and has more than 18 years of industry experience covering a wide range of technologies. His areas of interest are Serverless and Software as a Service (SaaS).Anton AleksandrovAnton Aleksandrov is a Principal Solutions Architect for AWS Serverless and Event-Driven architectures. Having over 20 years of hands-on software engineering and architecture experience, Anton is working with major ISV and SaaS customers to design highly scalable, innovative, and secure cloud solutions. Throughout his career Anton has held multiple leading roles architecting solutions for enterprise cloud applications, developer experience, mobile services, and the security space.Deepthi ChelupatiDeepthi is a Senior Product Manager for AWS Lambda. She is focused on enabling enterprises and SaaS builders to build secure and scalable applications using Lambda and Serverless technologies on AWS. She enjoy landscape photography and painting.
Software as a service (SaaS) providers continuously add new features and capabilities to their products to meet their growing customer needs. As enterprises adopt SaaS to reduce the total cost of ownership and focus on business priorities, they expect SaaS providers to enable customization capabilities. Many SaaS providers allow their customers (tenants) to provide customer-specific […]
Hasan Tariq
Amazon DynamoDB Amazon EventBridge Architecture Serverless