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.
Related
My web app has multiple App Engines. Each App Engine has its own function. Apps were created with PHP as backend in Google App Engine and uses Cloud SQL and Google Cloud Storage for database and storage respectively.
The following Google App Engines are needed to be combined:
Client Database App
Permission Database App
Transactions Database App
Fields App
Reports App
Performance App
Data Entry App
Pattern Matching App
They are all coded in PHP and run in Google App Engine. They use Cloud SQL and Google Cloud Storage for storing data. Can they be binded together to function as one?
An App Engine application is made up of one or more "services." Many developers only use the "default" service. You can split your app into multiple services and each service has its own app.yaml configuration file and its own settings. In fact, an App Engine app could be comprised of services running in different languages (Python for one, PHP for another), and even both runtime environments (Python on flexible environment, PHP on standard environment).
One of the nice things about this "microservices" approach is that you can deploy or rollback the code for each service independently of each other. You can also share resources across them like Datastore or memcache (Memcache and a few others aren't currently supported in the flexible environment though). You can also pick different instance types or scaling options for different services, which could help you optimize costs or performance.
So yes, this is possible and can be a very good practice for many applications.
I found myself in several discussions throughout the week regarding a web application under development and whether it should leverage an API that is being created.
Here's the situation. I have a PHP MVC web application with a MySQL DB as well as several mobile apps all being developed in house. For the mobile apps we're building a rest api. The big question is why should my PHP web application now use that rest api? I've always expected the use of an API to be for third party systems that need to interface with my database or for systems built on a different technology. The web app is certainly not a third party system and the services are in PHP. If the API is on a different server than the web app then I guess it could be considered a third party system... which has not been decided yet.
To me, it just seems strange to leverage the API for the web app especially since the APIs services are going to be limited to about 50% of the functions available in the web app leaving me to build the other 50% that would be unique to the web app. I also foresee a performance hit to the web app stepping through the service layer rather than just accessing the DB directly. On the other side I see more maintenance having a code base for my web app hitting the DB and similar functions built into the api for mobile apps.
Has anyone found themselves in a similar situation and can provide some technical pros and cons to why I should just use the API or can point me to a solid case study?
Pros:
What if one day you decide to move the backend app to another machine? With an API, your app code won't need to change.
What if one day you grow, and need to scale to 10000 backend apps instead of 1? With an API, your app code won't need to change.
What if one day you decide to swap out MySQL for Mongo? With an API, your app code won't need to change.
^ Enforced separation of concerns between data access layer (DB) and application
Cons:
More code up front when writing the app layer
More incremental work when you need to support a new app layer feature that your API doesn't support yet
To me, the pros clearly win.
I want to create following project :
Server application hosted on Azure - it connects to databse via Entity framework and gives and API for anyone who want to connect (but with account stored in SQL database)
WPF application - it consumes server methods, objects etc.
Web app (php & javascript) - also consumes server methods and object etc.
IMPORTANT : I have only azure student's subscription and I want to hold onto it - buying anything else is out of the question unless it has strong argumentation.
I figured that to do this I have to create REST Web API because I have no other choice to connect to server than via HTTPWebRequest (because I want to have the same API for WPF nad web app).
My question is : does better solution exists?
I think I can create different API's for desktop client than web app but I have no idea how to do that. Whould you be so kindly to show me other way?
Why dont I want to have this solution?
Reason is simple. For big databases and slow internet connection it would take ages to download whole data in few seconds. As far as my knowledge goes there is no lazy loading in REST thus my WPF application's thread reponsible for downloading database would freeze for a big period of time.
If my question is too broad please leave a comment before you put up a flag.
Also, any tips regarding my project design are well appreciated.
Different APIs for Desktop and Web: this can be done easily enough. Assume you have a class library to contain your business logic (domain stuff). Create a web api project that makes use of it, then create yet another web api project separately that also makes use of the core models. When you deploy, deploy each separately to a different domain/subdomain (I'm unsure if you'll require further Azure resources for this, but consider api.desktop.myapp.com and api.web.myapp.com... no real technical reason why you can't do it that way, though for architecture reasons I'd avoid it (it's really coming close to if not definitely is duplication of code).
Same API for Desktop and Web: you stated that you thought you'd have to do this differently for the desktop and web, specifically because of the resource usage on the server. I disagree here, and think you should implement some standardized rate limiting into your API. Typically this is done by allowing only X amount of resources to be returned in a single call. If the initial request asks for more than X limit, an offset/nextID is returned by the API, and the client submits a new request noting that offset/nextID. This means you have subsequent calls from the client to get everything it needs, but gives your server a chance to handle it in smaller chunks (e.g., check for rate limits, throttling, load balancing, etc). See the leaky bucket algorithm for an implementation that I prefer, myself: https://en.wikipedia.org/wiki/Leaky_bucket)
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.
I have 2 questions:
First, what's the difference between a web application and a cloud application? Are there any differences at all? If I'm developing a web application (a site with many interactive features), can I call it a cloud application?
Second, if there's a difference between a cloud and web application, what languages can cloud applications be developed in? Would a scripting language like PHP be useful for that?
Thanks.
UPDATE: I have watched the video in one of the answers, but I am still a little confused. Taking Google Docs as a example, all I see is a user interface that can be created with html and JS, along with a server script, and the data is stored in a database, which is basically the same thing a web application does. Or is it different?
Thanks
Web applications can run on "the cloud". The cloud is basically a collection of dynamic computational resources (cpu, ram, storage etc) that can be used by web applications.
This allows apps running on the cloud to scale well because they are allocated resources dynamically.
You can use public clouds such as Amazon's EC2 - or build your own private clouds.
A web app running on a cloud isn't exactly a "cloud app" - but the app is simply hosted on a cloud.
I find the first half of this video explains it very well (if a little annoying).
Also see this quesiton which has some good answers.
A web application is an just an application deployed on a web server.
The user accesses this application knowing that it is accessing a remote application and this application has a specific purpose.I.e. implements a specific functionality.
When you start talking about the cloud, you have a different concept alltogether.
The idea is that you want to access a service that you have no idea where the service actually is being deployed.
The main benefit is that a company can save resources.
For example a company can have e.g. their own CRM and have to pay money for servers, for IT personel etc. or just access a service in a "cloud" where the company providing the cloud is responsible for the servers etc.
So to answer your question, to build the cloud you use web applications as "modules" to provide the cloud.
But a web application by itself (separate of this context) can not be considered as cloud application (unless it runs as part of the cloud).
Anything that runs locally can run in a "cloud". Cloud computing is the inevitable movement of traditional applications/processes to a dedicated provider. Analogous to the Walmart syndrome, where little mom and pop shops have fallen by the wayside.
The difference between a cloud and web application is where it sits.
Web and cloud apps both are distributed applications having server and client parts. They store data on a server side, but can have local data cache for offline cases.
Web applications performed/run by browsers. Normally, they are written on HTMP/CSS/JavaScript. Adobe had another vision of client parts. They proposed special Flex language for Abobe Flash as client run-time environment (prior it has been killed this year).
Cloud apps are very similar to web apps, but their client parts are native applications specially developed to run on selected target platforms (OS X, Win, iOS, etc.)