Modular Web App Network Architecture

Question

Assuming that I am dealing with dedicated physical servers or VPSs, is it conceivable and does it make sense to have distinct servers setup with the following roles to host a web application?

1. Reverse Proxy
2. Web server
3. Application server
4. Database server

Specific points of interest:

1. I am confused how to even separate the web and application servers. My understanding was that such 3-tier architectures were feasible.

2. It is unclear to me if the app server would reside directly between the web and database server, or if the web server could directly interact with the database as well. The app server could either do the computational heavy-lifting on behalf of the app server or it could do heavy-lifting plus control all of the business logic (as implied in the diagram above, thus denying the web server of direct database access).

3. I am also unsure what role the reverse proxy (ex. nginx) could and should fulfill as a web server, given the above mentioned setup. I know that nginx has web server features. But I do not know if it makes sense to have the reverse proxy be its own VPS, given that the web server–in theory–would be separate from the app server.

Answer 1

Remember one key rule:

Don't worry too much about getting the architecture scalable and all in the first pass. You might need to change it several times over as your application evolves as a result of more users/traffic/features/etc.

Just get down to shipping something so that REAL users can have a go, and act on their feedback. Don't plan ahead too much because no matter what to plan, it is bound to change.

As for the quesrion, the reverse proxy and the web server can generally be the same application -- usually nginx to begin with. Then as you scale out, varnish can be a more powerful reverse proxy.

Web servers like nginx never talk to the database directly. Application servers sit between the two.

-- UPDATE --

The above does NOT mean that we do not need to think about architecture at all. It means not worrying about getting every last architectural detail right from the start.

However, we SHOULD think about the high level system shape. Interactions between components is something that must be well thought out before beginning the concrete implementation.

Answer 2

you can think of App Servers as a sort of super version of JDBC or ActiveRecord or whatever it is you use. Some applications won't need that separation, and if this is your first pass, as mentioned, don't worry about it. However, if you find that the logic responsible for interacting with the database is getting very complex, it can be useful to split that out into its own service. This is pretty much always done in Big Data environments since the logic around programming the database is so complex and involved.

If all you have is a simple web-app that doesn't need anything more complex than MySQL or Postgres, I wouldn't worry about the App Server just yet. If you are using a web decent framework for the web server (such as Play, Django, Rails, etc.), the code will be modular enough that swapping out the DAO layer for a REST/HTTP layer to communicate with a new App Server shouldn't be too hard.

It's already been mentioned that the web server can double as the reverse proxy, as well. Again, if you find that this gets sufficiently complex down the road to justify giving that logic it's own box, by all means. Just be mindful of the fact that this is a possible direction the app could go in the future when you are programming things so that you don't end up needing to untangle unmodular code in order to break out a dedicated proxy server.

Answer 3

For a 3-tier architecture you are (partly) trying to scale. This means that you will offload some of the processing from the single database to a few application servers, and offload processing from them to many web servers. This also allows you to write code for each tier that is specialised, so the DB server will only run the DB, the app servers will only read (and cache) data and apply business logic, and the web servers will only handle presentation of the results to the clients.

There are other reasons to make a 3-tier architecture like this, security is one big reason - in such secure architectures the web server is considered the most likely to be compromised and therefore runs in a low-privilege environment (eg no direct access to the DB - if or when someone gains access to your webserver and it can read any DB table, then all your passwords are theirs. If all it can do is make an API call to the application server they also have to hack the app server too).

You can create such an architecture without many physical servers, either run them on VMs or just create each tier as a separate service - eg. the webserver is one, and its code calls a service that would be located on the app server if you had one but otherwise is just a local service that you communicate with using the same comms channel.

In many ways its easy to conceptualise this architecture - if you use any 3rd party service then you are already n-tier, the "application server" is whichever 3rd party service you consume. So if you use a Google mapping service for part of your site, its obviously running on a different server and you are making network calls to get the data which you combine with your own to build a page. Replace the Google service with your own that talks to your own DB nd you have a 3-tier service!

Reverse proxies are generally a security thing, in that it protects the web server from attackers - they have to bypass the proxy which should be difficult as it has a very small attack surface. A 3-tier architecture often has the webserver perform this role as it doesn't do much apart from generate HTML from data supplied to it by the application services.