You’ve probably heard talk about how building servers is outdated, inefficient, or even downright dangerous.
Virtualized, containerized, and serverless solutions definitely provide some benefits over legacy, server-based architecture. And there are many times where these solutions are truly ideal for delivering modern applications.
But at the end of the day, all of these containerized solutions are simply tools, VMs, or applications running on someone else’s server. Managed solutions can be a fantastic relief, but they can also be a major source of frustration since you’re removed from the inner workings of the platform.
There are many times where it’s beneficial – or even imperative – to operate your own server. For instance, if you’re running a home NAS, or if you have special hosting needs.
Building, operating, and maintaining your own server is a great way to improve your sysadmin skills and to learn deep, nuanced aspects of the systems you work with.
Over the years I’ve built and operated servers running Debian, FreeBSD, Arch, Alpine, and Ubuntu. I’ve built physical NAS machines, VM hosts, and other servers in my home lab. And I’ve built countless production web, database, and development servers at AWS, Linode, and Azure. Some of these machines were built as a hobby, but the majority were built to handle professional workloads.
The act of building each of these servers has taught me something invaluable about my craft. Each server I build gives me the opportunity to learn and grow. I started with only the most basic fundamentals and have expanded my knowledge over time.
The experiences I have had over the years have shaped me and given me different and unique perspectives, to the point where I’ve made a concerted effort to move away from Linux and towards FreeBSD for all of my production work. I’ve also learned some surprising and interesting things along the way, like how to tune Apache for high performance and tweaking TCP settings to improve FTP connection speeds.
It’s OK to build servers. A lot of freedoms come from doing so, as do many responsibilities. Be curious and open to learning what those things are. Remember that each server is a unique entity that needs your time, attention, guidance, monitoring, and care.
If you’re going to build your own servers, be a good steward. Take some steps to do it in a smart way:
- Write thorough documentation. Taking good notes not only reinforces your present learnings but helps your future self remember details about actions from the past.
- Read up on hardening and security fundamentals. There’s lots of material out there. Review some of it and see what applies to your specific needs.
- Learn how to use SSH keys. Stop using passwords to connect to your machines. Consider closing off your SSH ports and opening them only to whitelisted IPs or over VPNs.
- Use a tool like Ansible manage your fleet’s state. Not only will this help you manage your entire server fleet, but it also helps reduce how unique all of your systems are. The goal here is to be able to rebuild any given server in a short amount of time, starting with a baseline playbook to privision the machine, and then playbooks to install whatever components you need.
- Keep your fleet up-to-date. When you build your own server, you’re on your own and are responsible for updating it. Don’t let your systems fall too far behind. Keep them patched and current.
- Don’t forget backups. Ansible playbooks stored in Git is a great start, but remember to backup any server-specific configuration or data so that if a machine goes haywire, you can rebuild it without too much hassle.