I'm working on a project that is set up as multi-tenant, separate users, data stores, etc. However, as I look further into different scenarios, I see things that may not mix well with multi-tenancy, or at least as I understand it.
Tenants can be hierarchal
Company A
West Region
East Region
Company B
Campus A
Campus B
Company C
Tenants can provide resources to another resource
Company A creates a resource
Company A shares it with Company B with specified permissions
Company C shares a resource with Company B
Company B can now use resources provided by Company A and C
I'm not tied to multi-tenancy, but I want to make sure that whatever pattern I choose, I am following the best practices of the pattern.
Is hierarchal multi-tenancy defined well enough to actually attempt? I don't see much online about it, except for a proposed Open Stack project and a research paper in only 2014. I could potentially use hierarchal users instead, but there are, of course, other benefits to tenants.
Now given that I want tenants to be able to share resources, in any direction, maybe I don't need hierarchal tenants. Maybe a need a normal flat multi-tenant pattern with just an added layer of sharing. One tenant would share to another tenant or maybe a user in another tenant.
In the latter, each user seems like they become their own tenant, with their own data. It seems like it is more and more like a social network. in Facebook, I can share things to others, they can share things to me, there is no direct hierarchy, but brands will make pages that reflect the idea of a hierarchy, without actually having one. For instance, Microsoft has Microsoft, but also Xbox, Xbox Support 1, Xbox Support 7, Windows, Bing, etc.
So I've started here with a multi-tenant architecture in front of me and now I'm thing a business grade "social network" is what I really need.
Do either of those tracks make sense? Any thing you would have me change or consider?
In cloud computing, multi-tenancy (MT) is commonly accompanied by tenant isolation. If we take the Wikipedia definition, MT is independent of sharing.
In an MT architecture, one instance of a software serves multiple tenants (or groups of users). This is in contrast to multi-instance software in which multiple instances of a software serves multiple tenants.
The main benefit of the MT architecture is of cost - software updates can be done on the single instance to benefit all of the tenants. MT software provides a common base of functionality for tenants, but commonly have interfaces that allow each tenant to customize branding & workflows.
Your project looks to be MT with sharing capability. Let's assume each Company wants to be able to share access to some resources. The architecture then should have sufficient flexibility for the tenant to be able to control access to resources. The underlying frameworks should be fast, secure, and reliable, and auditable.
Since your focus is on sharing flexibility, it's important that the architecture supports letting tenants define access to resources the way you and they want - tenant to tenant, or tenant to some user.
In my opinion, I would consider starting with a "default-deny" architecture - one that doesn't share anything by default, and allow the tenants to setup rules for access to resources.
Short version: Multi-tenancy is generally independent of interactivity.
Related
By definition (Wikipedia) - A tenant is a group of users who share a common access with specific privileges to the software instance and the term "software multi-tenancy" refers to a software architecture in which a single instance of software runs on a server and serves multiple tenants. It also states that with a multi-tenant architecture, a software application is designed to provide every tenant a dedicated share of the instance - including its data, configuration, user management, tenant individual functionality and non-functional properties.
From the definition, I understand that multi-tenancy says more from an architecture perspective and in case of Google drive, the internal architecture may not be known. However from a user/usage view, can we call Google drive or similar cloud applications as perfect examples for multi-tenancy since these are able to serve multiple customers and even allows us to share data among users securely? If so, will it be correct in saying that any software or application with a single instance allowing multiple users and gives data isolation, called as multi-tenant applications (from a user perspective)?
Note - I have already gone through the following post which states the difference between multi-user and multi-tenancy, however most of the cloud application share same database and servers and so can we call them multi-tenant? - http://multi-tenancy.blogspot.com/2009/07/what-does-this-mean-part-i.html
Multi-user example:
userX#domain1.com uses Google Drive
userY#domain1.com uses Google Drive
Multi-tenant example:
userX#domain1.com uses Google Drive
userY#domain2.com uses Google Drive
A multi-user system need not necessarily mean it's a multi-tenant system.
As you mentioned, we may not know the internal architecture of Google Drive, but from a user's view, it can be considered as a multi-tenant application as users from multiple domains/business entities/companies (i.e., userX#company1.com and userY#company2.com) access the same application using Google's enterprise solutions. Each of those domains/companies can be considered as tenants of Google Drive.
Google Drive is an excellent example of a multi-tenant application when several users have access to one cloud drive and can have access to this drive. For example, to perform some kind of teamwork. In this case, each user of Google Drive will be a tenant. The work with Google Drive's documents has a similar logic. Few users that have access to documents can jointly use them.
I am new in Service Now platform, developing a custom app using the service portal and I am looking for some architectural advice from experts.
My storyline is my service is gonna serve different companies as per their requirements by easy codebase maintenance. for example, I am having a base app which has some concrete requirements that fit for all companies, but there will be some other features for company specific, like feature A for company A, feature B for company B and so on. So my initial plan was like classic software development that is to have a single codebase using git that will have multiple feature branches that will deploy to multiple instances. But sometimes some situation where I might need to merge the branches that is not possible now. My question here is there any alternative way to do that? Other possible scenarios here is should I go with a single instance with ACL based data separation? (but that not feels scalable to me cause the amount of the data will be huge after some time) or is that possible to apply regular SAAS architecture like multitenancy(single app with multiple databases) with some configuration wise feature separation?
Thanks in Advance.
we have a big distributed and multitenant system with all sorts of accounts :
- admin and backoffice users account
- customer account
- cashier account (tenant : there is one or many more cashier for each client tenant)
All this account are sharing more or less the same lifecycle (account created, grant on some ressources, deny account, password reminder...)
But they are not used in all applications of the system : some account would be used on specific or just two application for example.
Furthermore our system should have the possibility to have a bridge with a CMS for the customer management, or the backoffice users account could be authorized one day against a ldap...
So the question : we are searching for the best way to model our right and authorization service(s).
One idea is to create one service in order to manage all types of accounts of any kind : that is a SOA way to modularize our system
And one idea is to create different services : perhaps much more a micro-service oriented way of thinking...
What are your opinion ? I am searching some advices and feedback on this two different approach or perhaps an alternative that we habve not thought about...
If you are looking for any open-source solution for your problem, you can have a look into keyclaok.
Keycloak also got place in Thoughtworks Technology RADAR.
It is very promising solution and has LDAP, Multi Tenancy support also. checkout keycloak features.
There is paid solution like ForgeRock is also avaible.
Coming to feedback which you have asked about SOA or microservice way of implementation here (You will get different feedback/advice on this)
It will be better if you have a service to take care of access and authorization management and other to look into user details. If you meant that having different services for different account then note that Having one service for taking care account is still considered as Microservice approach as there is one dedicated service to perform single set of tasks.
You can have User-Service for user information management and a authService to handle access and authorization of users. check.
I have a completed asp.net mvc 3 web application which relies on a mysql database and a mssql authentication/authorization database. How should I go about converting the application into Software as a Service - specifically with relation to having multiple tenants? Should the database just have its tables segregated based on tenant ids, or should there be one database per tenant? Are there any books or good sources I can reference? I am just trying to see if there is a best practice for this, or if what I am doing is standard.
Software as a Service is a huge industry and is rapidly growing. Major educational players are actively investing in including coursework regarding SaaS. One such institution is Unversity of Berkeley, California. They offer a free online course on SaaS at edx.org. The two professors teaching the class are highly acclaimed. The book for the course can be purchased via their site or through amazon.com.
Note: I am in no way affiliated with the course, the University, the professors, any of the free online education sites, nor am I enrolled in the class. There is not much content available on SaaS and this is one of the only sources that I was able to find.
Edit
With regards to the database, to convert from a single tenant to a multi tenant system, an abstraction must be used in order to separate the content. However, this will undeniably multiply the amount of content by the amount of tenants in the tables resulting in slower query times. In this respect, the tables must be partitioned by tenant ranges, with views representing those partitions. These views can then be queried.
In medium to large organizations what team or group typically support middle tier components like Oracle Application Servers?
(Unix Team, DBA Team, Or Application Development/Support Team)
In a client server application design the delineation of ownership between the server and the client is very clear. In the client server case the Unix Administrators manage the servers and the development support team manage and support the clients. (and the DBA's support/manage the database)
Recently at our shop the lines have become blurred; the introduction of an Oracle application Server (OAS) has popped up;
OAS seems to require a very unique set of skills but also show some similarity to the client server skills. (part Unix Admin, Part Dba, Part Application Developer/Client Support)
What have others done when confronted with this kind of challenge......??
Does a completely new team form that exclusively supports the Middle Tier??
Our It Group has 3 Unix Admins; 3 Application Support staff; 3 Dba's to give the perspective of the size of the teams....
There are a couple of different options, to my mind:
1) Roll it into the application development/support team as this is part of an application that isn't necessarily where only Admins are useful. There should be a separation between development and support to some extent as different tools may be used and some may have a stronger skill set for one over the other such as if one prefers investigating things then support may be a better fit.
2) Platform management team which is a separate group where there is a separation of the layers involved in the applications the company produces. I used to work for a company where the middle tier and back-end were managed by one team that was separate from the Applications group which seems appropriate if there is the plan of having that middle and back-end tiers become a platform for the company to pitch to other companies to use how they see fit in terms of making their own applications on top of this API.
I can see a logic in using either method depending on how one sees what the IT arm offers in a sense.
For large organizations, you generally eventually get to a point where there are dedicated teams to manage the middle tier web servers and application servers.
The problem for smaller organizations generally comes that when you first deploy the app servers, there may not be enough admin work to justify a separate person in that role, at which point you have to cobble together time from other teams. It's not particularly unusual for DBAs to manage the app server (particularly for Oracle DBAs managing Oracle Application Servers). It's also not particularly unusual for the Unix admins to manage the app server. Either way, though, some of the work will inevitably benefit from input from the other team.
IMHO there should be a single "Oracle" team, comprising DBA's, unix admins, application admins, and even a network person for big installations. There is really only one system, although it has multiple tiers and technologies. You do not want four teams all passing the buck round when a system fault occurs. Ask me how I know ;)