Building is not the issue, but I have no clue about the software and the how and why you do it.
For the most part, "Server" means running either Windows Server or some Linux, *BSD or Solaris-derived operating system. I guess Hackintoshes as well, but most people don't think of MacOS that way.
Windows Server is technically expensive, but not really because key resellers are a thing. The biggest difference between it and desktop Windows are that you lose access to the Microsoft Store and some Store-derived applications (Your Phone is the one I always mention because IMO it's the most useful) and desktop widgets, sometimes drivers aren't labeled for use with Server SKUs (e.g. Intel iGPUs) and things like sound are treated as optional. But the interface rarely changes and it IS Windows, if that's what you want to use.
Linux/BSD/Solaris are all Unix-derivatives. There isn't MUCH reason to talk about OpenIndiana except that it may be important if you use it or used it in your day job, but it's more or less the last vestige of name-brand Unix (AIX still technically exists, if you have some giant rack of PowerPC gear and you're too good for Linux). Anyway, Solaris/OpenIndiana was the birthplace of ZFS, and like the Greeks inventing Democracy, nothing important has happened there ever since.
BSD is the original free UNIX, and in a way it's more rigidly defined and traditional than Linux, but it also misses some crucial functionality and flexibility that Linux has. Open, Free and NetBSD all have their own focus, but these days the only one of those that gets much real attention is OpenBSD, the PITA security-focused version, although the FreeBSD derived TrueNAS is probably the real star of late. The biggest problem in BSD space is that some things just never get driver support, which really hampers the choices available to users on that platform. One of the biggest differences between BSD-style Unix and Linux is the software license. BSD allows for modified, proprietary commercial derivatives, while the GNU license structure present for Linux demands that works derived from open code also remain open. A lot of entities REALLY dislike this, and by a lot I mean Apple.
Linux is a place where the rules are made up and the points don't matter. If you don't like something, you can fork it and change it, and people have. This has led to things like massive controversies over how the OS starts and holy wars over the graphical subsystems. In a lot of cases, we just have to pick something and live with it, but we can't deny that every single thing can be made to work on Linux. The biggest players in Linux are RedHat (part of IBM now) and its current mainstream alternative Rocky, Debian and its derivatives, which include the incredibly popular Ubuntu and Mint, and some random weirdos like the very traditional Slackware; Arch (favorite of trans furry web developers everywhere and also somehow what SteamOS is based on. Somebody might want to check how many Valve employees are on estradiol) and Gentoo, the Linux for people who definitely get boners when a Cenobite shows up at the end of the first act in every Hellraiser movie.
All of these OSes are just a means to an end. Running a server is generally about having a highly available and reliable system where services are run. What service? Why? Depends. A pretty straightforward example is having remote file services. Some people use a NAS for this, but there can be a case for full-fat file servers as well, especially if your needs encompass more than just SMB and NFS off a 4-bay QNAP and you want to run file deduplicaton or netboot clients. Windows doesn't offer native drive availability software on its desktop SKUs, so your RAIDn and cacheX storage solutions have to run on Windows Server, for example, whereas there are Linux releases that'll run on single board computers that can be made to speak SAS to a tape library if you really need that to happen for some misbegotten reason.
Most servers of any sort are really just a combination of a database and a particular sort of network traffic, but configuration is a lot easier when there's segregation between one service and another on an otherwise generic host system, so this is what we do most of the time. This can be handled through Guest instances that live in virtual machines or containerized (shared resource) systems in Docker or whatever. In any case, a lot of servers wind up hosting VMs or VM-like systems, so acting as a host for those smaller systems winds up being a big part of what physical server systems do. This is why we often talk about Hypervisor systems as a major part of our home environments.
Handruin seems to have his system set up so that he has one system for file services and another one or two for VMs or containers. My stuff more or less lives on giant do-everything systems instead, although to some degree that's because I already have that hardware on hand and don't want to buy something new to change how I handle things. I have a mix of Windows and Linux servers, so I have both Windows and Linux VM hosts as well.
