2-Tier vs. 3-Tier
There is seemingly an infinite combination of choices to make when building a new application. One of the most fundamental choices is whether the application will use a 2 or 3-tier architecture. This choice really comes down to whether to split out the business and data logic into a separate tier. For web applications the decision is made for you.
However, when building a stand-alone application there is a choice to be made.
The fundamental choice is whether the client application directly accesses the database, or indirectly accesses it by executing code on an intermediate application server. When selecting an architecture there are many things to consider, such as:
• Ease of development
• Ease of maintenance
Of course the relative importance of each consideration varies based on the application’s target uses and environment.
As can be seen from the following table, a 2-tier architecture has some compelling advantages. Although any of these points can be argued and some come down to subjective preference, there’s no arguing that 2-tier applications can be easier to build and cheaper and easier to deploy.
However, when the Internet is involved, the performance of a 2-tiered application often suffers. Since more data needs to be transferred to the client in a 2-tiered architecture, the speed of the network can have a significant impact on the performance of the application.
While the speed and performance of the network has been a limiting factor in the past, installing NitroAccelerator on the database server and clients allows 2-tiered applications to run at speeds comparable to local area networks making this option a serious one that warrants some consideration.
Read on for a relatively high level view of the design considerations and arguments. In the next blog post I’ll explore the optimal settings for building and running 2-tiered applications to maximize performance over the network.
Table 1: Design considerations for multi-tier application architectures
|Security||The topic of security is a tough one because arguments can be made either way for 2 vs. 3-tiers. In my experience, the 3-tier architecture has the potential for better security, but if great care isn’t taken during development it frequently ends up less secure. With a 2-tier approach, the application authenticates to and communicates directly to the database, which simplifies the attack surface area and is one less boundary to be concerned about. Depending on the details of the application server, there could be, for example, many complex REST APIs that could each have their own attack weaknesses. This one topic could be covered in a book, so I’m simply calling this one in favor of 2-tier even though direct access to the data sounds unsafe.||Even though 3-tier has the potential of greater security, I’m calling this one in favor of 2-tier.|
|Cost||2-tier applications are generally easier to build and because of their lower complexity are less expensive all around.||2-Tier|
|Ease of maintenance||Although part of cost consideration, ease of maintenance is worth analyzing separately. Keeping the client up to date in a 2-tier architecture can be a trouble point that is not an issue with most 3-tier designs. However, in a 3-tiered architecture, keeping the application tier up to date is much more difficult in the long run. For example, sometimes security patches required to keep the application tier secure are not compatible with your code and require you to make code changes, which can be extensive.||2-Tier|
|Performance||Performance in a 2-tiered architecture is more sensitive to the hardware the client is running on, as well as the speed of the network connection.||Generally, 3-Tier|
|Deployment||In a 3-tiered architecture, typically users point their browsers to the application server to start using the application. However, the setup of that environment can be considerably more complex than setting up a database for the users to connect to and making the installer for the client available.||3-tier for end-users; 2-tier from an initial configuration and setup perspective|
We are interested to hear your point of view and considerations. Check back for an ongoing series about application architecture options, performance and more.