Every enterprise starts with a business. Every IT architecture starts with requirements.
Most homelabs begin with a new tool.
"I want to try Kubernetes."
"I want to self-host Immich."
"I want to deploy Authentik."
Mine started exactly the same way and this is not necessarily an bad thing.
Over time, however, I noticed something. While I had many interesting services running, they rarely formed a coherent system. They solved individual problems, but they weren't designed as a complete environment.
Real companies don't work like that.
They don't choose technologies first and search for a use case afterwards. Instead, they start with business requirements, operational constraints and security goals. Technology is simply the result of those decisions.
This series is my attempt to recreate that process.
In this series I will build the IT infrastructure of a fictional company
Meet Fetched & Far GmbH
Fetched & Far GmbH is a is a fictional software company developing cloud-based business applications for customers across Europe.
The company currently employs around 120 people across two offices in Stuttgart and Zurich while supporting hybrid work for most employees.
The business expects rapid growth over the next five years and wants an IT infrastructure that scales without major redesigns.
Although the company itself is fictional, every architectural decision and implementation in this series will be based on real technologies and real-world best practices.
The Challenge of this Series
Imagine you're the first IT architect joining Fetched & Far GmbH
There is no existing infrastructure.
No Active Directory.
No VPN.
No Identity Provider.
No Monitoring.
No Backup System.
Everything must be designed from scratch.
At the same time, the company has clear expectations.
Developers need secure SSH access.
Employees should only have one account for all internal services.
Remote work must be supported securely.
Customer data has to be protected.
The environment should be observable, maintainable and scalable.
The goal is to design an infrastructure that supports the business.
But we have on benefit:
While most companies have tech dept and legacy system or decades-old servers that "can't be touched.", we do not have that and can completely start with modern design choices
In the next chapter we'll define Fetched & Far's business requirements and use them as the foundation for every architectural decision that follows
Design Principles
┌──────────────────────────────────────────────────────────────┐
│ Business First │
├──────────────────────────────────────────────────────────────┤
│ Technology exists to support the business—not the other │
│ way around. Every component should solve a real business │
│ problem and provide measurable value. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ Security by Default │
├──────────────────────────────────────────────────────────────┤
│ Security is built into the architecture from day one. │
│ Authentication, authorization, encryption and auditing │
│ should never be an afterthought. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ Simplicity │
├──────────────────────────────────────────────────────────────┤
│ Complexity should always be justified. Following the │
│ Business First principle, the simplest solution that │
│ satisfies the requirements is usually the best one. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ Automation │
├──────────────────────────────────────────────────────────────┤
│ Manual work doesn't scale. Repetitive tasks should be │
│ automated wherever possible to improve consistency, │
│ reduce human error and free up valuable time. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ Identity First │
├──────────────────────────────────────────────────────────────┤
│ Identity is the foundation of modern infrastructure. │
│ Every user, service and device should have a verifiable │
│ identity with only the permissions it actually requires. │
└──────────────────────────────────────────────────────────────┘
┌──────────────────────────────────────────────────────────────┐
│ Design for Failure │
├──────────────────────────────────────────────────────────────┤
│ Failures are inevitable. Systems should be designed to │
│ recover quickly through monitoring, backups and tested │
│ recovery procedures rather than assuming perfect uptime. │
└──────────────────────────────────────────────────────────────┘
Scope
During this series I'll design and implement concepts such as:
NOTE: This is still an ongoing series and this will be updated once it is finished
- Network architecture
- Identity & Access Management
- Single Sign-On
- Secrets Management
- Secure SSH access
- Internal PKI
- Reverse Proxy
- Git platform
- Documentation platform
- Monitoring & Alerting
- Centralized Logging
- Backup & Disaster Recovery
- Infrastructure as Code
- Incident Response
- High Availability
Some topics will be implemented immediately.
Others will first be designed and introduced when the fictional company reaches a size where they actually become necessary.
What This Series Is Not
This isn't a collection of installation tutorials.
I'm not trying to build the most complicated setup possible.
Instead, I want to answer questions like:
- Why would a company introduce Single Sign-On?
- When does centralized secrets management become useful?
- How should internal networks be segmented?
- Which trade-offs exist between simplicity and security?
- When is additional complexity actually justified?
Understanding those decisions is, in my opinion, far more valuable than learning another Docker command.