Patterns for Deploying SaaS in Remote Environments

By Sunil Ramachandra, Sr. Solutions Architect – AWS
By Farooq Ashraf, Sr. Solutions Architect – AWS
By Peter Yang, Sr Partner Solutions Architect – AWS

In a software-as-a-service (SaaS) environment, the goal for SaaS providers is to offer their software truly as a service, hiding all of the implementation details from their tenants. In this model, the entire application is running on the SaaS provider’s infrastructure.

There are models, however, where certain business or technical factors require the providers to host part of the application in their tenant’s infrastructure. This model where there is a shared ownership of application infrastructure between provider and tenant, we have labeled as “SaaS Anywhere.”

SaaS is about achieving innovation and growth through efficient operations. SaaS application should be managed, operated, and scaled through a single management experience that increase this operational efficiency.

With a SaaS Anywhere deployment model, however, SaaS providers are challenged with the complexity of finding new and creative ways to control the remote resources without compromising these core SaaS values. With this in mind, SaaS provider needs to carefully consider which resources absolutely need to run in a remote environment when thinking about adopting a SaaS Anywhere strategy.

In this post, we are going to talk about three SaaS Anywhere patterns that we have identified. We are going to review some of the key business drivers and considerations associated with each of the patterns. Lastly, we’ll discuss some challenges to consider when operating and managing a solution with a SaaS Anywhere deployment model.

Control Plane and Application Plane

Before we go into patterns, it’s important for us to first talk about the two fundamental parts of a SaaS solution, the control plane and application plane. The control plane is a set of shared services the SaaS provider uses to manage, operate, and analyze a multi-tenant SaaS solution. The application plane is the part of the application the end users will interact with. This is where the application functionalities of your SaaS solution live.

With SaaS Anywhere, we’ll look at patterns on how the resources of the application planes can be deployed and operated in remote environments. It’s important to note that, even though the application plane can be architected to run fully or partially in a remote environment, the control plane in the SaaS provider’s account should still be the set of shared services that manages all instances of the application plane.

Common Considerations

Each SaaS Anywhere deployment pattern comes with its own set of tradeoffs and considerations. We’ll get into those as we cover each pattern, but there are some considerations that are common to the patterns. These include:

• Availability and reliability become a shared responsibility between the SaaS provider and the tenant. The SaaS provider has clear control over the resources running in its environment and can manage the availability and reliability of these resources. Tenants, however, may also assume some level of control over resources running in their environment. This means the tenant can own some responsibility for the uptime and resilience of these resources.
• Frictionless onboarding is essential for a SaaS solution and this does not change with SaaS Anywhere. However, it gets more complicated because of the introduction of an external dependency on the remote environment and the permissions needed to complete the onboarding process. SaaS providers need to consider how/where their onboarding automation code will provision and configure any remote resources. This could include storage/compute provisioning, network configuration, setup of AWS Identity and Access Management (IAM) roles, and so on. The goal here is to ensure the appropriate resources can be provisioned in these remote settings.
• Cross-account observability will be critical with a SaaS Anywhere deployment. With services running in remote environments, it is important for the SaaS provider to establish a method for publishing observability data from remote environments back to the control plane, where the data can be monitored, aggregated, and analyzed.

Now that we have covered some of the common considerations across the three patterns, let’s take a closer look at each pattern.

Distributed Data Store

In this delivery model, the control and application planes are deployed in the SaaS provider’s account(s) and some or all of the application data is deployed in the customer’s account. The diagram below (Figure 1) provides an example of this pattern.

Figure 1 – Distributed data store.

This model could be a consideration when it’s prohibitive to transfer the customer data. One scenario is when the customers of the SaaS providers are in a highly regulated industry where data has to stay with the customer. Another scenario is when the amount of data is so large and it’s not optimal to be moved between environments.

Ideally, a SaaS solution has a set of microservices and each microservice should have their corresponding data store instead of one data store for the entire application. This means SaaS providers should have the flexibility to configure remote storage for specific microservices, instead of the entire application.

With the distributed data store model, your tenant can now control of these remote storage resources. Administration tasks, such as database backup, database performance, and database security, could become the tenant’s responsibility.

A pertinent example of this model is that of cloud services like Amazon Security Lake, AWS HealthLake, AWS HealthOmics, where a central repository of highly controlled datasets is owned and controlled by customers. In this scenario, data could be stored in the tenant’s account and accessed via the application running in the SaaS provider’s account.

In the sample architecture below (Figure 2), the SaaS provider hosts the control plane and application plane in their own AWS account. Some or all of the tenant’s data live in the tenant’s AWS account. To enable the SaaS provider to access the customer’s Amazon DynamoDB database, for example, an IAM cross-account role is used. This allows the SaaS provider to assume a role in the customer’s account, granting permission to connect to and perform operations on the Amazon DynamoDB database.

By separating the accounts, the customer retains ownership and control of their data while enabling the SaaS provider access to perform service actions. The cross-account role sets the appropriate permissions for the SaaS provider to carry out their duties without excessive access to the customer’s environment.

Figure 2 – Sample architecture for distributed data store model.

Distributed Application Plane

In the distributed application plane model, the control plane and part of the application plane are deployed in the SaaS provider’s account, while some of the application plane services are deployed in the customer’s account. The diagram below illustrates this model.

Figure 3 – Distributed application plane.

The distributed application plane model could be a consideration when the customers have large amounts of data that need to be transferred. The SaaS provider can deploy remote application services in the end customer’s environment to interact with remote resources and communicate with application services running in the SaaS Provider’s account.

This enables the SaaS provider to selectively deploy certain services remotely while keeping the rest of the application plane in their own account. This lets you move those services that make sense to move.

In this model, the customer is now also responsible for the resources needed to support the compute and storage of these remote services. With parts of the application plane now deployed across different environments, the customer will also need to ensure that these remote services are protected, resilient, and accessible to the SaaS providers. The rest of the application still runs in the SaaS provider’s cloud account. This allows optimizing for performance and cost by only putting the minimal services in the customer’s environment.

In the sample architecture (Figure 4), the control plane and part of the application plane are running in the SaaS provider’s AWS account. In the customer environment, there are remote application services deployed by the SaaS provider which can process data and execute actions with remote resources. For example, a remote service can run product-related tasks in the environment it’s deployed in and eventually send metadata back to the SaaS provider environment.

Figure 4 – Sample architecture for distributed application plane.

Remote Application Plane

In the remote application plane model, the control plane is deployed in the SaaS provider’s account and the entire application plane is deployed in the tenant’s account. The figure below (Figure 5) provides an example of this pattern.

Figure 5 – Remote application plane.

The remote application plane model could be an option when tenant, domain, and/or security requirements create a need to host application resources remotely. Since all of your application resources are deployed in the tenant account, the tenant will also have a share in the responsibility for the securing these resources. Even in this scenario, the SaaS provider would still employ a centralized control plane to manage these remote tenant application planes.

In the sample architecture shown below (Figure 6), the application plane is running in the customer’s account and connects to the control plane running in the SaaS provider’s account. Specifically, the Amazon Elastic Kubernetes Service (Amazon EKS) cluster deployed in the customer’s account communicates with the control plane in the SaaS provider’s account. The microservices in the EKS cluster have access to datasets residing in the customer’s account.

By having the control plane in the provider’s account and the application plane in the customer’s account, this architecture separates the management layer from the application layer across accounts. This allows the provider to manage the platforms while keeping tenant resources isolated in the customer’s environment.

Figure 6 – Sample architecture for remote application plane.

Conclusion

In this post, we covered some common considerations associated with deployment resources in a remote environment, such as the impact on onboarding new tenants and the shared responsibility for managing those remote resources. We also outlined three different deployment models, along with a sample architecture for each model.

If you’re designing a SaaS solution with services running in a remote environment, you should carefully consider the business goal you are looking to achieve and determine if SaaS Anywhere is the right approach for their solution. If SaaS Anywhere is necessary, you should identify which model is the appropriate model and minimize the remote footprint to what is necessary in order to achieve your goal without compromising the agility and speed of innovation for the SaaS solution.

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. ­­

Explore today resources for any stage of your SaaS journey from design and build, to launch and optimization.