Editor’s note: For the latest information, visit the .

By Tod Golding, Partner Solutions Architect at AWS

Most software companies understand the importance of being customer focused. The adoption of agile software development practices was heavily influenced by the needs of software organizations to connect to, and focus on, the continually evolving needs of their customers.

Now, take this basic reality and imagine how it manifests itself in the world of SaaS (software as a service) applications. With SaaS, your customers may be running in a fully shared environment, and the stakes are even higher. The real challenge for SaaS providers is to leverage the power and value of having a shared environment while accommodating the diversity of their customers’ needs. Striking a balance between these often-competing forces is essential to SaaS solutions.

Building an application that accommodates this level of flexibility and diversity requires diligence. The implications can be very pervasive and can affect multiple dimensions of your SaaS strategy. Ultimately, how you approach this opportunity is likely to directly influence the agility of your offering and its ability to align with the needs of your customers. The approach you choose will certainly have some impact on your ability to respond to market dynamics and competitive challenges.

The need for tenant-driven agility also highlights the intertwined nature of business and technology in SaaS environments. SaaS demands a design, architecture, and deployment vision that enables and supports the ability of your business to offer customers options that align with their specific needs.

In this blog, we’ll look at some of the considerations that go into capturing data on your tenants with an emphasis on identifying some of the key areas that could shape your system’s architecture. The landscape of possibilities here is broad, and my hope is to provide a glimpse of some of the factors that you may include in a broader assessment of your tenant profile.

Assessing Tenant Needs

Developing a tenant profile is all about understanding the value systems and domain forces that will influence a customer’s willingness to adopt your SaaS solution. Your ability to understand and categorize customer needs can help determine how and where you might need to support tenant variations in your underlying design and architecture.

Here are some of the typical questions that SaaS teams examine as part of this assessment:

• What are some of the security considerations that might influence your customer’s willingness to run in a multi-tenant environment?
• Are there specific standards or compliance criteria that must be met by some or all of your tenants?
• Are there tenants who may have specific data governance requirements?
• Are there other SaaS solutions that might be used in combination with this application?
• Are there tenants who will demand some level of isolation from other tenants?
• Are there tenants who will be willing to run in a fully shared environment?
• Are there optimizations, workflows, or product features that could be offered as value-added options?
• Are there any significant variations in how each tenant may need to respond to spikes in user load/activity?
• Do one or more tenants require customization of the application’s flow, business rules, appearance, and so on?
• Are there specific SLA requirements/expectations that may be imposed by some tenants?

This list is only meant to serve as a starting point. The nature of these questions is to tease out important traits that may distinguish the needs of specific tenants. Working through this list (and adding your questions) should give you a good sense of the range of options you may need to support in your solution.

Developing Tenant Personas

Once you have a well-understood list of tenant criteria, your next goal would be to determine how these criteria might be clustered together to represent different personas or families of tenants in your target audience.

This approach mirrors the agile concept of defining personas. The idea is to clearly capture and articulate the characteristics and requirements associated with each tenant type. As a part of this exercise, teams may assign tenant persona names that can be used as a common reference point for the broader team. The image below provides a simple example of how you might go about defining a persona.

Identifying personas should not be a heavyweight process. Invest enough energy to test yourself and the boundaries of your tenants’ requirements, but don’t iterate on this too long. You simply want to gather enough knowledge to ensure that you have identified the likely points of inflection in your SaaS architecture.

Aligning Architecture and Personas

The overarching goal of defining personas is to determine what values will shape the design of your SaaS application. Once you’ve identified your target personas, you’ll have the data points you need to determine the dimensions of flexibility and customizability you need to address with your underlying design.

While the personas for each SaaS application will vary, there are some common themes to consider as you begin to align your personas with your architecture. These themes often include isolation strategies, tenant policy management, metering models, and data access patterns. The sections that follow will explore how each of these areas can influence the design of your solution.

Tenant Isolation

Often, you can address the compliance and security requirements of your tenants by applying one or more isolation strategies. Tenants may require complete and total isolation from other tenants, or they may just need isolation at one particular layer or dimension of their environment.

The introduction of isolated tenants creates natural opportunities to define tiers of your product offering. Tenants who demand more isolation will easily understand how the value of that isolation justifies the costs associated with a higher-priced tier. Isolation also equips SaaS organizations with a mechanism for offsetting the increased costs associated with providing isolated infrastructure.

While you may have tenants who demand isolation, this does not mean every tenant will require an isolated solution. The challenge is to strike a balance between addressing the edge cases while continuing to offer shared, multi-tenant solutions where possible. The result is often a hybrid model where some tenants reside in a fully shared space while others are provisioned with some level of isolation.

The following diagram provides two examples of hybrid isolation models you can implement on Amazon Web Services (AWS). The image on the left depicts an approach that offers some tenants full isolation and others a shared environment. Tenants 1 and 2 presumably had requirements that warranted isolation and opted into this model, while the remaining tenants were willing to run in a shared environment.

The diagram on the right shows how you might implement a hybrid model, where isolation is achieved at different tiers of the architecture. The web tier is delivered as a shared environment while the application tiers are isolated for each tenant.

These are just two examples of isolation patterns. AWS provides constructs that can be leveraged to address a fairly diverse set of tenant isolation needs. The AWS stack includes account, networking, security, and storage constructs that enable a wide range of strategies for partitioning a tenant’s footprint. We won’t dig into each individual strategy in this post, but more information is available in the whitepaper.

Centralized Tenant Policies

One common way to address the varying needs of your tenant personas is to introduce a centralized model for managing tenant policies. Tenant policies enable you to customize many dimensions of the tenant experience. Performance, workflows, appearance, feature access, service-level agreements (SLAs)—all of these options can be potentially configured through tenant policies.

The design of your application directly influences the level of flexibility you’ll have in building and applying these policies. First, you’ll need to introduce a service that manages tenant configuration information. The diagram above provides a conceptual view of how these policies would be managed, acquired, and applied. Each tenant’s experience could be altered or shaped at any of the tiers of your application design based on the configuration of tenant policies.

Where this concept gets its power is in a number of levers and knobs you’ll have available to configure tenant workflows, performance, and so on. An application that has been decomposed into finer-grained services is going to allow for more granular control over the tenant experience, allowing you to support a wider range of tenant personas. The presence of these policies tends to put you in a better position to respond to new tenant needs that might surface as your product evolves.

The introduction of these tenant policies may also influence how you apply AWS constructs in your environment. You can imagine, for example, that a tenant policy might correlate to an Identity and Access Management (IAM) policy to control the visibility and control that is given to a tenant or one of the tenant’s users. Tenant policies also might shape the custom metrics that you capture with CloudWatch.

Metering Tenant Activity

In many cases, tenant personas are driven directly by consumption. To support these personas, you’ll need to design and instrument your application with mechanisms that will allow you to capture and aggregate a rich set of consumption metrics. These metrics should span all the moving parts of your system, allowing you to construct a comprehensive view of the infrastructure footprint being imposed by each tenant.

To create a complete metering picture of tenant activity, you’ll need to acquire data from multiple sources. The Amazon CloudWatch service is a good source for surfacing your tenant metrics. Amazon CloudWatch natively supplies access to consumption that spans most of the core metrics you’ll want to include in your tenant profile. It also supports the publication of custom metrics that correlate to your application’s features and functions. You might, for example, be able to determine that the use of a particular application feature directly correlates to a spike in disk or memory utilization.

In cases where you have isolated tenant infrastructure, you’ll want to think about how you might use tagging or separate accounts to identify resources that are associated with a specific tenant.

The last bit of metering you’ll need to consider is how (or if) you plan to apply policies based on tenant consumption. You’ll need to determine how your system will respond as tenants near or exceed consumption thresholds. You may choose to wire these policies up to Amazon Simple Notification Service (Amazon SNS) and to Amazon Simple Email Service (Amazon SES), for example. In some rare cases, SaaS providers might even disable portions of their application’s functionality when a tenant exceeds a threshold. The Amazon API Gateway’s throttling capabilities could be a good fit for this scenario. One common approach is to allow tenants to burst over their consumption threshold on a periodic basis and only enforce constraints when they being to exceed their limits on a more regular basis.

Data Access Optimization

Storage is not an area that gets a lot of attention when we think about personas and how we might distinguish tenants. Instead, we tend to view storage as an all-or-nothing proposition where all tenants get the same behavior. However, given the wide array storage options that are available on AWS, it makes good sense to consider how you might leverage these different storage models to support the different tiers of your SaaS system.

This concept connects directly to the tenant policies section described in the previous section. Through these policies, you can offer tenants different models for accessing and storing data. Combine this with the rich set of storage options available on AWS, and you have a fairly diverse set of options at your fingertips. You might support completely different storage options for tenants (RDS, DynamoDB, S3, Glacier, and so on). You might support separate policies for how data is archived and moved from one storage model to the next. Or, you might have separate throughput policies for each tenant. The range of options is very broad.

Cost is often a key motivator for optimizing data access. If your solution has a heavy storage footprint that is a significant portion of your tenant costs, then developing storage optimization strategies for different personas is an opportunity to align your costs with your tenant tiers.

Support Automation

Support represents another area where there is often variation among SaaS tenants. It’s natural for organizations to offer different levels of SLAs to different types of tenants.

In order to maximize your ability to support more demanding SLAs, you should think about how and where you may want to introduce automation that will trigger support activity. Your focus should be on proactively detecting issues and triggering the creation of support tickets. Each organization is going to have its own processes and models for driving support. The key is to determine what level of automation is needed, and what mechanisms may be used to detect and trigger the support model SLAs you’ve defined for each of your tenant personas.

AWS provides mechanisms that can assist with automating your support policies. You can use CloudWatch events, for example, to trigger a support workflow. Lambda functions could also be applied here to introduce any custom functions that would be used to automate your support process.

Applying YAGNI

The software development and agile communities have often advocated the YAGNI (you aren’t gonna need it) principle. This principle promotes the idea of designing only for the set of features and capabilities that you know are required today. The goal is to avoid investing in flexibility and generality that hasn’t yet earned its way into your solution.

You should consider this rule of thumb when you look at your personas and the needs you’re addressing with your solution. Yes, where possible, you’d like to accommodate generality that will promote and enable a range of tenant personas. At the same time, you don’t want to introduce abstractions or complexity that is not of immediate need or value to your current customers. You must find a way to strike a balance between architectural and design models that are enabling your business, and those that are simply laying a foundation for flexibility that may never be required.

As you think about decomposing your application into services and abstracting out tenant policies, you’ll likely find yourself right in the heart of the YAGNI challenge. Certainly, the more you lean toward more granular services and a more configuration-driven model, the more prepared you will be to support tenant variations. It’s all about finding the boundaries of what’s immediately useful, what’s just a good principle, and what might be overkill for your current needs.

Making Agility a Priority

As a SaaS solution provider, you should always consider agility and how your personas may or may not be influencing your ability to respond rapidly to customer feedback and changes in market dynamics. So, while you certainly want to embrace the varying requirements of your tenant personas, you also want to be sure that the level of customization and variation you’re accommodating doesn’t undermine the fundamental agility goals of your business.

This is especially relevant as you look at tenant isolation schemes. Typically, supporting isolation also means supporting more complex and potentially more fragile provisioning and deployment models. It also tends to limit your ability to roll out new features and capabilities rapidly. It can even affect the efficiency of your management and monitoring environments.

Leveraging AWS Services

AWS brings a rich collection of services to the SaaS domain, and provides a variety of different strategies to address the current and emerging needs of your SaaS customers. You can apply networking and account constructs to achieve multiple flavors of tenant isolation. You can use the continually evolving list of AWS storage options to offer tenants a range of different experiences. With Amazon Elastic Compute Cloud (Amazon EC2), Amazon EC2 Container Service (Amazon ECS), and AWS Lambda, you also have a diverse set of compute models that can influence the profile and footprint of your SaaS solution.

Summary

In this post, I’ve outlined the value of understanding the profiles of your tenants and aligning your design with the key points of variation for each tenant persona. Ultimately, your goal is to build a solution that offers clear, distinguished boundaries of value to each persona. You can then use these boundaries as a natural tool for creating product tiers that match the business needs of your customers with the broader cost considerations of your SaaS offering.

Whether you’re starting from scratch or evolving an existing SaaS solution, you should always have some sense of the current and evolving needs of your tenants. Even if you’re not formally tiering your product into separate offerings, you can still use your awareness of the range of tenant requirements to shape your architectural direction. Insights into your tenant profiles can lead you to new and interesting ways to leverage AWS services and capabilities in patterns that you may not have originally anticipated.