What Servers Exist on a Network and What Each One Does

A server is a role and not a piece of hardware: one machine can serve a site, store files and check passwords. While the load is small, roles get along together, and as it grows they move out to separate machines and VMs. To find your way around this zoo, it is enough to know which roles exist and how they relate.

Facing the user

A web server delivers pages and applications: it takes a browser request, fetches what is needed from files or neighboring services and replies. In serious setups a reverse proxy stands in front: it accepts connections, handles encryption, spreads load across machines and shields them from attacks, as we cover in the article on proxy server tasks. An application server lives behind them and runs the logic, from an online store to a mobile app's API.

Data

A database server stores structured things: orders, users, stock. Its main enemies are low memory and disks, and its sacred cow is backups with restore tests. A file server stores unstructured things: documents, scans, projects; in offices these are shared folders with group permissions. A backup store gets set apart and placed far away: a copy on the same server as the data survives exactly the same disasters.

The service layer

A DNS server turns names into addresses; in an office it also handles internal names while outside queries go to public resolvers, and you can check any record with our DNS lookup. DHCP hands out addresses to devices. A domain controller stores accounts and policies: who is on the network and what they may do, and almost all other roles rely on it. A mail server receives and sends messages and is the most temperamental service role: address reputation, sender signatures and blacklists need constant attention, and the domain health check makes it easy to watch your domain.

The network border

At the exit to the internet live the gateway and firewall: routing, access rules, VPN for remote work. In larger companies a security gateway with filtering and reports combines them, such as UserGate. The office forward proxy also belongs here, if staff traffic must be filtered and counted.

Physical, virtual and cloud

A role is not tied to hardware. One physical machine carries a dozen virtual servers, and this is today's norm: virtualization simplifies backups, moves and experiments. The cloud shifts the picture further: some roles are rented as ready services, and you keep only their setup, with no hardware at all. The choice between your own hardware, VMs and cloud comes down to money and responsibility: what costs less to run and whom you wake at night during an outage. Mixed setups, with your own database and rented mail, are more common than pure ones.

How it grows in real life

A small network starts with one machine where files, DNS and a couple of services get along, and with a router as the gateway. The database usually moves first: it gets cramped next to its neighbors on RAM and disks, and a separate machine pays off. Next the border gets its own place: a gateway with its own rules replaces the router. Small teams more often hand mail to outside services than run it themselves: the cost of the role's whims exceeds the subscription price, and an outside service keeps sender reputation more professionally. A file server, on the other hand, people like to keep close: documents are near, permissions are clear, speed is local. After that, virtualization multiplies roles: there may be two physical machines and a dozen roles on them, and that is a normal density.

Eyes and ears: monitoring

What people remember after their first outage deserves its own role: a monitoring and log server. It collects metrics and logs from all the others, draws graphs and wakes the on-call person before users notice. Traffic accounting flows here too, and we have a separate review of it. The rule is simple: this role should appear second or third, not tenth, because without it all the others live blind.

When designing, keep two questions from the table in mind: what breaks when a role fails, and who will notice. The answers set redundancy priorities better than any manual: the domain controller and DNS get redundancy first, a file server forgives hours of downtime, a store's front end forgives no minutes. Infrastructure matures through awareness of these answers rather than through server count. And whatever your setup, document it with at least one picture with arrows: the next administrator, perhaps you in a year, will say thanks.