1. Introduction
Devising the best way to organize and deploy an application may not be a simple task. We may even ask ourselves why is it not advisable to have the database and web server on the same machine. Should we set them apart? Well, there are many factors to consider in web application design. Each presents some trade-offs. In this tutorial, we’ll discuss some database and web server deployment tips and good practices.
2. Software Architecture and Physical Deployment Design
The first thing that helps with the physical deployment design is to understand our software’s architecture. We define software architecture as the structural design of a software system. A software system is a set of interrelated elements working towards a common goal. So, software architecture deals with software elements’ organization and their interfaces. Even if we don’t bother with structural software design, as soon as we choose a framework, we’ll get some of its architectural decisions. For instance, using a database management tool, we’ll get its data persistence components and the need to use its own API. But the fact is, to better organize our code, it helps to group software elements by some criteria. There are a lot of ways to do that, client-server, n-tier layered, component-based, microservices, and event-driven, to name a few. For example, the figure bellows shows an n-tier layered architecture with three tiers. In this case, we’ve set apart the UI components, the application business logic, and the data persistence: 
As we can see, in this architecture there are clear frontiers between software tiers. Well, regardless of the architectural pattern we use, chances are that this will hold true. We’ll see that we can, and should, use this as a guide to design the physical distribution of our software. Whenever we are able to draw a clear line between classes of software elements, we may consider distributing them.
3. Physical Deployment of Software Architectures
Of course, the simplest way of deploying software is to simply host all the components on the same server. However, this can be a bad option. It is best to take into account, at least, the following aspects:
- reliability: for production systems, redundancy is usually a good idea. Not having single points of failure will decrease the outage likeness
- resource usage/performance: different kinds of software components have distinct hardware needs. For instance, database systems may require lots of I/O throughput and memory. On the other hand, application logic might draw more CPU power
- security: some software components are more exposed than others. So, it is good to place our key assets (like data) in less prone servers. So, in security, it is usual to layer the protection perimeters. So, an attacker needs to breach more than one asset before gaining access to any vital one. This gives better detection chances as we can have early detections on outer-layers attempts
- scalability: we can scale up different layers according to their specific needs. Also, we can use different techniques for each layer. For instance, we can add new web servers to accommodate higher user loads without having to bother with the database server
That way, the first approach is to try giving each layer its dedicated server. As a good practice, avoid joining application and database servers whenever possible. And take our database as far as possible of the public Internet. Take advantage of firewalls and proxy servers to help defend our data. With that, we can, for each layer, design the most sound security and scaling strategies. Additionally, with containers, we can use them to group software layers, relying on orchestration to distribute the load among physical servers.
4. Conclusion
As we discussed in this tutorial, taking some time to define a software architecture will help to create easier-to-maintain applications. Moreover, will also help design the production architecture. Once we’ve set an architecture, we can use it to better organize the physical distribution of our software components. So we should set the database apart from the web server whenever possible.