We are planning to use Azure Service Fabric for a data-oriented multi-tenant application. Typically 100+ customers each with 5 - 100 users.
Looking at the documentation, I concluded that the best approach is to use an Application instance for each customer, rather than trying to use Profiles to achieve multi-tenancy.
Is this the best way to go ?
An application instance for each customer is a good way to handle multi-tenant situations on a single cluster, yes. There are Service Fabric applications that do this today (Azure DB is a notable one).
Here are some things you get with this approach:
Each application instance gets its own process, which means you have process-level isolation per tenant.
Each application instance is composed of one or more services, which means you can use a "microservices" architectural style for the application.
Each application instance can be created with unique parameters, so you can have various setups for each tenant. For example, you can do things like offer higher availability to certain tenants by using higher replica set size settings for the services in their application instance, or you can offer higher data capacity by using a higher partition count setting for the services in their application instance.
These are generally good things for data-oriented multi-tenant situations but whether or not its the best way to go of course depends on your specific requirements.
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 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.
I am developing an application that needs to be clustered in Liberty Profile on BlueMix. I need to have a shared List of objects accessible to all nodes of the cluster. The app will perform update, add and remove operations on them, as one node does not cope with the big load need of the application. How can I do this with Liberty Profile? Is there a best practice or recommended approach before looking for 3rd party solutions for this? Thanks
I would suggest looking at the services in Bluemix, for example Data Cache or Redis. An external (to your app) service would be the cloud best practice for sharing data between multiple instances of the same application or multiple applications that need to communicate.
A traditional Liberty cluster doesn't make sense in Bluemix because the Cloud Foundry platform upon which it is based is already providing ways to achieve high availability and scale.
Note: I edited this question because I try to ask more as a question not as an opinion.
Our application is a multi tenant application being developed using Java, JBoss, and MySQL on Linux.
if application is multi-tenancy should we launch 1 instance per customer or or should we launch 1 instance for all customers ?
When and why we should launch new instance while we have one already?
Thanks
Best Regards
This is not a great question for here since the questions are likely to be a bit too opinionated. But I will give you some thoughts about what you wrote.
Having one customer confined to one instance gives you no failover. If the instance fails, the application is down until you can restart or relaunch the instance.
You should probably think about building clusters than can host several customers, 2-4 instances each, with failover and load balancing. (Maybe also use Multi-AZ RDS to host mysql)
Customer specific configuration needs to get out of JBoss and into your application somehow, I dont know the details of the platform so I cannot provide specifics.
Whether to launch one instance per customer or not is purely based on the solution you want to provide, the requirement, the load and the multi tenant strategy you decide to use. There is no fixed answer.
If all the tenants load can be sustained by one instance and you are not worried about per tenant resource usage then one instance is just enough. Of Course, you will plan for high availability.
Here are a few answers i provided for other users questions regarding db design and scalability for a saas setup. I hope it helps.
Databse architecture (single db vs client specific db) for Building Enterprise Web (RIA) application on cloud
Explanation of Tenant Load Balancer in SaaS maturity model level 4
Architecture for SaaS based online portal
If i have a multi-tenant asp.net MVC application, something like basecamp ,what's the suitable hosting plan for me, is it a "Shared Hosting" or "Dedicated Server" is best fit for me.
Some parameters for the project:
- Each tenant will have a different database.
- Each tenant will have its own sub-domain.
- Expected number of tenants in the first year for the product, about 1000 tenant.
So how can I manage the hosting part of this project ?
Am open for any suggestions even if they are not part of my question.
To decide which infrastructure best fits your application you need to take into account parameters like how "active" your tenants will be or how "heavy" your application is.
For example, a simple, read only application for 1000 user may fit a pretty small dedicated server. But a different system may need a couple of DB servers and 3 web servers in a load balanced configuration (a basecamp-like with 1000 users may need a configuration like that)
You should not underestimate this problem: I don't think that a single server would be powerfull enough, and when you have more than one server your sysadmin problems start to grow :)
Remember that another viable alternative is hosting your application in a cloud environment (ie: http://aws.amazon.com or Microsoft Azure). But sometimes going to the cloud need a different approach on application's architecture.
Also, remember to take into account consideration like the availability of your application (ie: what happens when the server goes down?)