For practitioners who find it difficult to translate requirements into designs, I guide you through everything from the basis for decisions to completing the documentation, drawing on hands-on infrastructure design experience.
3 learners are taking this course
Level Basic
Course period Unlimited
You can structure business requirements and constraints into functional and non-functional requirements and prioritize them.
I can compare server, network, and storage configuration alternatives and explain the rationale for selecting among them based on cost, performance, scalability, and operability.
I can design system architecture and redundancy and recovery strategies based on assumptions about increased traffic, failures, and security threats.
I can create a system design document that includes the architecture, design rationale, risks, and open issues.
You can use design review checklists and Architecture Decision Records (ADRs) to review design proposals and reach consensus with stakeholders.
Infrastructure design is not about choosing equipment. It is about documenting what you choose within the requirements and constraints, and what you have not yet decided.
I’ve brought servers in. I’ve opened up the network, and I’ve run backups. But when asked, “Why did you do it this way?” during a design review, all I can come up with are product names. This course follows that question from the beginning through a single case study. It is not an installation lab or a process of following along by typing commands.
This is for you if
Those who have experience building or operating systems but are new to design documents
For those who can read an architecture diagram but couldn’t explain why it was divided that way
People who wrote that a system was redundant but couldn’t ask whether the remaining system would take over when one server stopped.
Those who reviewed quotes and proposals but couldn’t distinguish whether the choices stemmed from requirements and constraints
You can take this course even without knowing how to develop. However, you should at least be familiar with the terms server, network, and storage. It is not suitable for those looking to solve certification exam questions or learn the implementation procedures for a specific product, nor for those who already lead design reviews.
What This Course Does Not Cover
Even after completing it, you will not be able to finish designing any site on your own. This is not a course on choosing vendors, nor is it a course that settles redundancy or disaster recovery numerically. You will not leave with a finished product in which all the values have been finalized. Items for which there is still no answer are left open rather than being filled in with assumptions.
What order do we follow
We examine a single case starting with the requirements. Without using industry-specific terms, we first write down what the system does. Next come the constraints: budget, schedule, location, operations, existing equipment, and integrations with the outside. Until we hear the constraints, the choices that follow cannot be explained.
Using those conditions, divide the environment into zones and arrange the servers, network, storage, data, security, and backup in sequence. Each choice is accompanied by its rationale, the alternatives considered, what is gained and given up, and the risks that remain. Deferring a decision is also recorded. When it is noted why the decision was deferred and what is being awaited, it is not a blank space but a judgment.
Redundancy is not achieved simply by specifying the number of machines. We look at whether in-progress work is handed over, whether the data has been transferred, whether users arrive through the same path, who determines that a failure has occurred, and whether the failover happens automatically or manually. If even one of these conditions is missing, the service will stop even with two machines. We do not claim that something is not a single point of failure merely because there are two machines. If they depend on the same power supply or the same storage, that shared component is the single point of failure.
In the latter part, we revisit whether the numbers we initially assumed are still valid as assumptions. We do not write that something is sufficient before measuring it. Finally, we even work out the order for briefly explaining this design proposal to someone seeing it for the first time: what it does, what the conditions are, what the structure is, and what remains. We do not wait until we are asked a question to bring up what remains.
What remains after listening
The design proposal as of this point remains. It includes the conditions received as input, the design for each area, decision records, and a list of items that are still open, along with assumptions and risks. The deliverable includes stating the open items without hiding them. It is not a document to be submitted directly using the numbers from my own site, but a framework for rewriting one’s own conditions in the same order.
How should I listen to it?
Listen to the video, review with the on-screen PDF, and check the terminology in the transcript PDF. The screen shows keywords and diagrams. The sentences are explained verbally. The transcript is not a dictation; it contains the lecture’s sentences. When the terminology in the audio and the text differs, use the notation in the transcript as the standard.
You don’t have to review after every lecture. When you finish a section, just check once whether the choices in that section came from requirements and what remains open.
Who is this course right for?
Engineers with experience building and operating infrastructure who want to take their system design skills to the next level
Practitioners who can read architecture diagrams but have difficulty explaining the rationale and trade-offs behind architectural choices
Learners who have mastered the fundamentals of servers, networks, and storage and want to advance to intermediate system design.
Tech leads and IT professionals looking to systematize design reviews and technical decision documents
Need to know before starting?
Understanding the basic concepts of servers, networks, and storage
Hands-on experience building or operating IT infrastructure
Basic understanding of reading and writing technical documents
All
92 lectures ∙ (4hr 14min)
Course Materials:
Explore other courses in the same field!
Limited time deal
$10,032.00
20%
$77.00
