Enterprise infrastructure briefing

Virtualisation, storage, networking and resilience

The compute, data, network and recovery foundations that keep modern services running.

VirtualisationStorageNetworkingBackupObservabilityLifecycle

Infrastructure is the part of technology most people notice only when it fails. Applications can be modern, interfaces can be polished and cloud strategies can be ambitious, but services still depend on compute, storage, networks, identity, recovery and the people and processes capable of operating them.

This is my living guide to enterprise IT infrastructure. It covers traditional and software-defined platforms, local and hybrid estates, and the practical design questions that decide whether infrastructure is simply installed or genuinely resilient.

Last reviewed: 5 September 2026. Supporting guides are refreshed as new relevant articles are published.

The infrastructure stack

Virtualisation: choose the operating model, not just the hypervisor

Virtualisation decisions used to be dominated by feature comparison because the leading platforms were relatively similar in operating model. Licensing changes, HCI, software-defined storage and stronger open-source alternatives have made the choice broader.

VMware, Hyper-V, Proxmox and HCI platforms can all run virtual machines. The more important differences are around clustering, storage integration, backup compatibility, automation, vendor support, skills, licensing and how much operational complexity the organisation is willing to own.

A platform that is technically cheaper can become expensive if the team cannot support it confidently. A premium platform can become poor value if its capabilities go unused. The right choice is the one whose operating model matches the organisation.

Storage: performance, protection and failure domains

Storage architecture is easy to reduce to capacity and IOPS. Those numbers matter, but they are only part of the design. Failure domains, controller behaviour, rebuild time, snapshot design, replication, firmware lifecycle, support and integration with the compute platform are often more important during the life of the system.

SAN, HCI and software-defined storage move complexity around. A SAN concentrates storage into a dedicated platform with clear boundaries. HCI couples compute and storage more closely and can simplify procurement and scaling for the right workload. Software-defined platforms such as Ceph offer flexibility but demand an operational understanding of the cluster underneath them.

The useful question is not which model is modern. It is which failure modes the team understands and can recover from.

Networking is application infrastructure

Networks are no longer just the cables between servers. VLANs, routing, firewalls, DNS, internet paths, cloud connectivity, load balancers and identity-aware access controls determine how an application behaves and which failures can isolate it.

Redundancy also needs to be real. Two switches do not create resilience if both depend on one uplink. Two internet circuits do not help if they share a physical path. Multiple application servers do not create availability if every node relies on one DNS resolver or firewall state.

I prefer network diagrams that show service paths and failure domains rather than simply device icons. They make architecture easier to test because each dependency can be challenged.

Backup and resilience are separate from availability

High availability reduces interruption when a component fails. Replication keeps another copy of current data. Backup preserves recoverable versions across time. Disaster recovery provides a way to restore a service after a larger failure. They overlap, but they are not substitutes.

Ransomware made this distinction harder to ignore. A highly available platform can replicate corruption very efficiently. A backup repository that uses the same credentials and administrative plane as production can be compromised along with it. Immutability, separation and tested recovery are therefore architectural controls rather than backup-product features.

Recovery objectives should drive design. An RPO and RTO written in a policy have little value until somebody has measured how long a representative service actually takes to restore.

HCI: simpler boundaries, different trade-offs

Hyperconverged infrastructure can remove some of the boundaries between compute and storage and make scaling more modular. That can be useful, particularly where the organisation values a single lifecycle and an integrated support model.

The trade-off is coupling. Compute and capacity may need to scale together. Network design becomes part of storage performance. Failure domains can be less obvious to teams used to a separate SAN. The right HCI design therefore depends on workload shape and operating preference, not simply on whether three boxes can form a cluster.

Observability: know before the user tells you

Monitoring should explain service health, not merely display component status. CPU graphs and ping checks are useful, but they do not tell an operator whether a user can authenticate, whether a backup completed, whether storage latency is rising or whether a certificate will expire next week.

Good observability brings metrics, logs, dependency information and operational context together. It also controls noise. An alert that is ignored every day is not monitoring; it is background decoration.

Lifecycle decisions matter as much as day-one design

Infrastructure has a long memory. A five-year platform accumulates firmware dependencies, operating-system versions, backup integrations, application assumptions and undocumented workarounds. Refresh decisions should therefore consider supportability and operational risk alongside hardware performance.

I would normally look at vendor support windows, hardware fault history, capacity trend, software compatibility, security requirements, recovery confidence, licensing changes and the cost of maintaining specialist knowledge. Sometimes the right answer is new hardware. Sometimes it is a platform change. Sometimes the current system is still perfectly fit for purpose.

Infrastructure decision checklist

• What service-level requirement is the platform actually supporting?
• Where are the true single points of failure?
• Which components can fail without operator intervention?
• Can the team diagnose a degraded state before it becomes an outage?
• Are backup and recovery independent enough to survive compromise of production?
• How long does a representative restore actually take?
• What is the capacity and support horizon?
• Does the architecture remain understandable to more than one person?

Latest infrastructure analysis

Infrastructure in a cloud world

For hybrid and cloud workload placement, continue with the Cloud & Hybrid Infrastructure pillar. For Windows Server, Hyper-V, Azure and Entra dependencies, see the Microsoft Technology pillar. The Technology pillar provides the wider map.