|WikiProject Computing||(Rated C-class, Low-importance)|
Multitenancy or Multi-tenancy
Most of the recent published research on multi-tenant architectures uses a hyphenated version of the word (multi-tenancy vs. multitenancy). I changed this in the text, but I am unsure about how to change the name of the page, or who makes the decision on whether to change the page name or not. —Preceding unsigned comment added by Jayelston (talk • contribs) 19:47, 8 August 2010 (UTC)
Selling or informing?
Adding links to a list of companies which "actively promote the principle of mult-tenacy" seems more commercial than informative. I'll remove references if nobody objects by June 30. DigMore (talk) 13:58, 7 June 2010 (UTC) update: June 30 ... nobody objected so I'm removing them.
Seems like one of the big concerns, which is barely mentioned in the article, is security. IE, if your data is on the same box and/or in the same memory as a competitor, security is a somewhat tougher-than-usual problem. WikiAlto (talk) 22:44, 24 February 2009 (UTC)
I concur, this section needs a citation. I expect nothing but a debacle from such a horrid idea. Someone seriously thinks this is OK? Really? Don't blame me that your credit cards were stolen, they stole everyones who was running on the XYZ application hosted by the ABC company. Yea that's going to go over well.-G (talk) 20:31, 14 January 2014 (UTC)
From TD Anthony: As the definition of a term that is rather simple, old (20+ years), and generic (Saas, telecom, mainframe, database, etc) the article could have been a tad shorter and less hyperbolic.
I might have added: The term "multi-tenancy" was re-incarnated from its use in the real estate business wherein it signified how a building that might have otherwise have been rented and used by a single tenant was rented to multiple tenants that shared the common facilities. Around the 1980's, the computer and telecommunications industries started to adopt the phrase to define how large and expensive products could be used to serve multiple customers or groups within a single running instance of the product to reduce the cost to each customer and the resources consumed.
Mainframe databases and corporate PBX's are good examples. These products incorporated a high level of configuration segmentation and usage isolation that, at first, was meant to isolate the use of the products by different subsidiary companies or divisions. A case in point is where a PBX that is owned by a large company in an office building is re-programmed to also provide isolated phone functions to a smaller neighboring tenant in the same building.
To Anonymous: "Multi tenant Vs multicustomer"
Multitenancy can be (but is not necessarily) multi-customer. Multitenancy refers to when multiple groups share a single product through the segmentation and isolation of configurations, data, and usage. As such, those multiple groups may be separate customers or simply different departments, divisions, or usage applications of the same main customer.
To Einstein9073: 1. Although I found the article more industry analytical (blurb regurge) and less techno-academic (dry and wordy), it's fairly accurate. 2. Re: There being no positive or negative to a simple and generic architectural characteristic, "seems overwhelmingly positive" appears ill-chosen. Perhaps you meant sycophantic or hyperbolic to which I might give a slight nod. 3. Re: References biased: In today's capitalist world, the details of architectural techniques are now almost always promulgated through "white papers" written by companies that employ the technique. Similarly, most industry standards are created, explicated and promoted by, and for, the creators of the standard - MS Office, Adobe PDF, Sun Java, ad nauseum. So, don't hold your breath unless you turning blue.
T (talk) 23:03, 10 March 2011 (UTC) The article implies that a multi-tenant solution requires a single instance and that is simply not true. "an update on this instance may cause downtime for all tenants even if the update is requested and useful for only one tenant". All that is required for a multi-tenant solution is that they are using the same codebase and shared hosting resources but need not require that they be the same instance. For example, one could build an web application with 100 tenants where 50 tenants are using version 1, 20 tenants are using version 2 and 30 are using version 3. Updating an instance does not necessitate that it will affect all clients unless the system has specifically been designed that way. I.e., one variant of a multi-tenant solution is that the instance of the software and the storage are all shared however that is not the only variant. One can make a multi-tenant solution where the instance of the software varies by tenant but the storage is shared. One can make a multi-tenant solution using the same instance but separate storage. One can make a multi-tenant solution where the instance of the software can vary by tenant and the storage is separate.
Sorry, but the viewpoint of this article seems overwhelmingly positive and seems geared more as a sale brochure rather than describing exactly how this works and its advantages/disadvantages compared to alternatives. I would like to see more technical detail on how multitenancy works. Also, currently most of the references come from articles written by companies actively pushing multitenancy, so again I would like to see more balanced, or at least less obviously biased sources. 184.108.40.206 (talk) 19:03, 8 January 2008 (UTC)
- I agree it's a bit too sales-ey in its language. I'll remove references to products offering SaaS multi-tenancy, and generally stress the fact that this concept has been around under different guises for about 40 years
as the IP above mentioned, "Mandantenfähigkeit" (which is already linked to as the equivalent german term in the article) has a long history prior to SaaS. Time-sharing mainframes had it in the 60's, and SAP software has always had it. I'll add a paragraph to the history section
I think I've made the article less SaaS specific, and also removed anything that looks like a recommendation for a particular product.
- Thanks for your work. I think the problem is still present though. Subsolar (talk) 00:57, 2 December 2009 (UTC)