SaaS Factory (The Series) — Data Partitioning: Storage Strategies in SaaS (Part 2/3)

In this post, we'll talk about Data Partitioning and Storage Strategies in SaaS.

Finding the right fit

Selecting a multi-tenant partitioning storage model strategy is influenced by many different factors. If you're migrating from an existing solution, you may favor a silo model because it offers the simplest, cleanest way to transition to multi-tenancy without rewriting your SaaS application. If you have regulatory or industry dynamics that demand a more isolated model, the efficiency and agility of the pool model may still open your path to an environment that embraces fast, continuous releases. The key here is to recognize that the strategy you select will be driven by a combination of business and technical considerations in your environment.

Evaluating Trade-offs

If you placed the three partitioning models — silo, bridge and pool — on a spectrum, you'd see the natural tensions associated with adopting any one of these strategies. The qualities listed as strengths for one model are often represented as weaknesses in another. For example, the principles and value system of the silo model are often in opposition to those of the pool model.

*Trade-offs across the partitioning models*

Data access models

For many organizations, choosing a strategy is not as simple as selecting the silo, bridge or pool model. Your tenants and your business will have a significant influence on how you approach selecting a storage strategy. In some cases, a team may identify a small collection of its tenants that require the silo or bridge model.

Once they've made that decision, suppose they feel they have to implement all storage with that model. That artificially limits their ability to embrace tenants who might be open to a pool model. In fact, it may add cost or complexity for a tier of tenants that don't require the attributes of the silo or bridge model. One possible compromise is to build a solution that fully supports “pooled” storage as its foundation. Then you can create a separate database for the tenants that require a siloed storage solution. The Figure provides an example of this approach in action.

*Data access models*

Migration and multi-tenancy

Each of the multi-tenant storage models requires its own unique approach to handling data migration. In the silo and bridge models, you can migrate data on a tenant-by-tenant basis.

Your organization may find this appealing because it lets you carefully migrate each SaaS tenant without exposing all tenants to the possibility of a migration error. However, this approach can introduce more complexity into the overall orchestration of your deployment lifecycle. Data migration in the pool model can be both appealing and challenging. Migration in a pool model gives you a single point at which, once migrated, all tenants have successfully transitioned to your new data model. On the other hand, any problem introduced during a pool migration can affect all of your tenants.

From the start, you should think about how data migration fits into your overall multi-tenant SaaS strategy. If you build this migration orchestration into your delivery pipeline early, you tend to achieve a greater degree of agility in your release process.

Minimizing Invasive Changes

As a general rule, you should have clear policies and principles to follow when considering how the data in your systems will evolve. Whenever possible, teams should favor data changes that are backward compatible with previous versions. If you can find ways to minimize changes to your application's data representation, you'll limit the high overhead of transforming your data into a new representation.

Security considerations

Data security must be a priority for SaaS providers. When adopting a multi-tenant strategy, your organization needs a robust security strategy to ensure that tenant data is effectively protected from unauthorized access. Protecting this data and conveying that your system has employed the appropriate security measures are essential to earning the trust of your SaaS customers.

The storage strategies you choose will likely use common security patterns supported on AWS. Encrypting data at rest, for example, is a horizontal strategy that can be applied universally across any of the models. This provides a foundational level of security that ensures that — even if there is unauthorized access to the data — it would be useless without the keys needed to decrypt the information.

Isolation and Security

Support for tenant isolation is fundamental for some organizations and domains. The notion that data is kept separate — even in a virtualized environment — can be seen as essential by SaaS providers that have specific regulatory or security requirements.

As you consider each AWS storage solution, think about how isolation is achieved in each of the AWS storage services. As you'll see, achieving isolation in RDS looks very different from how it's done in DynamoDB. Consider these differences as you select your storage strategy and assess your customers' security considerations.

Management and Monitoring

The approach you take to multi-tenant storage can have a significant impact on the management and monitoring profile of your SaaS solution. In fact, the complexity of — and the approach you take to — aggregating and analyzing system health can vary significantly for each storage model and AWS technology.

Aggregating storage trends

To build an effective operational view of SaaS storage, you need metrics and dashboards that provide an aggregated view of tenant activity. You need to be able to proactively identify storage trends that may be influencing the experience across all of your tenants. The mechanisms you need to build this aggregated view look very different in the silo and pool models.

With siloed storage, you must put tooling in place to collect data from each database and display that information in an aggregated model. In contrast, the pool model, by its nature, already has an aggregated view of tenant activity.

Tenant-centric views of activity

Your storage management and monitoring solution should provide a way to build tenant-centric views of your storage activity. If a given tenant is experiencing a storage problem, you'll want to drill into storage metrics and profile data to identify what might be affecting that individual tenant.

Here, the silo model aligns more naturally with building a tenant-centric view of storage activity. A pooled storage strategy will require some tenant filtering mechanism to extract the storage activity for a given tenant.

Policies and Alarms

Each AWS storage service has its own mechanisms for assessing and tuning your application's storage performance. Since storage can often represent a major bottleneck in your system, you should introduce monitoring policies and alarms that let you surface and respond to changes in your application's storage health.

The partitioning model you choose will also affect the complexity and manageability of your storage monitoring strategy. The more isolated your solution, the more moving parts there are to manage and maintain on a tenant-by-tenant basis. On the other hand, the shared nature of a pooled storage strategy makes it simpler to have a more centralized, cross-tenant collection of policies and alarms.

The overall goal of these storage policies is to implement a set of proactive rules that can help you anticipate and react to health events. As you select a multi-tenant storage model, consider how each approach may influence how you implement your system's storage policies and alarms.

In the next post, we'll continue talking about data partitioning architectures: storage strategies in SaaS.

SaaS Factory (The Series) — How to Build Software as a Service Solutions on AWS

See you then! =)