Isolating your network in a VPC has major security benefits, including enabling private collaboration and storing sensitive information properly.
On the dev side of the house, network isolation also enables the deployment of multi-tiered web applications. Tiering your app allows you to segment layers with and without public internet access. This is often used to isolate the database layer from the public internet while still allowing patches and software updates to be pulled from a top layer instead of the public internet directly. In addition to decreasing attack surface, this can enable multi-region deployments.
There are numerous ways to run multiple layers, but you typically can rely on a few basic forms that maximize scalability, security, and reliability. One of the most common designs is a three-tiered architecture which is especially popular in cloud-based environments.
A three-tiered application consists of three different layers that reside on different servers and can be developed and administered with a high degree of independence. These parts are:
- Presentation: The external interface that manages communication between the user and the application, typically consisting of a web server with HTML and accompanying web development code.
- Application: A custom application that provides the necessary business logic and glues the application together.
- Data: A database system for storing and retrieving data used with the application.
These three tiers serve as separate services that communicate through network-based APIs. Security and performance concerns often call for the Application and Data tier to reside within the same local network behind a common firewall, but the separation of each layer brings the potential to deploy each component onto different hardware or even different physical locations. The flexibility here will drastically depend on your application’s requirements.
The diagram below shows a real-world view of a basic three-tiered web application. The web server in the Presentation tier provides an interface to a user working in a browser window. On the opposite end, the Data tier takes the form of a database, which could be a single system or a cluster presented to the network as a single entity. Popular open source options for the Database tier include MySQL, MariaDB, and PostgreSQL for SQL and MongoDB and Cassandra for NoSQL.
In between the web server and database is the Application tier, where you will likely spend the majority of your coding time. The Application tier contains the custom code and business logic you need for the application to accomplish its goals. On the front end, the web server sends queries to the Application tier. The Application tier will respond to the web server and the web server will format the data and present it to the user. On the back end, the Application tier queries the database, receives the data, and then processes the data to add intelligence and insight for the user.
As a very simple example, the database might store sales records for a company. The user enters a request to receive the average daily sales for a specific product in a specific location for a certain time interval. The web server sends the request to the Application tier. The Application tier formulates a query to the database, receives the raw data, performs the necessary calculations, and then sends a response back to the web server.
There is no convenient drop-in solution for the Application tier that is equivalent to, say, an Apache web server for the Presentation tier or a MongoDB database for the Data tier. Instead, custom code is typically written in Python, PHP, or Ruby for the Application tier. However, some programming frameworks exist that will give you a head start on writing the code more efficiently, including Django (for Python), Rails (for Ruby), and Symfony (for PHP).
The Application tier could, in theory, be combined with the Presentation tier by providing the web server the necessary code for direct queries to a database, but this would be impractical for most complex business logic and negate many of the benefits of segmenting applications.
One of the most important of those benefits is increased security with a smaller attack surface. As shown in Figure 1, a three-tiered solution minimizes the portion of the application that must reside in front of the firewall. The web server communicates through a secure API. The rest of the activity is behind the firewall and, critically, in a private address space that isn’t accessible from the internet. SQL injections, in particular, are one of the most common vulnerabilities–and one of the most destructive. These can be prevented by isolating and protecting all direct communication with the database.
Another benefit of the three-tiered application is reliability. An outage in one tier is less likely to affect the other tiers when each layer is running on a separate server or separated further onto different hardware or another data center entirely. This also gives us potential for scalability. Because the components operate independently, they can grow independently. For instance, if database access is a performance bottleneck, you can add nodes to the database cluster with minimal disruption to the overall operation.
A three-tiered approach can also optimize the development process. The APIs connecting the tiers separate the components in a way that supports efficiencies in division of labor. Web developers and admins can operate and maintain the web server while database developers and admins can run the database system. In between, specialists in the framework you’re using for the Application tier can focus their attention on the application code. In a DevOps scenario, for instance, the application developers can build and test a new version of the application code offline, changing it out easily with minimal effect on operations.
If you’re starting to build a web application, consider a three-tiered architecture. In today’s container and cloud environments, it is easy to separate the components on different systems, and you’ll be rewarded for your efforts with a more reliable, more secure, and more scalable application.
Get started on Linode today to build out your application layers.
Resources: Getting Started with VLANs | Cross-Data Center Applications
Linode Solutions: VLANs | Managed Databases
Comments (1)
You can eliminate the “NAT” in Figure 1. It’s not needed in an IPv6 world. A proper firewall will suffice.