multi-tenancy

 Multi-tenancy is an architecture in which a single instance of a software application serves multiple

customers. Each customer is called a tenant.
 Tenants may be given the ability to customize some parts of the application, such as color of the user
interface (UI) or business rules, but they cannot customize the application's code.
 Cloud uses multi-tenancy to share IT resources, software and services in a cost efficient and secure way.
 Multi-tenancy can be economical because software development and maintenance costs are shared.
 It can be contrasted with single-tenancy, an architecture in which each customer has their own software
instance and may be given access to code.
 With a multi-tenancy architecture, the provider only has to make updates once. With a single-tenancy
architecture, the provider has to touch multiple instances of the software in order to make updates.
 In cloud computing, the meaning of multi-tenancy architecture has broadened because of new service
models that take advantage of virtualization and remote access.
 A software-as-a-service (SaaS) provider, for example, can run one instance of its application on one
instance of a database and provide web access to multiple customers. In such a scenario, each tenant's
data is isolated and remains invisible to other tenants.

Multi-tenancy has two aspects:

Internal: A company treats its departments as different tenants. This demands a logical isolation of
applications and infrastructure while sharing the physical infrastructure.
External: A service provider’s environment in which each tenant is a different company.
Eg: A financial company requires a dedicated infrastructure (physical isolation), while a retail company could
share infrastructure with other companies (logical isolation).
Factors such as security, reliability, scalability and serviceability play important roles in understanding how
this multi-tenancy magic happens behind the scenes and its relevance to cloud design.

Typical expectations of clients of a multi-tenant cloud, whatever their business, are:

 The experience of a dedicated cloud
 Secure and isolated
 Complies with standards and regulations
 Cost efficient
 Scalable and manageable
Security and compliance needs are fluid across the different layers. Each layer contributes towards security
and compliance needs. Let’s visualize the solution from a bottom-up approach.
Infrastructure
IT infrastructure makes up the bricks and mortar of any cloud. Infrastructure can be either shared
physically or logically, based on multi-tenancy and security expectations.
Total isolation of compute can be achieved through dedicated clusters and/or resource pools.
Logical isolation is realized at the virtual machine level, using a shared cluster or resource pool.
In the case of multi-tenancy within an organization, logical isolation can be achieved in several ways:
 Common storage infrastructure with acceptable trust level
 Separate disk arrays/pools of disks
 Separation at the logical unit number (LUN) level
Total isolation of a network is realized with an entirely separate, dedicated network for every tenant. Logical
isolation occurs at the network level and is achieved by using different virtual local area networks (VLANs)
and virtualized network interface controllers (vNICs).
Secure isolation across the tenancy landscape helps meet expected security needs.
Virtualization
Clients expect that the various infrastructure elements are virtualized and managed as a single large entity,
while at the the same time isolated based on tenancy.
Hypervisor-based isolation can also address needs with a dedicated or shared hypervisor environment across
tenants. Anti-collocation, hypervisor-level firewalls, resource grouping of compute and storage, and VLAN-
based isolations are some of the means to accomplish security and compliance needs.
Orchestration and automation
Along with virtualization, orchestration and automation help realize multi-tenancy by provisioning
workloads on tenant specific environments; deploying tenant-specific software, middleware, tooling agents
or antivirus programs; hardening workloads; integrating with directory services, and so on.
Often, a standard tooling landscape may be prescribed and used for cloud. However, that is not always how
things pan out. At times, the cloud might require integration with a tenant-specific tooling environment. This
would introduce custom automation and integration which the provider would have to accommodate.
A multi-tenant cloud must have some means of supporting client-specific business processes, tenant-level
identity management services, integration with the necessary tooling for service and system management,
and support for various hypervisors.
Defining standard processes and practices for the multi-tenant environment and providing flexibility for
customizations may be essential. Grouping tenants based on the nature of their businesses, matching
compliance requirements and geographical locations, and supporting tenants with specific needs as stand-
alone clients are parts of the way ahead.
Catalogue
With all these expectations met, what does this really mean to the user? How usable is the multi-tenant
cloud?
Each aspect of multi-tenancy must culminate in an intuitive user interface. The catalogue contents may vary
based on tenancy and individual privileges. Multi-tenancy at a catalogue level may warrant integration with
different directory services for each tenant, white labeling, integration with broker and management services,
and so on.
With all these capabilities for designing multi-tenancy, the buck stops with the solution designers and their
capability to continuously innovate and evolve a multi-tenant design based on ever-changing technology.
Though these are important aspects based on typical expectations, however, exercise caution when specific
expectations from clients must be met.