Single-Tenancy and Multi-Tenancy in a SaaS Application

Introduction

• The speaker, Pujjard, is a Senior Solution Software Engineer at Postel, the Dutch national Postal Service.
• He is an AWS Community Builder and will be discussing the concepts of single-tenancy and multi-tenancy in a SaaS application.

Theoretical Concepts

Single-Tenancy

• In a single-tenancy approach, each consumer (tenant) has dedicated resources in the application, such as compute, data, and configuration.
• Advantages:
  • Enhanced security
  • High resilience
  • Customization per tenant
• Disadvantages:
  • Higher cost
  • Scaling challenges
  • Longer deployment times
  • Maintenance difficulties

Multi-Tenancy

• In a multi-tenancy approach, multiple consumers (tenants) share the same resources in the application.
• Advantages:
  • Cost-effective
  • Easier scaling
  • Faster deployment
• Disadvantages:
  • Noisy neighbor issue (one tenant using the shared resource heavily, affecting others)
  • Requires balancing resource usage among tenants

Use Case: Postel's Event Broker Application

About Postel

• Postel is the largest logistics provider in the Benelux region, delivering 6.9 million mail items and 1.1 million parcels per day.
• They have over 70 in-house developed applications, including an event broker SaaS application called "Ebe" (Event Broker).

Ebe Application Architecture

• Ebe uses EventBridge as the main component to route messages between producers and consumers.
• Producers can be SQS or HTTPS, and consumers can be SQS, HTTPS, or private HTTPS connections.
• Each producer and consumer are deployed as individual CloudFormation stacks, following a single-tenancy approach.

Challenges with Single-Tenancy Approach

• Longer deployment times (around 8 minutes per stack)
• Upgrade challenges (2 hours to upgrade all stacks)
• Resource limitations (throttling in CloudFormation API, CodeDeploy, and API Gateway)
• Higher fixed costs (per-stack CloudWatch alarms, KMS keys, etc.)

Migration to Multi-Tenancy

Constraints

• No downtime is allowed for this mission-critical application.
• Minimal involvement from producers and consumers during the migration.

Approach

1. HTTPS Producer Migration:

   • Replaced individual producer endpoints with a proxy endpoint.
   • Replaced individual producer-specific Lambda functions with a shared Lambda function.
   • Used a DynamoDB table to store producer configurations.

2. SQS Producer Migration:

   • Created a shared Lambda function to process messages from all producer SQS queues.
   • Used the DynamoDB table to store producer configurations.

3. SQS Consumer Migration:

   • Extracted compute resources (Lambda functions) from the consumer stacks.
   • Kept only the necessary infrastructure (SQS queues, alarms) in the consumer stacks.
   • Created a shared Lambda function to process messages from all consumer SQS queues.
   • Used a DynamoDB table to store consumer configurations.

Results

Benefits of Multi-Tenancy Approach

• Faster deployments (down to 1 minute)
• No need for complete redeployment during software upgrades (only shared components updated)
• Reduced costs (no per-stack CloudWatch alarms, KMS keys)
• Better Lambda utilization and optimization opportunities

Addressing Disadvantages

• No strict compliance requirements for the Ebe application
• Minimal customization needed per producer or consumer (handled through configurations)
• Addressed the noisy neighbor issue by adjusting the Lambda concurrency

Conclusion

• Single-tenancy is a great starting point, but multi-tenancy can be beneficial when facing scaling and cost challenges.
• The right approach depends on factors like compliance requirements, customization needs, and growth projections.
• Revisiting the architecture and making improvements is crucial to get the best results.