Home · Servers for cloud computing
Workload guide
Servers for cloud computing
A cloud node is a unit of a fleet, not a machine in its own right: identical, stateless and replaceable. This guide covers the node choices in our range and how fleet orders are quoted.
Two node shapes run most clouds
The scale-out tier — web, application and container hosts — is 1U territory: the PowerEdge R470 and R6615 and the ProLiant DL365 in our range, bought in rows, imaged identically, swapped without ceremony when they fail. The service tier — hypervisors, storage-fronting nodes, control planes — is 2U, where the memory and drive depth live.
Cloud fleets standardise ruthlessly: one 1U configuration and one 2U configuration, frozen, repeated. Our programme quoting is built for exactly that pattern — the configuration is written once and every stage ships against it.
What the fleet brief needs
- Node counts per shape, and the phasing if halls fill in stages.
- The image or hypervisor the nodes must land ready for.
- Spares ratio — the shelf stock that keeps the fleet whole between shipments.
Failure is a logistics property
At fleet scale, hardware failure is routine and the response is a swap, not a repair. Quotes for cloud programmes therefore carry the spares conversation explicitly: which components sit on the shelf at the site, and which ride the next shipment. Serial numbers per unit are available before shipment, so the fleet register can be built before the crates land.
The register is the fleet's memory
A cloud estate's most underrated asset is its hardware register: every node, its configuration, its serial number, its hall position, its service history. Fleets that keep it can answer the questions operations actually asks — which nodes carry the old drive model, which row loses capacity when a feed trips — in minutes. Fleets that do not, answer them by walking the hall with a torch.
The register is cheapest to build at purchase: configurations written per order, serial numbers available before shipment, deliveries logged against the plan. Our programme quotes are structured to feed it directly. Treat the register as part of the hardware purchase and the fleet stays legible at ten nodes and at a thousand.
Phasing the rollout
Cloud halls fill in waves, and the node order should be written the same way: a configuration frozen once, quantities phased against the hall plan, spares riding each wave. The paperwork discipline is what makes phasing safe — every wave quotes against the same written build, so a node installed in the fourth quarter is the twin of one installed in the first, and the fleet register grows by accretion instead of archaeology.
State the wave plan in the first inquiry, even if the later quantities are estimates. A programme priced with its phasing visible carries better totals than the same nodes bought as disconnected orders, and the configuration freeze protects the estate from the quiet drift that turns a fleet into a collection.
The short version
Freeze one configuration per node shape, phase the quantities against the hall plan, keep the register from the first crate, and let failure be a swap rather than an event. A cloud estate run that way scales by administration rather than by heroics — and the supply side of it is exactly what this desk's programme route is built to feed.
Questions buyers ask
Can cloud nodes be quoted in stages?
Yes — phasing is written into programme quotes with the configuration frozen across stages.
Do you supply container-platform hardware differently?
The nodes are the same 1U and 2U machines; the brief changes (more memory per node, less local storage), not the range.
Price a configuration like this
Send the model name, your target configuration and the delivery destination. We reply with a configuration-matched quote and the checks to run before shipment.