When discussing cloud computing, one often hears the term "Multi Tenant Architecture". The term is seen as "the standard" by which one should judge whether a software is truly a cloud solution or simply a software hosted on a remote data center. The expression implies the ability of an enterprise software to be effectively used by multiple enterprises at the same time, without the knowledge of one another.
As mentioned, Multi tenant architectures are supposedly one of the underpinnings of modern SaaS (Software as a Service) or cloud architectures. However multi-tenant architectures are increasingly being asked for in many on-premise deployments.
The reasons for this ask, ranges from convincing to the absurd. This trend is particularly noticeable in organizations where:
1. After an era where Corporate IT had no say (for good reason), in business departments running their own mini-IT shops, IT has now become "a strategic expense". IT is trying to consolidate various home-grown systems, but the requirements have become so divergent that completely different functional and non-functional requirements are being sought.
2. Alternatively, in other cases, IT departments in large Organizations have bought multi-tenant software products without real business analysis. Here the promise was that client departments would utilize their own resources to understand the processes they would want to automate and then go about implementing such solutions in a self-service model.
3. Finally, are organizations where Multi-million dollar data centres have been sold to large organizations with the promise of virtualization without having a real business case for it.
Regardless of the mechanism, reality is that IT departments would like to look for applications that can be rolled out in this self-service way.
For our purposes, on-premise multi-tenant architectures are being desired by organizations wherever there is a self service software delivery model. Where multiple groups or departments or even organizations are using a shared environment and would like to sandbox their interactions and system configurations to their own use scenarios.
Multi tenant as the name implies multiple distinct uses. A good metric to validate if the architecture is truly multi tenant is to Of course ask the question "How many user groups are using distinct configurations, their own databases as well as configuration policies and yet are on the latest release of the software?"
To achieve multi-tenancy is a whole different ball game together. The first step is what is called virtualized multi tenancy where multiple environments and associated user groups are having their own configurations but in sandboxed virtual environments.
The next level is to allow multiple deployments within the same environment, but completely isolated by having dedicated instances of run time environments.
True multi-tenant architectures would imply that its the same run time process but allows completely isolated operations. The way to achieve it is perhaps through configurations that can be altered and spawned at any time. Perhaps resource constraints can be set to prevent monopolization of resources by a single instance/ configuration. Software based memory architecture would allow completely sand-boxed operations. All this requires a lot of hard work in upfront planning and designing and building.
Given these above requirements, I would think that to be functionally complete multi-tenant architectures would require the following:
1. A Configuration driven administration model
2. An ability to spawn and kill configuration based instances that are completely sand-boxed from one another.
3. An ability to set resource constraints on usage
4. A configuration authoring tool
5. A set of policies that dictates what can be done and not done
6. A starting persistence and object model that can be tweaked to a degree.
7. A standardized higher level SDK that can be developed against without having to accessing lower level APIs
8. Ability to monitor and report on usage and optionally get billed for it.
Based on the above, some conventional platforms are evolving to support multi-tenant models. Others, have a long way to go....
As mentioned, Multi tenant architectures are supposedly one of the underpinnings of modern SaaS (Software as a Service) or cloud architectures. However multi-tenant architectures are increasingly being asked for in many on-premise deployments.
The reasons for this ask, ranges from convincing to the absurd. This trend is particularly noticeable in organizations where:
1. After an era where Corporate IT had no say (for good reason), in business departments running their own mini-IT shops, IT has now become "a strategic expense". IT is trying to consolidate various home-grown systems, but the requirements have become so divergent that completely different functional and non-functional requirements are being sought.
2. Alternatively, in other cases, IT departments in large Organizations have bought multi-tenant software products without real business analysis. Here the promise was that client departments would utilize their own resources to understand the processes they would want to automate and then go about implementing such solutions in a self-service model.
3. Finally, are organizations where Multi-million dollar data centres have been sold to large organizations with the promise of virtualization without having a real business case for it.
Regardless of the mechanism, reality is that IT departments would like to look for applications that can be rolled out in this self-service way.
For our purposes, on-premise multi-tenant architectures are being desired by organizations wherever there is a self service software delivery model. Where multiple groups or departments or even organizations are using a shared environment and would like to sandbox their interactions and system configurations to their own use scenarios.
Multi tenant as the name implies multiple distinct uses. A good metric to validate if the architecture is truly multi tenant is to Of course ask the question "How many user groups are using distinct configurations, their own databases as well as configuration policies and yet are on the latest release of the software?"
To achieve multi-tenancy is a whole different ball game together. The first step is what is called virtualized multi tenancy where multiple environments and associated user groups are having their own configurations but in sandboxed virtual environments.
The next level is to allow multiple deployments within the same environment, but completely isolated by having dedicated instances of run time environments.
True multi-tenant architectures would imply that its the same run time process but allows completely isolated operations. The way to achieve it is perhaps through configurations that can be altered and spawned at any time. Perhaps resource constraints can be set to prevent monopolization of resources by a single instance/ configuration. Software based memory architecture would allow completely sand-boxed operations. All this requires a lot of hard work in upfront planning and designing and building.
Given these above requirements, I would think that to be functionally complete multi-tenant architectures would require the following:
1. A Configuration driven administration model
2. An ability to spawn and kill configuration based instances that are completely sand-boxed from one another.
3. An ability to set resource constraints on usage
4. A configuration authoring tool
5. A set of policies that dictates what can be done and not done
6. A starting persistence and object model that can be tweaked to a degree.
7. A standardized higher level SDK that can be developed against without having to accessing lower level APIs
8. Ability to monitor and report on usage and optionally get billed for it.
Based on the above, some conventional platforms are evolving to support multi-tenant models. Others, have a long way to go....
No comments:
Post a Comment