Skip to content

Instantly share code, notes, and snippets.

@santoshshinde2012
Last active March 25, 2022 09:01
Show Gist options
  • Save santoshshinde2012/671920fbb4a877438b76cd2e004d2078 to your computer and use it in GitHub Desktop.
Save santoshshinde2012/671920fbb4a877438b76cd2e004d2078 to your computer and use it in GitHub Desktop.
Resources to start with Multi-tenant Architecture

Resources to start with Multi-tenant Architecture

Introduction

Multi tenant architecture is an ecosystem or model, in which a single environment can serve multiple tenants utilising a scalable, available, and resilient architecture. The underlying infrastructure is completely shared, logically isolated, and with fully centralised services.

Creating a multi-tenant software-as-a-service (SaaS) application requires developers and architects to take new approaches to how they design, build, operate, and deploy their solutions. SaaS touches every dimension of your design, including how you decompose your system into services, how those services are built, how they are secured, how they store data, and how they are deployed.

This document helps you plan, design, and implement a multi-tenant architecture on Google Cloud by helping you choose between the following approaches:

  • Same runtime environment for multiple tenants.
  • One runtime environment for each tenant domain.
  • One resource container for each tenant domain.

This paper explains the multi-tenant architecture at Force.com that makes the Force.com platform fast, scalable, and secure for any type of application.

This article describes the various tenancy models available for a multi-tenant SaaS application.

  • SaaS concepts and terminology

    • Single-tenancy: Each database stores data from only one tenant.
    • Multi-tenancy: Each database stores data from multiple separate tenants (with mechanisms to protect data privacy).
    • Hybrid tenancy
  • How to choose the appropriate tenancy model

    • Scalability
    • Tenant isolation
    • Per-tenant cost
    • Development complexity
    • Operational complexity
    • Customizability

This article describes the various strategies and virtualization patterns for addressing multi-tenancy concerns.

  • Physical Separation
  • Virtualization
  • Design the application to be multi-tenant aware

Multi-Tenancy is one of the core features of ABP Framework. It provides the fundamental infrastructure to build your own SaaS (Software-as-a-Service) solution.

A common misconception holds that only physical isolation can provide an appropriate level of security. In fact, data stored using a shared approach can also provide strong data safety, but requires the use of more sophisticated design patterns.

This article describes the how to design multi-tenant architecture and advantages of it.

This article describes the multitenancy implementation with best practices.

Isolating tenant data is a fundamental responsibility for Software as a Service (SaaS) providers. If one of your tenants gains access to another tenant’s data, you lose trust and may permanently damage your brand or worse, lose your business.

Tenant isolation is one of the most fundamental aspects of SaaS architecture. Every SaaS provider must consider how to ensure that their tenant resources are isolated and secure. The challenge is that each resource type (compute, storage, etc.) requires different isolation approaches. In this session, we build a clear roadmap for navigating the landscape of isolation options, highlighting the strategies for achieving isolation spanning the different multi-tenancy models and AWS services. Our goal is to create a comprehensive view of the considerations that impact your approach to introducing isolation into your SaaS solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment