Business Applications
The network is the information highway for the business applications of today, and for the business to be successful, these applications must be able to properly communicate as required between users, devices, data, databases, and other application components.
Application Models
Network designers need to understand how an application is built to properly design the network for that application. The following are the different application models being leveraged today and their associated design elements that you need to know as a network designer:
Single-server model: This is the simplest application model and it is equivalent to running the application on a personal computer. All of the required components for an application to run are on a single application or server.
2-tier model: This application model is like the client/server architecture, where communication takes place between client and server. In this model, the presentation layer or user interface layer runs on the client side while the dataset layer gets executed and stored on the server side.
There is no intermediate layer (aka application layer) in between client and server.
3-tier model: This application model is the most common at the time of writing. This model has three tiers or layers:
Presentation: This is the front end of the application that all end users access. This is how an end user sees and interacts with the application. This is often called the web tier or GUI tier of the application. The main function of this layer is to translate tasks and results to something the end user can understand.
Intermediate: This is the layer where all of the application’s functions and logic occur. This layer processes tasks, functions, and commands, makes decisions and evaluations, and performs calculations. It also is how data is moved between the presentation (web/GUI) and database layers. This is often referred to as the application or logic layer of the application.
Database: Here information is stored and retrieved from a database. The information is then passed back to the intermediate (application) layer and then eventually back to the end user.
Breaking elements of an application into different layers like the n-tier architectures allows network designers to properly design the network for each tier or layer individually. Each layer may need its own load balancing, applying source NAT, DNS, source routing, and traffic engineering design. This means more work from a network design perspective but a better purpose-built environment for each tier with all associated elements needed, which allows the different application layers to scale out as needed.
Table 3-2 shows the different network design elements for each layer of the 3-tier model and provides leading questions to ask to help elicit the information needed to make a proper design.
Table 3-2 3-Tier Application Model Network Design Elements
Tier |
Traffic Pattern |
Network Design Elements |
Questions to Ask |
Web tier |
End user and application layer access only. |
No database layer access. The web tier needs to be globally accessible for the end users. Normally located in a DMZ. |
How are end users accessing the web tier globally? How are the web tier–specific networks/IP addresses being routed? What’s the web tier’s high-availability architecture? (Active/active, active/standby, anycast, etc.) |
Application tier |
Web and database access only. No end user should ever access this tier directly. |
This tier is internally accessed only, so no external addresses or routing are needed. Load balancing should be implemented, but how depends on the other tier’s communication method with this tier (SNAT, NAT, Sticky, etc.). Normally located internally behind multiple security layers. |
How does the web tier communicate with the application tier? How does the database tier communicate with the application tier? |
Database tier |
Application layer access only. No end user or web tier should have access. |
This tier is internally accessed only, so no external addresses or routing are needed. Normally located internally behind multiple security layers. |
How is replication being done between the different database member servers? How are the database changes synchronized? The answer to his question is especially critical when there are multiple data center locations. |
Application Constraints and Requirements
As a network designer, there are a number of common application constraints and requirements that you should be aware of. These are topics that a network designer should be asking about as a network is being designed to support an application. This is by no means an all-inclusive list.
Multicast: Usually leveraged between a cluster of servers to keep data synchronized, such as a backend database replication architecture, or as a transport mechanism for data streaming applications like IPTV and real-time stock market updates for day traders. In these situations, not having multicast breaks the application in question.
Layer 2 extension: Probably one of the most common network design requirements after an application has completed its development process. As the application is being deployed, it is quickly identified that the application servers, maybe in a 3-tier model, do not communicate outside of their Layer 2 segments. Now it’s the network designer’s job to provide Layer 2 extension options that allow the application to properly function. This leads to bad network designs with large Layer 2 fault domains that are generally unreliable. Even though these are bad network design options from a network design perspective, they do solve the application requirement and thus they make the business successful. If there is a requirement to extend Layer 2, some of these limitations can be mitigated with overlay technologies while still allowing for an expanded Layer 2 environment.
Hardcoded items: Thankfully, we are seeing issues with hardcoded items in the code less frequently today. They do happen, and that’s why network designers need to know about them. These hardcoded items bring a security element into the mix with compliance controls and overall security requirements for the application in question. From a network design perspective, though, how do we handle hardcoded IP addresses in the code? The simplest answer is to not allow hardcoded items in the code, but what do you do as a network designer when it does happen? This is where solutions like Network Address Translation (NAT), traffic engineering, and source routing can be leveraged to help mitigate this issue.
High availability: How an application is designed for high availability has a large impact on the network supporting that application. Is the application in multiple locations, such as geographically separated data centers? If so, how is the application data synchronized between these locations? How do end users access the applications in each location? Is one location preferred over the other at all times (active/standby), or can the application be accessed from either location at any time (active/active)? What about the load-balancing options for the application? Is it leveraging DNS load balancing or a physical load balancer? Does the application require the use of source NAT (SNAT) between its different application layers? There are so many network design–related questions that we have to ask and answer to properly facilitate the creation of a network design that makes the application successful.
When creating a network design that’s goal is to make an application successful, it really comes down to the applications, services, and so forth being created incorrectly. Network designers have been forced to provide band-aid solutions like Layer 2 extension options because of these problems. This is most definitely not solving the true issue of proper application development. We simply extend Layer 2 as a short-term solution that ends up becoming a permanent one. This is similar to hardcoding IP addresses and hostnames in an application’s code. Network designers always have to provide bad network design options because of these application issues.
To solve these issues, a network designer and a security specialist should be part of the team that builds and reviews an application, to ensure network design and security controls are being properly considered in the application. It’s not fair to expect an application developer to know and understand the details of network design or security; network designers have to help them, teach them, and show them.
If we want to change these situations with the plan to limit them from happening, we need to be a part of the creation process so we can explain the reasons to the business at those critical steps. The business doesn’t know what a network designer knows. A network designer can tell the business why they shouldn’t rely on a Layer 2 extension for the application, why they shouldn’t hardcode IP addresses, hostnames, usernames, and passwords in code, and why they should ensure security controls are implemented during the creation process.
In the end, it all comes back to business decisions and the respective trade-offs.