LazyStack

LazyStackSaaS Platform

Note - LazyStackSaaS is currently in Alpha with select partners. Beta release is expected in late June or early July. If you would like to try out LazyStackSaaS in the Beta program and receive direct support, please contact us. Support for beta users that agree to be reference accounts is free.

LazyStack manages the configuration and deployment of multi-tenant SaaS applications that follow the AWS Serverless Application Model (SAM). When deploying a SAM application we configure services instead of dedicated servers.

AWS provides hundreds of managed services. These services automatically scale, are distributed and highly secure. A typical SAM stack for a web application would use services like these:

Services
  • Cognito - user management, sign-up, sign-in, etc.
  • S3 - file storage at scale
    • SPA code bucket - the web application code to download to the browser
    • Assets bucket - content like images, configuration, videos etc.
  • ApiGateway - http endpoints that may call other services like Lambdas
  • Lambdas - event-driven compute service
  • CloudFront - content delivery network
    • orchestrate and optimize access to other AWS resources
    • cache content at internet edge-locations to minimize latency
    • improved security (adding tenantKey header to calls made to ApiGateway origins)
  • Database - NoSQL, NoSQL and Network databases as a service

The common theme across all these services is they are largely maintenance free once configured and deployed.

Simple SAM applications are usually deployed as a collection of AWS resources (services) called a "stack". SAM templates contain the stack configuration and are used by the CloudFormation tool to deploy the stack.

Complex SAM applications can be comprised of multiple stacks and access resources configured separately from any stack. Later on, we will see how this feature becomes important for multi-tenancy implementation.

Continuous Integration and Continuous Deployment (CI/CD)

It's important to manage updates to your client app and Lambda code. One simple way to do this is with the AWS CodeBuild service. This service can pull source code from your GitHub repositories, build the code, and deploy the complied code to the SPA code bucket and Lambda service.

Multi-Tenancy

Traditional SaaS Multi-Tenant architectures evolved to align service costs to the expected revenue on a tenant by tenant basis. The Serverless Application Model fundamentally changes the way we think about multi-tenancy because the use of AWS services inherently address this problem through service elasticity; which means that there is little to no charge for configured but idle resources. Here is a quick break down of the service elasticity pros and cons of commonly used AWS Services.

Service Pros Cons
Cognito Fully elastic. Large free tier allocation. None
S3 Fully elastic. Large free tier allocation. None
ApiGateway Fully elastic. Large free tier allocation. None
Lambdas Fully elastic. Startup time latency. Can be addressed using provisioned concurrency at additional cost.
CloudFront Fully elastic. None
DynamoDB Database Fully elastic. None
RDS Partially elastic. There are idle state charges.

In the following sections we describe a Serverless Application Model Multi-Tenant SaaS Architecture.

Serverless Application Model Multi-Tenant SaaS Architecture

When using SAM, it can be argued that it is possible to provision every tenant with their own stack. Then the problem is reduced to managing these stacks efficiently. While this is a viable approach, we believe there is still value in sharing some types of resources among tenants. These include the ApiGateways, Lambdas and client app code.

ApiGateway and Lambdas are convenient to define with a SAM template and deploy with CloudFront. This deployment process takes some time and as most tenants would use the same ApiGateway and Lambdas, there is no reason to do a separate deployment for each tenant. These "application service stacks" are one of the key resources shared by tenants. However, LazyStack has the ability to provision different application service stacks for different tenants to support use-cases like AB deployments, product options, and bespoke lambdas.

Web app client code is often compiled and/or packaged for deployment into a S3 SPA bucket. This can be a time consuming process and need not be performed for every tenant. Instead, tenants can be configured to share the same S3 SPA bucket. LazyStack provides CI/CD pipelines that allow the client app to be pulled from any GitHub repo and deployed with a customized CodeBuild script. This feature can be used to support use-cases like AB deployments, product options, and bespoke client apps.

LazyStack Multi-Tenant SaaS Platform Use-Cases

Sometimes an example is the best way to illustrate a concept and provide insight to new architectures. In the following sections we present examples of how tenants onboard with a hypothetical SaaS application, LazyMagic.net.

LazyMagic.net Magic Schools App

Are your teachers a little absent-minded, are your students losing their pets or aperating into the wrong class dungeons, are your ghosts acting up? If so, you need the the LazyMagic.com app.

LazyMagic allows your magic shool to create tenants for each magical house and tailor the app for that house's specific needs. Individual houses signup and use the Head of House App and Student App. Optionally, your school may signup and use the Headmaster and Teacher app to see activity across house apps. LazyMagic.net offers the following apps:

  • Headmaster app - used by a school head master.
  • Teacher App - used by teachers.
  • Head of House App - used by the Head of House.
  • Student App - used by students.

Tenants may also create their own tenant apps that use the secure APIs provided by the LazyMagic.net platform! LazyMagic.net will handle the deployment of these bespoke apps for you.

Breaking News! Hogwart's Ravenclaw house now using LazyMagic.

Ravenclaw on-boards as a LazyMagic.net tenant account. The following cloud service resources are automatically configured to support a Head of House and Student App for Ravenclaw.

Ravenclaw Tenant Configuration
  • The Head of House app is accessed using the hoh-ravenclaw.lazymagic.net subdomain
  • Ravenclaw is using the standard Head of House app and standard Head of House ApiGateway
  • The Student app is accessed using the ravenclaw.lazymagic.net subdomain
  • Ravenclaw is using the standard Student app and standard Student ApiGateway
  • Both apps share an isolated Ravenclaw database and content in the Ravenclaw assets bucket
  • Both apps are configured with Ravenclaw branding and Ravenclaw content drawn from the Ravenclaw assets bucket

Both applications have their own CloudFront Distributions and the CloudFront distribution determines which collection of service resources are available to the app.

LazyStack SaaS deployed the ApiGateways and associated Lambdas using SAM templates and CloudFormation. All other resources used in this tenancy were dynamically provisioned using calls to the AWS SDK.

Hogwart's Gryffindor house students build their own student app!

Not to be outdone, Gryffindor house is also using LazyMagic, and in their usual daring and courageous way have created their own bespoke student app using the secure and robust LazyMagic.net APIs.

Gryffindor Tenant Configuration
  • The Head of House app is accessed using the hoh-gryffindor.lazymagic.net subdomain
  • Gryffindor is using the standard Head of House app and standard Head of House ApiGateway
  • The Student app is accessed using the gryffindor.lazymagic.net subdomain
  • Gryffindor is using a bespoke Student app standard Student ApiGateway
  • Gryffindor is using GitHub and the LazyStack SaaS GitHub app to enable CI/CD of their client app.
  • Both apps share an isolated Gryffindor database and content in the Gryffindor assets bucket
  • Both apps are configured with Gryffindor branding and Gryffindor content drawn from the Gryffindor assets bucket

Both applications have their own CloudFront Distributions and the CloudFront distribution determines which collection of service resources are available to the app.

Hogwart's Headmaster, Dumbledore, reigns in the chaos!

Headmaster Dumbledore signs up for a Hogwarts school tenant and additional house tenants for Hufflepuff and Slytherin. The house tenants use their Head of House apps to give the Gryffindor tenant access to their isolated house databases. Since Hogwarts owns the Hogwarts.edu domain, this domain name is used instead of LazyMagic.net and all five tenants now use the hogwarts.edu domain.

Hogwarts Tenant Configuration
  • The Hogwarts.edu domain is used instead of lazymagic.net
  • Hogwarts choose to use the standard Headmaster app and standard HeaderMaster ApiGateway
  • Hogwarts choose to use the standard Teacher app and standard Teacher ApiGateway
  • The Headmaster app is accessed using the Headmaster.hogwarts.edu subdomain
  • The Teacher app is accessed using the teacher.hogwarts.edu subdomain
  • Both apps share an isolated Hogwarts database and content in the Hogwarts assets bucket
  • Both apps have access to the Ravenclaw, Gryffindor, Hufflepuff and Slytherin databases

Now teachers can add or subtract points from the houses and let student's know which dungeon to aperate into! Students and teachers can report ghosts that are acting up. Life is better at Hogwarts.

Hogwarts Configuration Overview

Tenant / App URL App AssetsBucket ApiGateway Database(s)
Hogwarts
Headmaster.hogwarts.edu
Standard
Headmaster App
Hogwarts HeadmasterApi Hogwarts
Ravenclaw
Gryffindor
Hufflepuff
Slytherin
Hogwarts
teacher.hogwarts.edu
Standard
Teacher App
Hogwarts TeacherApi Hogwarts
Ravenclaw
Gryffindor
Hufflepuff
Slytherin
Ravenclaw
ravenclaw.hogwarts.edu
Standard
Student App
Ravenclaw StudentApi Ravenclaw
Gryffindor
gryffindor.hogwarts.edu
Bespoke
Student App
Gryffindor StudentApi Gryffindor
Hufflepuff
hufflepuff.hogwarts.edu
Standard
Student App
Hufflepuff StudentApi Hufflepuff
Sytherin
sytherin.hogwarts.edu
Standard
Student App
Sytherin StudentApi Sytherin

Summary

In the LazyStack Multi-Tenancy SaaS platform, tenants are configured to use shared or isolated resources through service configurations. Each tenant app has its own CloudFront Distribution. Tenants are further configured for access to isolated or shared resources including:

  • SPA App - tenants may all share a standard App in a shared S3 bucket or have their own bespoke app in a S3 bucket only they can access
  • Assets - each tenant has a tenant specific assets S3 bucket containing branding, configuration and tenant specific content
  • ApiGateway - tenant apps may all access one of the standard ApiGateways or bespoke ApiGateways (with bespoke Lambdas) may be configured

Configuring all these resources manually would be a daunting and error prone task. LazyStack automates all this configuration and deployment to take maximum advantage of the AWS Serverless Application Model and deliver a scalable, secure and efficient multi-tenant SaaS application platform.