We're opinionated about hardware so you don't have to be.
Standardizing the boring infrastructure decisions is the service. It makes your workload the only variable left in the room.
In this article 4 sections
- We standardized the layers that should never be a coin flip: HPE 3PAR all-flash storage, dual Brocade Fibre Channel, our own network, our own compute.
- Standardization is not rigidity. We deviate only when your job earns it, and we build the exception because the baseline is known cold.
- One well-understood stack gets faults fixed faster than ten improvised ones. That is why this shows up in your uptime.
Open a typical server order form and count the decisions it asks you to make. Storage tier. RAID level. NIC bonding. Backplane. Hypervisor. Backup target. Replication mode. Each one is a fork, and every fork handed to you is homework.
Choice is a cost
A long configurator looks generous, but every pick on it is yours to own. You pick the storage tier, and if the IOPS turn out wrong for your database, that is your pick. Every option you select becomes yours to explain when the alert fires at 3am.
We think that is backwards. The infrastructure underneath your application is not where you should be expressing individuality. It is where you want the fewest surprises. So we made those decisions once, deliberately, and we stand behind every one of them. What you configure with us is your workload. Everything below it, we already settled.
The decisions we removed from your plate are the ones that fail silently for months and then all at once. Standardizing them is not us being inflexible. It is us taking on a risk that is ours to price.
What we standardized, and why
Storage: HPE 3PAR all-flash
Block storage lives on HPE 3PAR all-flash, active-active within the site with Peer Persistence, and replicated to a second site. Not a tier you upgrade into. The good storage is the only storage. You can see it on the private cloud page, and the drive wall is in the photos on our about page, because it is our wall, not a stock library's.
Fabric: dual Brocade Fibre Channel
Storage reaches compute over dual Brocade Fibre Channel, multipathed. Brocade fabrics have been in the doctrine for over a decade and never left.
Network: our own
Your traffic rides our own network: our own autonomous system, bilateral peering at GR-IX, Cisco ASR 9000 series at the edge and Nexus 9000 leaf-spine underneath, with EVPN/VXLAN carving a real per-tenant fabric on our own silicon.
Compute: our own servers
The machines are ours: HPE and Dell compute in a cage we built and label ourselves. Owning the equipment is what lets us stand behind the reliability we sell, and we have owned ours since 2004.
- OWN NETWORK
- our own autonomous system, edge to spine
- GR-IX PEERING
- bilateral, at the exchange
- HPE 3PAR FEDERATION
- all-flash, active-active in-site, replicated to a second site
- TENANT FABRIC
- EVPN/VXLAN, isolated per tenant
We deviate only when your job earns it
None of this means the answer is always the same box. It means the starting point is. Standardization is what makes a real exception possible: because we know exactly how the baseline behaves, we can tell precisely where your workload leaves it and build the deviation on purpose, not by guessing. Four sockets when the job needs four. A bespoke private cloud when the reliability target earns it. The exception is engineered, not improvised, and that is only true when the rule is solid.
Why this shows up in your uptime
Reliability is not a component you buy. It is what happens when a fault meets a stack the on-call engineer already understands.
An alert fires at 3am. What is the on-call engineer looking at?
A first encounter, every time
Every customer improvised a different stack, so every fault is a first encounter, and first encounters are slow.
A fault they've fixed before
Same fabric, storage, and network under everyone. The engineer has seen this exact class of fault. The surface is familiar, so the fix is fast.
Straight answers
Can I bring my own hardware preference?+
You can tell us what the job needs and we will build to it, up to and beyond the reference machine. What you cannot do is downgrade the parts we standardized to cut cost, because those are the parts that fail without warning and take your uptime with them. We deviate when the workload earns it, not when it cuts a corner.
Do you ever run non-3PAR storage?+
3PAR federation is the baseline for anything that needs real reliability, and it is what we photograph and publish. If a workload genuinely does not need federated block storage, we will say so and price you off it rather than sell you storage you will not use. The honest answer sometimes points down.
Is my box shared with anyone?+
On dedicated hardware, no. The serial number is on your invoice, and your cores are your cores. On a private cloud your tenant fabric is isolated over EVPN/VXLAN. Either way, the isolation is real, not a setting.
So what do I actually get to decide?+
Your workload: how big the job is, how it grows, and what reliability target it has to hit. That is the one fork that was always yours. The dedicated wizard down-sells you if you are aiming too high, and the private cloud path exists for when the reliability target earns it.
We are opinionated about hardware for one reason: so that you never have to be. Size your workload and let the rest be settled. The private cloud path is there when the reliability target earns it, and the pedigree behind all of it is on the about page.
See the metal we standardized on.
The reference build, the hardware behind it, and the price that is the same next year.
See the metalYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer