Question

Although this is a Java-centric question it really applies to any system utilizing a multi-tier architecture.

In 3-tier architectures, you typically have 3 tiers:

• A client/presentation tier where the client code lives; and
• A middleware tier where business logic lives; and
• A data/eis tier where the RDBMS and other data-heavy systems live

In Java land, for a web application, this might look like:

• An application server, such as GlassFish running both the “web tier” (WARs comprising the client tier in a web app) as well as the “business tier” (EJBs, middleware, etc.); and
• A RDBMS server embodying the data tier

In a virtualized/clustered environment, these applications (GlassFish, RBMBS such as Oracle or PostgreSQL, etc.) will run on VMs.

My question: What are the standard ways of allocating/distributing this 3-tier architecture across these VMs? Meaning, any one of the following “strategies” might be viable, but not preferential:

1. One VM (let’s say all VMs are Ubuntu Servers so cost/price doesn’t factor into the equation) running both GlassFish and the RDBMS (all 3 tiers)
2. Two VMs: an application server VM running GlassFish, and a database server VM running, say, PostgreSQL
3. Three VMs: two app server VMs both running GlassFish, however 1 GlassFish instance is only running WARs (web tier) whereas the 2nd FlassFish instance is running the middleware/biz logic; then a 3rd DB server

Obviously if all the servers (all tiers) were running on the same VM, they may run faster or more efficiently because they wouldn’t be bogged down with network latency. But they’d be on the same VM, which needs I would need mega-hardware to support them. There might also be security concerns with this setup.

There will be pros/cons to each. I’m interested in what strategies would best accomplish the following goals: (1) maximizes throughput/speed, (2) is best suited for a clustered/cloud environment and (3) maximizes security.

Thanks in advance!

Answer 1

(1) maximizes throughput/speed,

This depends entirely on your application. e.g the Database could be your bottle neck in which case what you in JVM does matter so much.

(2) is best suited for a clustered/cloud environment

If you are going to distribute your system, you are most likely to want to distribute your presentation layer. This is because the work they do is dependant on the number of clients and the work each client does is largely independent. (in the presentation layer)

and (3) maximizes security.

Having more VMs doesn’t guarantee improved security. Your JVM should be setup so the different applications running in it are pretty separate anyway. If you want to prevent denial of attack and your back end services are used by other systems, you may want to separate them otherwise, it doesn’t make much difference.