This will look like range of questions but all are related to SaaS and PHP based application we have been building. We are conscious about our application architecture and studying it so that we ensure to encounter all essential techniques before we move to production and do not face any failure.!
To support SaaS we have decided to make our database multi-tenant where each customer will have its own database. My mind is boggling around following list of questions further.
How to provide ability to customize a SaaS multi-tenant application to suit individual tenant needs?
How to ensure security of each tenant database so that they do not access each other's data accidently?
What are clusters and how do we add new instances of application and database to them in case of increasing no. of customers?
What do we do to ensure performance and scalability of SaaS website?
How do we handle failures of SaaS application, especially when we launch new versions and updates, (continuous integration)?
Any special solutions for handling subscribers/customers and permissions of activated and deactivated modules in SaaS application?
I have attached block diagram of DB we have decided to go with
I have written a good article with many of the items which we need to consider while developing a SaaS application in PHP. Check the SaaS application development using PHP in Zend Framework
Answers to some of your questions are below:
How to provide ability to customize a SaaS multi-tenant application to suit individual tenant needs?
Its like a normal site development. Suppose you have resources A to Z then you need to keep the assigned or accessible resources of reach Tenants inside database. Then while accessing you can simply check the permissions.
How to ensure security of each tenant database so that they do not access each other's data accidently?
The database design on SaaS application is a topic which is discussed lots of times on Stack Overflow. You can go with Single database or unique database for each Tenants. For Big Projects the second one is suitable.
If you are going with Single Database, simply store the TENANT ID in all tables. And then while Authenticating the Tenant, keep the TENANT ID in SESSION based on the Sub Domain which the request coming from. Then pass this ID in all database operations and thus, it doesn't affect the data of any other Tenants accidentally.
Related
My question title may not appropriate as I am not so aware of how to call it. I will appreciate it if anyone can edit to fits the query.
I am planning to build a web application where users will subscribe. For instance, CRM or Project management application. I want to have a separate instance and database with a custom domain for enterprise subscribers, and I may have a common database or instance for non-enterprise subscribers. The subscription will be handled through a marketing website, where all subscribers will checkout and have their own account.
Marketing website to subscribe
Application instance / website/ database / etc
Once the subscription period is over and it is not renewed, they will lose access. If they do not renew/reactivate for x time, the instance will destroy itself.
I am quite confident with PHP and MySQL, have some knowledge of AWS and Digital Ocean. I am planning to use Laravel for serverside. However, I am open to other languages as well, such as python.`
Can anyone help me to learn the best approach for the system I want to
make. Pros and Cons and things to be considered? Also, approach to make a mobile application for the subscriber where they can access their own instance.
I'm building an SaaS application in Laravel-5. Basically, I want our client to be able to point their domain to our name servers and effectively the application will load their website template (which will vary from client to client). It will also allow our clients' members to login to their account through their website and load all of their personal details.
Is this possible in Laravel-5 and can anyone point me in the right direction?
There are several ways to support multi tenancy in laravel.
Using middleware you can dynamically mutate the request object to modify behavior of the application.
By modifying the path locations you can then change where views and almost anything else is loaded from.
Landlord, a single database multi-tenancy package for Laravel & Lumen 5.2+.
Another proven package is Tenanti which handles custom database connections and even observes models to track changes to different database connections.
I'm currently maintaining a multi tenancy package for Laravel that allows complete division of responsibility for databases, files etc while maintaining a system connection for system wide settings and hostname setup.
Deprecated:
If you only want to have one database that stores all tenants, you might be interested in AuraEQ, I'm not sure there should be others. Is now Landlord.
I'm designing a SAAS application, which will be hosted on AWS. Previously I have used Elastic Beanstalk to manage applications. I could design the app so that all clients share single DB (that should be easy using EB). Is there a way to have a separate database for each client?
I could use environments for that (which doesn't seem to be a good idea since environments aren't meant for that), or create a separate beanstalk app for each client (I'm not sure if that wouldn't make updates more of a hassle).
I could also put EB aside and use different AWS services altogether.
My question is - can EB be used to create a multi-tenant SAAS app with isolated databases, or am I locked with a shared solution (single app, single db)?
If your customers are "come to my site, sign-up, start using", then build it as a single-app, using a single db. Design your database and app to be multi-tenant properly segregating data with built-in authorization checks.
If your SaaS architecture uses EB environments or databases based on customer, then:
You'll have to pay for resources per customer. That includes EC2 instances, RDS instances, etc.
When a customer signs-up, they'll need to wait for these resources to initialize. This delay may cause them to go elsewhere and not come back.
As your customer-base grows, so will your resources. Updates will take longer to apply.
I wouldn't consider a multi-tenant database architecture as being "locked in". I consider it "the right thing" as long as it's designed properly.
My company creates a lot of applications that have very similar functionality, with a few differences between each one. For example, some sites have a group creation feature, others have user profile pages, and yet others allow users to accumulate achievement points and such.
Our clients want users to be able to log in to each application with the same username/password, since it doesn't really make sense for the user to have to register a different account for each site.
How do we design our database? Is it better to have a single central database for all of our applications, or separate them into individual databases and do JOINs across databases? Which is better performance-wise and design-wise?
Thanks for any insight!
Just go with OpenID. Simplest to just use Facebook Connect as a provider. They let you get to all of your user's data (like name etc.) so you can identify and data mine them if need be.
If you don't want to rely on an external provider to handle your user accounts, then become your own OpenID provider.
I would have a central server, which hosts a user db and web services to access that user db.
That way you can use the same DB, and perform logins over web services to that system from your front end.
This is also scalable and can grow in complexity with your applications.
I would take the other two answers and combines them to make a private OpenId Provider.
This way you can use the standard OpenId clients for your developments, and possibly even open your applications up for external OpenId providers if you developments need them.
This gives scalability and open standards for other applications within the organisations to use the same provider.
In a general way I would develop tables that would be Master Data, they will be single version of the truth application wide. Each and every application will access the same "clients base". In your case it seems that the concept of Master Data can be applied to your applications database.
If the applications are hosted within the company you can use active directory.
You can access active directory from php with the ldap functionality. You can than add users to groups in active directory to give them access to various functionality within the application.
Take for instance Yahoo Mail or Twitter. When someone signs up to use their service, they'll need to automatically deploy a new database, application folder and so on - I assume!
I am planning to write an PHP application to let people add and edit invoices. Good examples would be Zoho Invoice, http://www.getballpark.com/, etc. They sure would be deploying microsites for each customer wouldn't they?
How do you do this? Would it be PHP that will handle it, or some Linux based thing.
Or if I am wrong, correct me. Maybe they have just one huge database and manage their signups from one single application.
Please guide.
Well most applications don't do that. Just imagine Twitter will have to deploy the whole Ruby on Rails Twitter application or the whole Yahoo Mail Server System for every single User.
You only choose the solution you suggest if users really need to customize their app (like plugging in own modules or change core functionality). Usually a (more or less) simple User, user options (like themes) and ACL management (e.g. for the enabled modules) should be sufficient for most applications.
Usually, it is best to use one big database. Using a combination of primary keys, foregin keys, you can easily ensure that you only display data which a user's role entitles him to.