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.
Related
I started reading microservices architecture and got confused with one below point.
Each service should have a separate database.
Does each service mean a single web(rest) api having its own database?
For example if I take motor insurance claim operation as a business scenario where I modelled business domain services in 3 part Insurance claim services , partner (automobile service providers) services and customer services.
Insurance claim settlement operation in claim api will require other information like incident , survey done by an inspector, policy detail , documents etc.
Now I can create 5 web(rest) api in Insurance claim services and will store its data in common db and other services like partner and customer service will have their own web apis and db
What is correct ?
All web api (claimAPI, PolicyAPI, IncidentAPI, SurveyAPI and DocumentAPI) in claim insurance services should have their own db or they can keep data in single data base ?
Thanks.
To follow microservice best practice, it is correct that they should each have their own database and be exposed solely by APIs. This is because every service in your architecture should be independent and de-coupled from other services. If 2+ services share a database, then there may arise problems in operation or upgrade.
One big issue with a shared database is each service would need to trust that another service doesn't modify it's information. But since they all have access to the same database, one of the others could in fact modify the underlying data and make things unstable or insecure.
Further, with 2+ services relying on a shared database, then you're forced to use the exact same database/version with all. You lose the freedom to independently use MySQL for one and MongoDB for another. Even if the same tool is used for all, when you do maintenance or migration on one you're forced to do it for the rest. All this adds up to some coupled services that make them harder to maintain and scale.
you can have common database for all microservices, it is one of the microservices patterns:
https://microservices.io/patterns/data/shared-database.html
https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-data-persistence/shared-database.html
check those links to see advantages and disadvantages of this approach.
I want to train an ANN model for each individual, in azure ml. For example, there is an application which wants to learn the behavior of each individual separately. How is this possible in azure-ml? Any suggestion?
As I know, I can create a model and train it with some data, but I don't know how can I train it specifically for each user. I should mention that I am seeking for a scalable idea which is applicable for a real situation (might be for 100 thousands users).
I highly recommend the Create many Machine Learning models and web service endpoints from one experiment using PowerShell article on this topic. It uses Azure ML PowerShell to automate creation of web services that have identical structure but user-specific trained models. Your application would need to keep track of the correspondence between web service and user.
I am working on a multi-tenant app in MEAN stack, in which user will signup and using their business names I will create an account(sub-domain) for them : abc.example.com.
So what approach should I use for this multi-tenant app?
A single database in which each client have their specific collection.
Or, should I maintain separate db for each user signup ?
In my application, I will be having 3-4 fixed collections for each user.
So out of these two which will be more beneficial and If you can also provide any example to support your answer ?
There are a lot of criteria that you need to look into before switching to the separate database per tenant model
Tenant volume, the number of tenants in the system
Volume of data per tenant
Compliance requirements like HIPAA that you have to adhere to the tenant
Geographical diversity, one tenant in USA and other tenant in Asia etc...
Both the options are fine, but once you are not able to predict beforehand the values for the points 1 through 3, you can just use the same database with a tenantid column and later scale out to per tenant database with ease.
If you have some values for the above mentioned points, the community here will be able to guide you better.
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.
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 ;)