The first datacenter is simple. The second breaks the assumption that an IP address, a price and a piece of hardware are properties of a service rather than properties of a place.
Mario Marin6 min readThe first datacenter is simple. The second one breaks assumptions you did not know you had made — starting with the assumption that an IP address, a price and a piece of hardware are all just properties of a service rather than properties of a place.
Here is what changes when you sell from more than one site, and what your billing system has to model to keep up.
IP address pools. The most immediate and the most damaging to get wrong. Addresses are announced from a specific site. An address from your Frankfurt range cannot be assigned to a machine in Bucharest — it will not route, the customer will report a dead server, and the cause will not be obvious.
A billing platform that picks the first free address globally rather than the first free address at the right location will hand out unroutable addresses, and it will do it silently. If you are approaching a second site, this is the single question to ask your platform first.
Inventory and capacity. Racks, U-space, power and hardware all belong to a site. "Do we have capacity" is not a global question any more.
Price. Power costs differ, transit costs differ, staff costs differ, and taxes differ. A product priced for one site is subsidised or overpriced at another.
Lead time. A site with staff on the floor delivers faster than a remote one. If your storefront promises the same delivery time everywhere, one of the two is a lie.
Tax. The place of supply can differ, which is a compliance question rather than a preference — see EU VAT OSS for hosting providers.
1. Is location a product attribute or a product? Either you sell one "Dedicated Server 32 GB" with a location chosen at order time, or you sell a separate product per site. The first keeps the catalogue small and requires per-location pricing and stock on one product. The second is simpler in a basic billing system and multiplies your catalogue by the number of sites, and every price change becomes N changes.
Location-as-attribute is the better model and it only works if the platform supports per-location price and per-location availability. Without both, you are pushed into duplicating the catalogue.
2. Does the customer choose, or do you? If the customer chooses, location is part of the order and must be captured before payment — a paid order with no location is an order nobody can fulfil, and it is a surprisingly common dead end in checkout flows. If you choose, you need an allocation rule and you need to tell the customer where it landed.
3. What happens when a site is full? Out of stock at one location is not out of stock. The storefront should show the product as available elsewhere, with the correct price and lead time for that site, rather than either hiding it or selling capacity that does not exist.
Once you have two sites, aggregate revenue hides the thing you need to know: whether each site is worth running. Per-site revenue, per-site utilisation of rack and power, and per-site margin are what tell you where to put the next investment.
The metric that matters most in this segment is revenue per kW and revenue per rack unit, by site. It exposes a site that looks busy but is full of low-density, low-margin customers, which is a situation that looks fine in aggregate right up until you need capacity you have already given away cheaply.
Not everything should fragment, and over-localising causes its own problems.
The customer is global — one account, one login, one balance, one invoice covering services at several sites. A customer with servers in three locations should not receive three invoices from three systems. Support is global. Credit and dunning are global: a customer in arrears is in arrears everywhere, and suspending them at one site while continuing to serve them at another is a policy decision, not an accident to discover later.
Eventually a customer moves a service between sites. It is worth deciding in advance what that means commercially and technically, because it touches everything above at once: new IP allocation at the destination and release at the origin, rack and power freed at one end and reserved at the other, possibly a price change if the sites are priced differently, and a decision about whether the move is billed as a change to the existing service or as a new one.
The technical half — a machine that keeps a configuration pointing at its old site — is a well-known source of outages, because a moved service that retains stale location-specific settings will look correct in every record and fail in practice.
Deployment locations are first-class in FluxBilling: IP pools are scoped to a location so allocation draws from the correct site's range, hardware inventory and rack management belong to a site, and products carry per-location pricing and availability rather than requiring a duplicated catalogue per site. The customer stays single — one account, one balance, one invoice covering services across sites.
One trap worth naming from experience, because it is easy to hit and hard to diagnose: a service can be ordered without a location being captured, and the result is an order that cannot be fulfilled and a checkout that dead-ends. If you sell from more than one site, make location a required selection in the order flow and test the path end to end before you rely on it.
See IPAM, DCIM and billing colocation.
Before you open a second site, ask your billing platform one question: when a customer orders a server at location B, where does the IP address come from? If the answer is not "location B's pool, and only location B's pool", you have found the problem you will otherwise find on a customer's dead server three weeks after opening.
The gap between a signed colocation contract and a customer who is racked, powered and billing correctly is where operators lose time and sometimes the revenue entirely.
Colocation breaks generic billing software because you are selling physical space, a power envelope and a set of hands. Four or five recurring lines, each measured differently.
Power is what a datacenter actually runs out of, and it is the line item most often priced badly. Bundle it and you subsidise your densest customers with your sparsest.