aws-samples/aws-serverless-saas-layers

A set of labs that illustrates the concept of multi-tenancy. AWS Lambda layers is used to introduce reusable service constructs and abstract multi-tenancy from SaaS developers.

Building Serverless SaaS with AWS Lambda layers

Introduction

One of the key goals of every software-as-a-service (SaaS) architect, is to create an environment where the complexity of multi-tenancy is largely hidden away from developers. The goal of this session is to introduce frameworks, libraries, and tooling that limits a developer’s need to have any awareness of tenant context. This will free up developers to focus on the features and functionality of their system.

The general strategy applied here is to move all the code that accesses and applies tenant context into a set of libraries. These libraries are then referenced by each of the components/services in your environment. This is precisely where AWS Lambda Layers comes into picture. In this Lab, we’ll look at how AWS Lambda Layers allows you to centralize your tenant aware libraries without impact the size or load-time of your SaaS application’s functions.

Hiding Away the Details of Multi-Tenancy

Before we dig into the AWS Lambda Layers, we first need to understand what it means to hide away the details of multi-tenancy. Let’s start by looking at a common microservice that might be part of our SaaS environment. The figure below provides a high-level view of some of the common components that might be part of my service implementation.

Here you’ll notice that we have our microservice at the center of this diagram. Within this service resides all the business logic and functionality that is within the scope of the microservice. Surrounding it are examples of common constructs that would often be shared by any microservice that would be part of our system. Logging, for example, has been included here to represent the common library that will be used to capture and publish our log messages. The metrics and analytics library, as its name suggests, is used to record any metric data that is associated with the service. At the top of the service, you’ll also see authorization/access. This library is used to acquire tenant context from an incoming request and validate/scope the caller’s access to the service’s functionality. Finally, you’ll notice that we have a Data Access library here as well. This is a common construct for many systems that want to create a standardized model for interacting with the underlying storage and/or database that is used by this service.

So far, there’s nothing particularly distinguishing about this model. However, if you take these same services and place them in a multi-tenant environment, you will find that each one of these services must now incorporate support for tenant context.

In this session, we’ll build a solution that leverages layers to implement logging and metrics in a multi-tenant serverless environment. We’ll demonstrate the use of these layers and how reusable constructs can streamline the experience for SaaS developers.

Setup Cloud9

If you are running this lab as part an AWS event, then the Cloud9 should already be setup in the AWS accounts provided to you by your instructor. Please skip this section if this is the case.

NOTE: This lab is meant to be run in us-east-1. Please make sure that you have selected "N. Virginia" as your region inside AWS Console.

If you are running this lab on your own, then follow these instructions to setup Cloud9 in your AWS account.

Step 1: Navigate to https://raw.githubusercontent.com/aws-samples/aws-serverless-saas-layers/master/Cloud9Setup/saas-cfn-cloud9-stack.yaml. This will display the contents of saas-cfn-cloud9-stack.yaml in your browser.

Step 2: Copy the contents of this file and save in your local machine as a file by the name of saas-cfn-cloud9-stack.yaml.

Step 3: You can now use this yaml file to create a new stack in your AWS Account. Name the stack as “saas-cfn-cloud9-stack”. Alternatively, you can use below command, if you have AWS CLI installed on your machine. This will automatically deploy the stack and eventually setup Cloud9 for you.

aws cloudformation deploy --template-file saas-cfn-cloud9-stack.yaml --stack-name saas-cfn-cloud9-stack

Lab1 – Starting with a single-tenant serverless solution

Lab2 – Code re-usability and multi-tenancy using AWS Lambda Layers

Lab3 – Collect metrices using a metrics manager

Lab4 – Data partitioning using Silo and Pool model

Proceed to Lab 1 when ready to begin.

License

This library is licensed under the MIT-0 License. See the LICENSE file.

aws-serverless-saas-layers's Issues

Stack create events stuck on CREATE_IN_PROGRESS

I'm running the lab in us-east-1, as recommended, using the instructions at https://github.com/aws-samples/aws-serverless-saas-layers.

I have a Cloud9 environment in us-east-1 that I'm running "aws cloudformation deploy --template-file saas-cfn-cloud9-stack.yaml --stack-name saas-cfn-cloud9-stack" from. The command completes in the Cloud9 terminal (as well as when run locally).

But resources are stuck on CREATE_IN_PROGRESS.

Any support is appreciated.

Matt

Lab 1 instruction incomplete - Deploy SAM

Deploying SAM in Lab 1 Step 2 is incomplete. The instructions or the script is missing that npm install needs to be executed in the order-manager and product-manager folders. This is quite user-unfriendly.

Steps to reproduce
User executes server-deploy.sh and follows instructions to set up Lambda functions.

Expected Result
Lambda functions should work and Lab 1 Step 3 should succeed.

Actual result
Lambda functions fail since dynamodb-doc is not found. The server-deploy.sh script and instructions do not mention anything of installing the resources locally before executing the script.

Lab1 Step 4 (load_simulator.sh) fails with ModuleNotFoundError: No module named 'requests'

Steps to recreate

I'm running this in my own AWS environment and successfully setup Cloud9 (us-east-1) and am getting through Lab1 Step 3 with no issues. The cloud9 environment, stack, and buckets are all up and running to that point.

At Lab1 Step 4 (load_simulator.sh) I get the following error:

Note: 'chmod' command works:

The command that fails

The error

Ultimately: ModuleNotFoundError: No module named 'requests' - in client/order-simulator.py and client/product-simulator.p

Troubleshooting to this point

1. I've run sudo pip install for 1) requests ("Requirements already satisfied: ...") and 2) pyjwt (no error when run) dependencies — so dependencies seem good. After re-running the load_simulator.sh the same error.
2. I've deleted the bucket and stacks and recreated the situation by using the root readme and lab1 readme instructions.
3. I've done step 2 (above) as well as deleting the Cloud9 instance and restarting from go with the same results. ;-) try'n here.

The ask

I'd appreciate any support as this is just the reference implementation I was looking (very hard) for.

Thanks,

Matt

Hi!

is there any related documents that what are you doing here? like aws-saas-factory-bootcamp.
i like to know what is your solution when you are using serverless approach inside saas layers,

thanks a lot :)