Palani works as a Senior Architect in the Cloud Engineering Studio division of Brillio. He has deep expertise in multi-cloud initiatives for large enterprises.
A continuation of part two of the blog.
AWS provides several cloud-enabled solutions, which in effect, can be utilized as the following SaaS deployment models:
Tenant Isolation at the Container Layer
Containerization platforms such as Docker or Kubernetes use containers to isolate the application and data within its context.
By design, different workloads can share the same cluster, with some level of logical or physical isolation between them. In this model, all the deployments for tenant solutions are in the same AWS account, but the level of separation is at the namespace level.
We can achieve tenant isolation for each tenant application by using namespaces. The SELinux runtime environment provides a separate namespace for every tenant deployment. This ensures a logical separation between tenants. The stack consists of Kubernetes operators as the runtime that manages the application and an application custom resource instance and a database custom resource instance.
AWS provides containerization through several services such as AWS ECS (Elastic Container Service), EKS (Elastic Kubernetes Service), and AWS Fargate. In the case of Kubernetes, multi-tenancy can be achieved by leveraging namespaces and a Platform-as-Code approach to build a multi-tenant SaaS solution on a Kubernetes cluster.
In the realm of physical isolation, multi-tenant PaaS solutions can provide the orchestration power of Kubernetes and the runtime isolation through namespaces to build a secure multi-tenant platform. Rancher, a multi-tenant Kubernetes as a service solution, is a good example of such a service.
Rancher can be used to deploy multiple containers separated by namespaces, with groups of applications and databases combined in a database-per-service design pattern.
Tenant Isolation at the Data Layer
At the database level, an application requiring a multi-tenancy architecture can adopt one of the following database architectures. In a typical 3-tier application having shared web and application layers, minute variations can exist at the database layer. The following figure shows possible multi-tenant architectures, assuming that existing applications may have to be re-architected in a tenant-aware fashion. AWS provides its portfolio of compute and database services for this purpose.
a) Instance Isolation: The first design involves complete isolation of the application’s compute instance as well as the associated database. The design will require the most compute and storage and can have customized security policies, user interfaces, and database design. However, this may be much more costly and difficult to maintain. Further, depending on certain compliance and security requirements, co-hosting tenants with different security profiles may not be possible. AWS provides this by design, with its current web service offering.
b) Single Instance, Separate Databases: Each tenant will have a different database for maximum isolation. To enable the application layers to pick the right database upon each tenant’s request, it would be required to maintain metadata in a separate store (such as Amazon DynamoDB) where the mapping of a tenant to its database is managed.
c) Single Database, Separate Tables/Schemas: Different database flavors have different constructs, but another possible deployment model could be that each tenant’s data resides in the same database. However, the data is tied to different schemas or tables to provide a level of isolation.
d) Single Database, Shared Schema/Tables: In this model, each tenant’s data is placed together. A unique tenant ID column separates data records for each tenant. Whenever a new tenant needs to be added to the system, a new tenant ID is generated, additional capacity is provisioned, and traffic routing to an existing or new stack gets initiated. Although difficult to architect, this is the most optimized architecture which results in economies of scale, higher resource usage, is easier to provision & maintain, and is a cheaper tenancy model with shared components. Its limitations are exposure and vulnerability to shared attack surfaces, lesser control over the environment and customizations, and that in the event of failures, all tenants can be affected.
Multi-tenancy architecture allows organizations to efficiently serve customers from all strata, ranging from small and medium customers (whose scale may not require dedicated infrastructure) to large enterprises (that require access to the cloud’s virtually unlimited and indispensable resources). Shared software development and maintenance costs, reduce expenditure, leading to savings that are passed onto the customers.