Transforming Your Monolith to SaaS with AWS SaaS Boost

By Tod Golding, Principal Partner Solutions Architect, AWS SaaS Factory

While the move to a software-as-a-service (SaaS) model is appealing to many organizations, the time, effort, and investment that’s required to transition to a new multi-tenant architecture can represent a significant hurdle.

For many, the move to SaaS includes ramping on new technologies, implementing multi-tenant constructs, creating new operational tooling, and adopting new billing constructs.

These barriers can be especially significant to those businesses that view the move to SaaS as key to their growth and future success. These companies are often looking for ways to accelerate their move to SaaS without absorbing the time, costs, and complexity of rebuilding or rewriting their applications.

To address this need, Amazon Web Services (AWS) has introduced AWS SaaS Boost, an open-source reference environment that provides developers with a low-friction way to transform existing applications into SaaS products.

In this post, I will look at the overall experience of getting your SaaS Boost environment up and running. I’ll also dig into the underlying architecture, multi-tenant deployment model, operational experience, billing integration, and core functionality supported in the SaaS Boost administration application.

The goal here is to introduce the core concepts. If you’re interested in learning more, explore the AWS SaaS Boost open source project on GitHub.

The Monolith-to-SaaS Mindset

Before we look at the details of AWS SaaS Boost, let’s start by looking at the conceptual model.

For this initial release of SaaS Boost, the focus is squarely on creating an environment that brings together all the elements of a ready-to-use SaaS architecture that can remove much of the heavy lifting commonly associated with migrating a solution to a SaaS model.

To understand this transformation, here’s a conceptual view of what it would mean to migrate your monolith into a SaaS offering. The diagram Figure 1 illustrates the before and after a move to SaaS Boost.

Figure 1 – Monolith into a multi-tenant environment.

On left side of the diagram, you’ll see a classic software deployment model where each customer operates in a standalone environment. They may be deployed in the cloud, or they may be on-premises.

The key observation is that each tenant is managed and operated separately. Typically, customers in these environments will be running a range of product versions as well.

While this approach may simplify early adoption, it begins to create real problems as a business grows. As more and more customers are onboarded in this model, companies begin to face challenges with operational efficiency, cost, and agility. Ultimately, this ends up impacting an organization’s ability to scale and innovate.

To address this need, AWS SaaS Boost allows organizations to take their existing monolithic applications and drop them into a fully managed, multi-tenant aware environment (shown on the right side of Figure 1). Now, as the monolith moves into this pre-built SaaS architecture, all tenants will be managed and operated through a unified experience.

Onboarding of tenants, for example, is fully automated by the SaaS Boost environment. The idea is to make this transition as frictionless as possible, allowing an organization to plug their application into an environment that includes all elements needed to manage and operate a SaaS solution.

Tenant management, tenant deployment, tenant aware analytics, billing, and metering are all wired up and ready-to-use when you drop your application into SaaS Boost. This allows a business to more immediately offer their product to the market in a SaaS model without absorbing the overhead of rebuilding their solution.

The notion of acceleration is at the core of the SaaS Boost value proposition. It enables a business to get to a SaaS model as quickly as possible. Then, you can think about how (or if) you might want to further modernize your solution.

Developer Experience

Now that you understand the basics, let’s look at how you can bring AWS SaaS Boost to life and start using these capabilities. The diagram in Figure 2 outlines the high-level steps that are involved in getting your SaaS application moved into a SaaS model.

Figure 2 – The SaaS Boost flow.

1. The first step is to download the code from the SaaS Boost repository. While SaaS Boost provides a streamlined process that requires no development, we also know developers may want to modify or augment the experience based on their needs. In fact, the evolution of SaaS Boost will very much be driven by a mix of AWS insights and community contributions.
   .
2. After the code is downloaded, you’ll run the installation process to install and set up SaaS Boost in one of your AWS accounts.
   .
3. Next, you’ll configure the overall settings unique to your environment. Here, you’ll set up the ports, domain, database settings, billing and metering configuration, and so on.
   .
4. At this point, the basics of your SaaS Boost are in place. Now, you can focus more on packaging and deploying your monolithic application to SaaS Boost. This requires developers to containerize their existing application and upload that container image to AWS.
   .
5. With your application uploaded and your environment configured, you can now begin to use the automated tenant onboarding feature of SaaS Boost. This onboarding process configures all the moving parts of each tenant environment.
   .
6. The last step represents the management experience of SaaS Boost. Once your tenants are deployed and running, you can use the management capabilities of the SaaS Boost application to manage tenant environment and use analytics views to assess the activity of the tenants using your system.

What Gets Provisioned with SaaS Boost

Now that you have a feel for the experience, let’s look at what gets deployed when you install the SaaS Boost environment. The diagram in Figure 3 provides a conceptual view of the core components that get provisioned when you set up a SaaS Boost environment.

Figure 3 – High-level SaaS Boost architecture.

The management and core services of SaaS Boost are built using a serverless application model using AWS Lambda. The admin application is built with React and hosted using Amazon Simple Storage Service (Amazon S3) and Amazon CloudFront.

This application authenticates admin users with Amazon Cognito. The application is also integrated with backend services via REST calls that are routed to a series of microservices that are responsible for much of the SaaS Boost heavy lifting.

On the right side of the diagram in Figure 3, you see a representation of an application. This is a placeholder for your application, which can interact with SaaS Boost services via the Amazon API Gateway.

You’ll notice this application also includes integrations with billing and analytics. While SaaS Boost includes these services as part of the core system, the details of what gets metered/billed, or which metrics you produce, will be different for each SaaS application. This means you’ll need to add the code to your application to publish these events.

Configure Your Application Settings

Once SaaS Boost is installed and running, you’ll need to log in to the SaaS Boost admin application and configure the specific attributes of your SaaS environment. This is where you configure the ports, domains, compute settings, databases, file systems, and billing options that are unique to your application.

This application configuration data is essential to the deployment footprint of each tenant that will be running in your system. As such, this configuration must be completed before any tenants are on-boarded to your system.

Figure 4 provides a snapshot of the application configuration page that is used to configure these options in the SaaS Boost admin application.

Figure 4 – Configuring your SaaS application.

Onboarding Tenants

The value of SaaS Boost becomes clearer when you begin to onboard tenants. This is where the multi-tenant nature of SaaS Boost represents a fairly significant contrast to a traditional, one-off deployment model of classic software applications.

With SaaS, we’re intentionally moving away from the “installer” mindset where an application is often installed and configured for each customer. In a multi-tenant environment, this shift is toward a model where there’s a single, unified environment that hosts all of your customers.

New tenants are then introduced into this environment through a frictionless onboarding process that orchestrates everything needed to get that new tenant up and running. This low-friction experience is fundamental to enabling a SaaS business to grow and accept new tenants at a rapid pace with zero operational intervention.

In this mode, onboarding is more of an end-user facing experience that collects the tenant’s configuration options and launches the onboarding process. The onboarding automation then configures of all the tenant’s elements in a repeatable, scalable manner.

The diagram in Figure 5 provides a view of some of the moving parts of the SaaS Boost onboarding experience.

Figure 5 – Onboarding tenants.

1. In this flow, we’ve included the upload of your application as part of the overall onboarding process (Step 1). This is because the first provisioning of any tenant cannot proceed without first having an instance of the application that will be deployed for that tenant.
   .
2. You’ll also need to configure your application settings before onboarding a tenant. This is represented by Step 2 where the settings microservice is updated with the application configuration data.
   .
3. After the application is uploaded, you can trigger the onboarding experience (Step 3a). The SaaS Boost admin application includes an onboarding experience. This built-in onboarding mechanism allows you to configure the new tenant settings and launch the onboarding process.
   .
   This onboarding flow is provided for those companies that may not want to offer a self-service experience. If you’d prefer to use a self-service onboarding experience, you can add that page to your application and trigger the onboarding from your application (Step 3b).
   .
4. While there are many moving parts to the onboarding service, the key item here is the provisioning of tenant environments. In Step 4 you’ll see that SaaS Boost includes all the automation and AWS CloudFormation scripting needed to create the infrastructure for a new tenant environment.
   .
5. This new tenant is deployed to your unified SaaS environment (Step 5), configuring all the routing and infrastructure constructs needed to allow this tenant to be managed and operated by the SaaS Boost environment.
   .
   To make the SaaS Boost environment as frictionless as possible, you’ll see that each tenant is deployed in what is called a “silo” model where each tenant has its own stack of resources. While it limits some of the cost efficiency that comes with fully shared multi-tenant infrastructure, this silo model allows existing applications to move into SaaS Boost without rewriting the system.
   .
   Fortunately, since the tenants are managed through a single experience, this model still enables SaaS organizations to realize many of the operational efficiency benefits of SaaS.
   .
6. The last piece of the onboarding puzzle is billing integration. Here, the onboarding experience creates a new customer within the billing system and enables organizations to begin to bill customers based on their desired billing model (Step 6).

Tenant Environment Architecture

To get a better sense of what’s going on under the hood, let’s take a detailed look at how tenant environments are realized on top of AWS. The diagram in Figure 6 provides a view of some of the architectural elements that are provisioned to support tenants.

Figure 6 – Tenant architecture.

Looking at this diagram from the top down, you see that two tenants have been provisioned in the SaaS Boost environment. Each is provisioned with a separate sub-domain that’s used to route them to their underlying architecture.

In this case, Amazon Route 53 is used to route to the separate virtual private clouds (VPCs) that have been created for each of our tenant environments. All of the resources needed for a tenant are represented within that tenant’s VPC.

Your application will be deployed into an Amazon Elastic Container Service (Amazon ECS) cluster. The tenant workloads hosted in each of these clusters will be scaled separately.

The diagram above also includes placeholders for the database and/or file system that may be required to run your application. The specific resources your application will need are set up during the application configuration process described above.

Deploying Application Updates

Now that your tenants are running in a multi-tenant environment, you have to think about how you’ll deploy application updates to those tenants. As part of aligning with the overall value system of SaaS, you’ll want to be sure application updates are applied to all tenants through a single deployment process.

SaaS Boost takes over this responsibility for you, removing the need to write your own DevOps deployment tooling for your application deployments.

Whenever a new version of your application is uploaded to the SaaS Boost environment, it will automatically deploy this update to all tenant environments.

Billing Integration

The move to SaaS often comes with a move to a new billing model. Companies may be, for example, shifting from a long-term contractual billing model, to a subscription and/or consumption-based billing model.

Figure 7 – Billing integration.

To support this transition, SaaS Boost includes support a SaaS billing. This provides a ready-to-use billing solution that’s integrated with a third-party billing service (in this case, Stripe). This puts the moving parts in place while still allowing you to modify SaaS Boost to support an alternate billing provider.

The fundamentals of this billing experience are shown in Figure 7. The basic flow starts with creating your account in Stripe and getting an API key (Steps 1 and 2). After that, you’ll configure the API key through the SaaS Boost admin application (Step 3). This triggers the setup of your application’s products or billing units (Step 4).

To connect all the dots of the billing experience, you’ll need to publish billing events from your application (Step 7). The nature of these events will vary based on the billing model you’ve selected. As each event is published, the billing system will resolve that to a specific subscription before sending the billing event to Stripe (Steps 8 and 9).

Operational Analytics

To run a successful SaaS business, you need operational views into your environment that allow you to understand how tenants are exercising your environment. These tenant-aware insights provide data that can identify tenant health issues or tenant trends that may influence how you manage and evolve the configuration of your SaaS Boost environment.

To support this need, SaaS Boost includes a series of tenant-focused graphs that are used to analyze tenant trends. The diagram in Figure 8 provides a sample view of a few of the graphs that are part of the built-in analytics capabilities included with SaaS Boost.

Figure 8 – Built-in analytics.

SaaS providers also tend to need to collect a broad range of metrics that are custom to their environment. To support this need, SaaS Boost enables integration with pre-provisioned infrastructure that can aggregate and surface these custom metrics views using Amazon QuickSight.

Getting Started and Looking Forward

It’s important to note this release of SaaS Boost is meant to provide a starting point for moving your solution to a SaaS delivery model. Some may be able to move their application to SaaS Boost with minimal effort. Others may choose to dig into the source code and shape the solution into a model fits their specific needs.

Beyond this first version, the SaaS Boost team will be looking to the community to drive the evolution of this offering. It will likely expand to support additional paths of modernization and support for more shared infrastructure and microservice-based strategies.

Explore the SaaS Boost open source project on GitHub and help guide its path forward.

About AWS SaaS Factory

AWS SaaS Factory helps organizations at any stage of the SaaS journey. Whether looking to build new products, migrate existing applications, or optimize SaaS solutions on AWS, we can help. Visit the AWS SaaS Factory Insights Hub to discover more technical and business content and best practices.

SaaS builders are encouraged to reach out to their account representative to inquire about engagement models and to work with the AWS SaaS Factory team.

Sign up to stay informed about the latest SaaS on AWS news, resources, and events.