Never Ending Security

It starts all here

How Looks a Typical Server Architecture Setup

Typical Setup: Server Architecture

When deciding which server architecture to use for your environment, there are many factors to consider, such as performance, scalability, availability, reliability, cost, and ease of management.

Here is a list of commonly used server setups, with a short description of each, including pros and cons. Keep in mind that all of the concepts covered here can be used in various combinations with one another, and that every environment has different requirements, so there is no single, correct configuration.

Everything On One Server

The entire environment resides on a single server. For a typical web application, that would include the web server, application server, and database server. A common variation of this setup is a LAMP stack, which stands for Linux, Apache, MySQL, and PHP, on a single server.

one server

Use Case: Good for setting up an application quickly, as it is the simplest setup possible, but it offers little in the way of scalability and component isolation.


  • Simple


  • Application and database contend for the same server resources (CPU, Memory, I/O, etc.) which, aside from possible poor performance, can make it difficult to determine the source (application or database) of poor performance
  • Not readily horizontally scalable

Separate Database Server

The database management system (DBMS) can be separated from the rest of the environment to eliminate the resource contention between the application and the database, and to increase security by removing the database from the DMZ, or public internet.

databUse Case: Good for setting up an application quickly, but keeps application and database from fighting over the same system resources.


  • Application and database tiers do not contend for the same server resources (CPU, Memory, I/O, etc.)
  • You may vertically scale each tier separately, by adding more resources to whichever server needs increased capacity
  • Depending on your setup, it may increase security by removing your database from the DMZ


  • Slightly more complex setup than single server
  • Performance issues can arise if the network connection between the two servers is high-latency (i.e. the servers are geographically distant from each other), or the bandwidth is too low for the amount of data being transferred

Load Balancer

Load balancers can be added to a server environment to improve performance and reliability by distributing the workload across multiple servers. If one of the servers that is load balanced fails, the other servers will handle the incoming traffic until the failed server becomes healthy again. It can also be used to serve multiple applications through the same domain and port, by using a layer 7 (application layer) reverse proxy.load_balancer_pic

Examples of software capable of reverse proxy load balancing: HAProxy, Nginx, and Varnish.

Use Case: Useful in an environment that requires scaling by adding more servers, also known as horizontal scaling.


  • Enables horizontal scaling, i.e. environment capacity can be scaled by adding more servers to it
  • Can protect against DDOS attacks by limiting client connections to a sensible amount and frequency


  • The load balancer can become a performance bottleneck if it does not have enough resources, or if it is configured poorly
  • Can introduce complexities that require additional consideration, such as where to perform SSL termination and how to handle applications that require sticky sessions

HTTP Accelerator

An HTTP accelerator, or caching HTTP reverse proxy, can be used to reduce the time it takes to serve content to a user through a variety of techniques. The main technique employed with an HTTP accelerator is caching responses from a web or application server in memory, so future requests for the same content can be served quickly, with less unnecessary interaction with the web or application servers.

Examples of software capable of HTTP acceleration: Varnish, Squid, Nginx.


Use Case: Useful in an environment with content-heavy dynamic web applications, or with many commonly accessed files.


  • Increase site performance by reducing CPU load on web server, through caching and compression, thereby increasing user capacity
  • Can be used as a reverse proxy load balancer
  • Some caching software can protect against DDOS attacks


  • Requires tuning to get best performance out of it
  • If the cache-hit rate is low, it could reduce performance

Master-Slave Database Replication

One way to improve performance of a database system that performs many reads compared to writes, such as a CMS, is to use master-slave database replication. Master-slave replication requires a master and one or more slave nodes. In this setup, all updates are sent to the master node and reads can be distributed across all nodes.


Use Case: Good for increasing the read performance for the database tier of an application.

Here is an example of a master-slave replication setup, with a single slave node:


  • Improves database read performance by spreading reads across slaves
  • Can improve write performance by using master exclusively for updates (it spends no time serving read requests)


  • The application accessing the database must have a mechanism to determine which database nodes it should send update and read requests to
  • Updates to slaves are asynchronous, so there is a chance that their contents could be out of date
  • If the master fails, no updates can be performed on the database until the issue is corrected
  • Does not have built-in failover in case of failure of master node

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s