DataCenter.BZ et le prix du contrôle local en colocation à Columbus

La première question de l’acheteur local est le contrôle

Imaginez un fournisseur de services gérés dans l’Ohio confronté à un problème familier. Un client du secteur de la santé souhaite une reprise après sinistre prévisible. Un district scolaire veut des serveurs en dehors de ses propres bâtiments, mais suffisamment proches pour des visites physiques. Un fabricant dispose d’une application métier qui ne justifie pas un projet national de migration vers le cloud, mais qui ne peut pas non plus vivre sous un bureau ou dans un placard. Le fournisseur peut revendre de la capacité d’une région cloud hyperscale, ou il peut placer l’équipement du client dans un centre de données local où le fournisseur connaît les ingénieurs, le chemin de cross-connect, le quai de chargement, les règles d’alimentation et la véritable chaîne d’escalade.

C’est le cadre pratique pour DataCenter.BZ, LLC. L’entreprise n’est pas importante parce qu’elle est devenue une marque mondiale. Elle est importante parce qu’elle montre comment un opérateur de colocation régional a pu devenir une couche de contrôle pour les petites entreprises, les hébergeurs, les organismes publics, les écoles, les systèmes de santé, les opérateurs de réseaux et les fournisseurs de services qui avaient besoin d’un endroit où l’espace en baie, le support local, la densité de puissance et l’accès aux opérateurs se rejoignaient dans une seule installation à Columbus. Le dossier public a maintenant deux visages. Le site Web actuel de DataCenter.BZ à l’adressehttp://www.datacenter.bz/ne se comporte plus comme un site opérationnel actif; il renvoie vers une page d’atterrissage de type parking à l’adressehttps://www.datacenter.bz/lander. En même temps, PeeringDB conserve toujours une fiche d’organisation DataCenter.BZ, LLC à l’adressehttps://www.peeringdb.com/org/7026, et les documents actuels de Cologix sur Columbus identifient les sites de Scherers Court comme des éléments actifs d’une plateforme de centres de données Columbus beaucoup plus vaste.

Cette division est importante. Un acheteur qui ne regarderait que l’ancien domaine y verrait de l’incertitude. Un acheteur qui examinerait les installations acquises y verrait une histoire continue d’interconnexion à Columbus. La signification économique de DataCenter.BZ se situe entre ces deux signaux: l’entreprise d’origine a construit un actif de colocation local suffisamment précieux pour être acquis, et l’actif acquis a contribué à ensemencer une plateforme Columbus qui est maintenant commercialisée autour du choix de réseau, de l’accès au cloud et de la capacité à haute densité. L’entreprise doit donc être lue comme une entité opérationnelle héritée dont l’identité publique s’est estompée tandis que sa logique d’installation a survécu au sein d’une plateforme plus vaste.

La proposition de valeur d’origine n’était pas mystérieuse. DataCenter.BZ vendait ce qui rend la colocation locale attrayante lorsqu’un client est trop sensible sur le plan opérationnel pour un hébergement à bas prix et trop pratique pour le cloud pur: espace de baie, cages, alimentation à haute densité, diversité des opérateurs, fibre noire, environnements conformes, infrastructure virtuelle, espace de travail de reprise après sinistre et support 24 heures sur 24. Son propre communiqué de 2013 décrivait le siège social à Columbus, la colocation à haute densité, les services de centre de données virtuel, un campus à la convergence de la fibre régionale, municipale et interurbaine, et 32 000 pieds carrés de faux-plancher, avec un deuxième complexe de 90 000 pieds carrés de faux-plancher alors en développement; le communiqué est toujours disponible à l’adressehttps://www.prnewswire.com/news-releases/datacenterbz-is-the-fastest-growing-data-center-provider-in-columbus-ohio-228316851.html. Ce n’est pas un récit hyperscale. C’est un récit d’infrastructure régionale: les entreprises locales voulaient transformer les dépenses en capital en service mensuel, mais elles voulaient toujours la proximité, le contrôle et des personnes qu’elles pouvaient appeler.

Le jugement qui en découle est simple. DataCenter.BZ était le plus fort économiquement là où les clients de Columbus accordaient plus d’importance au contrôle opérationnel local qu’à l’échelle de la marque. Sa faiblesse était que cette même couche de contrôle nécessitait du capital, de la puissance, des relations de réseau et une crédibilité qu’il est devenu plus facile de financer au sein d’une plateforme plus vaste. L’acquisition par Cologix en 2014 n’a donc pas été une note de bas de page. C’était le résultat attendu pour une installation qui avait dépassé le bilan d’un petit fournisseur local tout en conservant une valeur stratégique en tant que point d’interconnexion.

L’entreprise est plus claire après l’acquisition qu’avant

DataCenter.BZ, LLC apparaît dans les registres d’infrastructure publique comme une entreprise liée à la colocation et à l’infrastructure de réseau de la région de Columbus. La page d’organisation PeeringDB à l’adressehttps://www.peeringdb.com/org/7026répertorie DataCenter.BZ, LLC, deux installations et une entrée de réseau associée à AS40715. Deux pages d’installation fournissent les preuves de localisation les plus concrètes. La page d’installation Worthington-Columbus à l’adressehttps://www.peeringdb.com/fac/1328indique DataCenter.BZ - Worthington-Columbus au 535-575 Scherers Ct., Worthington, Ohio 43085, avec cinq réseaux répertoriés et une date de dernière mise à jour en septembre 2025. La page d’installation Datacenter.BZ à l’adressehttps://www.peeringdb.com/fac/1420indique 535 Scherers Court, Columbus, Ohio 43085, sans échange local ni réseau répertorié sur cette page d’installation.

Ces enregistrements ne doivent pas être interprétés comme un profil opérationnel complet et actuel. PeeringDB est une base de données d’interconnexion publique, et les enregistrements peuvent conserver une dénomination héritée, l’historique de l’opérateur et un contexte d’installation maintenu par la communauté. Le site Web actuel ne propose plus l’ancien discours de service. Il est plus prudent de considérer que DataCenter.BZ reste une étiquette utile pour les preuves d’installation et de réseau héritées de Columbus, tandis que la plateforme commerciale opérationnelle est maintenant Cologix. Cela correspond au communiqué d’acquisition de Cologix de 2014, conservé au format PDF à l’adressehttps://www.cologix.com/pdf/PressReleases/2014-02-04-Cologix-Acquires-DataCenter.BZ-In-Columbus-Ohio.pdf. Le communiqué indiquait que Cologix avait conclu une transaction pour acquérir DataCenter.BZ à Columbus, décrivait deux centres de données neutres vis-à-vis des opérateurs sur 32 000 pieds carrés de faux-plancher, et identifiait l’actif comme un point d’interconnexion de premier plan dans l’Ohio avec 30 choix de réseaux et OHIO-IX dans les salles de rencontre.

L’économie de l’acquisition était inhabituellement spécifique. Cologix a déclaré que la transaction comprenait cinq acres de terrain, des bâtiments, des installations critiques, plus de 100 clients, un conduit métropolitain et des actifs de fibre noire, et plus de 5 millions de dollars d’EBITDA annualisé. Pour une entreprise de colocation régionale, cet ensemble explique la logique du prix mieux que n’importe quelle étiquette générique de « centre de données ». L’EBITDA montrait des revenus de services récurrents. Plus de 100 clients montraient une diversification. La fibre noire et le conduit montraient un contrôle sur les routes, pas seulement sur les salles. Le terrain et les bâtiments donnaient à Cologix la possibilité de s’étendre. La continuité de l’équipe comptait parce que la qualité du support faisait partie du produit.

Les revendications techniques d’avant l’acquisition étaient également plus solides qu’un slogan de brochure. Une proposition de l’échange 7x24 du printemps 2012 pour une étude de cas d’Emerson Network Power et de DataCenter.BZ, disponible à l’adressehttps://www.7x24exchange.org/downloads/7x24SP12_pres.pdf, décrivait le siège social de DataCenter.BZ au 535 Scherers Court, Gordon Scherer comme président, une deuxième expansion de centre de données neutre vis-à-vis des opérateurs en 2011, un PUE de l’installation de 1,25 ou moins, une redondance 2(N+1) sur l’infrastructure critique d’alimentation et de refroidissement, et un faux-plancher de 32 000 pieds carrés conçu pour environ 500 watts par pied carré. Il décrivait également une densité de baie moyenne de 5 à 10 kW et des déploiements de baies à haute densité jusqu’à 90 kW, avec 50 kW dans les déploiements de baies standard. Ces chiffres font moins ressembler l’entreprise à un petit atelier d’hébergement qu’à une installation régionale essayant de vendre une infrastructure d’entreprise à haute densité avant que Columbus ne devienne une histoire de croissance nationale des centres de données.

La couverture de l’acquisition par Data Center Knowledge à l’adressehttps://www.datacenterknowledge.com/next-gen-data-centers/cologix-acquires-datacenter-bz-in-columbus-ohiodonne la même forme sous un angle d’actualité du secteur: Cologix a acquis DataCenter.BZ et son installation de 32 000 pieds carrés à Columbus, les clients ayant accès à 30 choix de réseaux et à OHIO-IX dans les salles de rencontre. Le rapport de Fierce Network à l’adressehttps://www.fierce-network.com/telecom/cologix-snaps-up-datacenter-bz-establishes-ohio-data-center-footholdajoute le cadrage stratégique. Cologix entrait dans l’Ohio, Columbus était traité comme un marché de deuxième rang avec un potentiel de périphérie, et l’installation acquise était présentée comme hautement connectée pour sa région.

Cela signifie que l’identité de l’entreprise n’est pas mieux comprise par le seul ancien domaine. Elle est mieux comprise par une séquence. DataCenter.BZ a été fondée et promue en tant que fournisseur de colocation à haute densité et d’infrastructure virtuelle à Columbus. Elle a construit une densité locale suffisante pour attirer les opérateurs et les entreprises clientes régionales. Cologix l’a achetée comme une tête de pont d’interconnexion. Ensuite, Cologix a étendu la plateforme Columbus bien au-delà de l’empreinte d’origine. Le nom DataCenter.BZ reste pertinent parce qu’il marque l’origine de la couche de contrôle de Columbus acquise, et non parce qu’il semble encore être la marque commerciale active.

Scherers Court a rendu la thèse physique

Les preuves publiques les plus solides pointent vers un lieu spécifique, et non une vague revendication métropolitaine. Scherers Court dans la région de Worthington-Columbus est l’épine dorsale de l’histoire. L’annonce de Hurricane Electric en 2012 à l’adressehttps://www.he.net/releases/2012-10-03.htmlindiquait qu’elle avait établi un point de présence dans l’installation de DataCenter.BZ au 555 Scherers Court à Columbus. Le même communiqué décrivait DataCenter.BZ comme une entreprise de Columbus offrant une colocation à haute densité et une infrastructure virtuelle à partir d’installations dédiées neutres vis-à-vis des opérateurs, avec un accès aux réseaux de fibre régionaux, municipaux et privés. Il expliquait également pourquoi le point de présence était important: Hurricane Electric pouvait atteindre l’Ohio et le Midwest plus large plus efficacement, tandis que les clients de DataCenter.BZ pouvaient accéder à une autre dorsale mondiale via des cross-connects et des fournisseurs de transport.

Les preuves d’adresse correspondent ensuite aux pages Columbus actuelles de Cologix. La vue d’ensemble de Columbus de Cologix à l’adressehttps://cologix.com/data-centers/columbus/répertorie COL1 au 535 Scherers Court et COL2 au 555 Scherers Court. COL1 est décrit plus en détail à l’adressehttps://cologix.com/data-centers/columbus/col1/comme un hub d’interconnexion avec une infrastructure de qualité entreprise, une connectivité régionale dense, un centre de données dédié de 44 000 pieds carrés, des baies personnalisées, des cages et des suites privées, 30 MW de puissance électrique disponible sur place, plus de 45 réseaux uniques dans une salle de rencontre contrôlée par Cologix et un support local. COL2 à l’adressehttps://cologix.com/data-centers/columbus/col2/est décrit comme un centre de données de qualité entreprise sur le même campus de Columbus, également axé sur le carrefour de la fibre interurbaine, la fibre des opérateurs régionaux, la disponibilité, le choix du réseau, les baies personnalisées, les cages sécurisées et les cas d’utilisation de reprise après sinistre.

L’arithmétique des installations est désordonnée d’une manière utile. PeeringDB utilise 535-575 Scherers Ct. pour une installation et 535 Scherers Court pour une autre. Hurricane Electric nommait 555 Scherers Court. Les pages de Cologix séparent 535 Scherers Court comme COL1 et 555 Scherers Court comme COL2. Le communiqué d’acquisition utilisait 32 000 pieds carrés de faux-plancher, tandis que les pages actuelles de Cologix parlent d’installations dédiées de 44 000 pieds carrés sur le campus. La proposition 7x24 décrivait un siège social de 66 000 pieds carrés et un deuxième ajout de centre de données neutre vis-à-vis des opérateurs. Ce n’est pas une raison pour écarter les preuves. C’est une raison pour lire les chiffres comme différentes coupes d’un campus: le faux-plancher, l’enveloppe du bâtiment, les phases anciennes/nouvelles, et l’emballage ultérieur de Cologix ne sont pas toujours la même mesure.

La continuité n’est pas seulement géographique. Les anciens documents de DataCenter.BZ mettaient l’accent sur la convergence de la fibre, les baies à haute densité, la conformité, le support local et les postes de travail de reprise après sinistre. Les pages actuelles de Cologix pour COL1 et COL2 mettent l’accent sur l’interconnexion dense, les emplacements de Scherers Court, la puissance élevée par baie, les entrées de fibres multiples, l’espace de travail d’urgence, l’ingénierie et le support 24 heures sur 24, et la capacité de sauvegarder les sites principaux à Chicago et à New York. Le langage est passé de fournisseur local dirigé par son fondateur à une plateforme nord-américaine, mais la thèse opérationnelle est reconnaissable.

Cette preuve physique aide également à expliquer pourquoi une installation de Columbus pouvait servir un acheteur choisissant entre la colocation locale et une région hyperscale. L’acheteur ne se contente pas de louer de l’espace. L’acheteur choisit une position de contrôle. Une baie dans une installation à forte densité d’opérateurs permet des circuits privés, une diversité de transit Internet, un peering direct, des interventions à distance, des accès au cloud via la plateforme Cologix plus large, et la possibilité de conserver la propriété physique du matériel. Une machine virtuelle dans une région cloud distante offre vitesse et étendue de service, mais le client cède une partie du contrôle physique, une partie de la clarté des achats et souvent une partie de la capacité à isoler l’économie des chemins réseau. Pour de nombreux clients du marché intermédiaire, la question n’est pas cloud contre colocation. C’est de savoir quelles charges de travail méritent quel modèle opérationnel.

Scherers Court a résolu la partie de cette question que le cloud ne résout pas automatiquement: où placer l’infrastructure partagée pour les clients qui ont besoin à la fois de proximité et de choix de réseau. Un fournisseur de services gérés de Columbus pouvait placer les sauvegardes, les pare-feu, les baies de stockage, les serveurs appartenant aux clients et les interconnexions privées dans un centre de données local, puis décider charge de travail par charge de travail ce qui devait aller dans le cloud public. C’est la niche commerciale que DataCenter.BZ occupait.

Le modèle d’affaires vendait de la certitude en unités mensuelles

La revendication économique la plus importante dans le communiqué de DataCenter.BZ de 2013 n’était pas le prix de la croissance. C’était la conversion des dépenses en capital des clients en dépenses opérationnelles prévisibles. Le communiqué à l’adressehttps://www.prnewswire.com/news-releases/datacenterbz-is-the-fastest-growing-data-center-provider-in-columbus-ohio-228316851.htmldécrivait des clients réduisant leurs coûts opérationnels et d’investissement, répondant aux exigences de disponibilité et de conformité, et remplaçant les investissements en capital individuels persistants par des dépenses de service évolutives. C’est le marché fondamental de la colocation.

Pour les petits acheteurs d’entreprise et d’hébergement, le coût total d’une salle de serveurs interne est rarement visible au premier abord. Le premier rack semble bon marché. Viennent ensuite les circuits d’alimentation redondants, le renouvellement des UPS, l’entretien des générateurs, le refroidissement, la suppression des incendies, la sécurité physique, la surveillance, les contrats avec les opérateurs, l’accès d’urgence, le personnel en dehors des heures de bureau, les audits et la question inconfortable de savoir si un bâtiment conçu pour le travail de bureau devrait également servir d’infrastructure critique. La colocation convertit ces charges partagées en frais de baie, de cage, d’alimentation, de bande passante, d’intervention à distance, de cross-connect et de support.

La logique des revenus suit la même structure. DataCenter.BZ pouvait monétiser l’espace par baie ou cage, la puissance par capacité, la connectivité par cross-connects et relations avec les opérateurs, l’infrastructure virtuelle par couche de service, la reprise après sinistre par espace de travail ou package de continuité, et la fidélisation des clients par la dépendance opérationnelle. Une fois l’équipement installé, les circuits commandés, les politiques écrites et les sauvegardes dirigées vers l’installation, le désabonnement est coûteux pour le client. Le client peut négocier le prix, mais il ne déplace pas les racks à la légère.

Cela explique pourquoi plus de 5 millions de dollars d’EBITDA annualisé étaient un chiffre pertinent pour l’acquisition dans le PDF de Cologix. L’EBITDA dans ce contexte implique une base de revenus récurrents de colocation, de connectivité et d’infrastructure gérée après les coûts d’exploitation de l’installation. Ce n’est pas la même chose que des revenus logiciels à forte marge, car les centres de données supportent des coûts immobiliers, d’alimentation, de refroidissement, de maintenance, de personnel et d’investissement. Mais c’est attrayant quand l’actif contrôle également une densité d’interconnexion locale rare. La marge n’est pas seulement un loyer. C’est le loyer plus la fiabilité plus l’optionalité du réseau plus l’inertie du client.

Le marché public des prix donne une base utile pour l’économie du petit acheteur. La page de tarification de la colocation en Ohio de CeraNet à l’adressehttps://www.cera.net/home/ohio-server-rack-cage-colocation-cost/annonce la colocation individuelle d’un serveur 1U à 139,95 $ par mois avec une alimentation standard et un rack dédié complet à 950 $ par mois avec une alimentation de 20 ampères, plus des frais pour l’alimentation supplémentaire. Le site plus large de CeraNet à l’adressehttps://www.cera.net/services/colocation/features-specs/met l’accent sur les options sans frais de démarrage, une tarification prévisible, des contrats flexibles, des conseils techniques et un support local. Ce ne sont pas les prix de DataCenter.BZ, mais ils montrent la grammaire des prix qu’un acheteur local comprend: les unités de rack, les racks complets, les circuits d’alimentation, les ports, la disponibilité, le support et les remises annuelles.

Pour une installation à l’échelle de Cologix, de nombreux contrats seront personnalisés plutôt que tarifés à la carte. Néanmoins, le marché local tarifé à la carte aide à expliquer pourquoi la niche de DataCenter.BZ existait. Un petit client peut commencer avec un ou deux serveurs, puis passer à un rack, puis à une cage, puis à un mélange de cloud et de colocation. L’installation qui héberge le déploiement précoce de ce client a une chance de devenir l’emplacement par défaut pour les nouveaux pare-feu, le stockage, les appliances de sauvegarde, les transferts d’opérateurs et le matériel spécifique au client. En ce sens, la colocation locale peut devenir la surface opérationnelle physique d’un fournisseur de services gérés. Le fournisseur vend des services, mais l’installation rend ces services fiables.

La comparaison avec le cloud ne se limite pas au prix du calcul

Pour le fournisseur de services gérés, la véritable comparaison n’est pas un serveur nu contre une instance cloud. C’est la facture mensuelle après avoir comptabilisé la bande passante, la croissance du stockage, l’accès physique, les cross-connects, les visites de conformité et le support. La page de tarification EC2 d’AWS à l’adressehttps://aws.amazon.com/ec2/pricing/on-demand/indique que les clients reçoivent 100 Go de transfert de données sortant vers Internet gratuitement par mois sur la plupart des services et régions AWS, puis paient les taux de transfert de données sortant par palier. La même page répertorie les 10 premiers To par mois à 0,09 $ par Go, les 40 To suivants à 0,085 $ par Go, les 100 To suivants à 0,07 $ par Go et les volumes supérieurs à 150 To à 0,05 $ par Go. Cela signifie qu’une charge de travail sortante stable de 10 To/mois peut ajouter près d’un poste de dépense mensuel de la taille d’un rack avant que l’acheteur n’ait payé le calcul, le stockage, le support, la surveillance, la sauvegarde ou la connectivité privée.

AWS Direct Connect modifie la comparaison, mais ne rend pas la bande passante gratuite. La page de tarification d’AWS Direct Connect à l’adressehttps://aws.amazon.com/directconnect/pricing/indique que la tarification dépend de la capacité, des heures de port et du transfert de données sortant via l’emplacement Direct Connect; elle indique également que le transfert de données entrant via Direct Connect est facturé à 0,00 USD par Go. La page Columbus de Cologix indique que son centre de données de Columbus héberge un nœud AWS Direct Connect. C’est un avantage pour un acheteur hybride de Columbus car la connectivité privée peut réduire la latence et rendre le routage du trafic plus prévisible. C’est toujours un choix de conception payant. Un client a besoin d’un port ou d’une connexion hébergée, d’un fournisseur local ou d’un chemin de cross-connect, de compétences en routage et d’une valeur de trafic suffisante pour justifier les éléments fixes et variables.

C’est là que l’ancienne proposition de valeur de DataCenter.BZ se lit encore comme économiquement précise. Un MSP local pouvait utiliser un rack de Scherers Court pour les appliances, les cibles de sauvegarde, les serveurs appartenant aux clients, les charges de travail limitées par les licences et les circuits privés, puis utiliser AWS pour les frontaux élastiques ou les services gérés. Le MSP pouvait conserver le trafic est-ouest ou de sauvegarde à volume élevé à l’intérieur de l’installation locale, utiliser le cloud de manière sélective et éviter de transformer chaque restauration, réplica ou téléchargement client en un événement de sortie. Le rack local n’éliminait pas les dépenses cloud. Il donnait au MSP un endroit pour décider quels octets méritaient une tarification cloud et quels octets appartenaient à l’équipement sous contrôle local.

L’arithmétique approximative de l’acheteur ressemble à ceci. Un rack local complet de style CeraNet à 950 $ par mois avec un port dédié de 100 Mbps n’est pas équivalent à un contrat Cologix, mais il donne la partie inférieure de la grammaire des prix de Columbus. Un palier de sortie AWS à 0,09 $ par Go fait que 10 To de trafic sortant valent environ 900 $ avant les autres postes cloud si le trafic est facturé dans ce palier. Un acheteur de colocation gérée avec du matériel en propriété, un trafic stable et une charge de support prévisible peut préférer des frais fixes d’installation et de transit. Une équipe logicielle qui valorise les bases de données gérées, la mise à l’échelle automatique et le déploiement mondial peut encore préférer le cloud. DataCenter.BZ comptait parce qu’elle donnait aux acheteurs du centre de l’Ohio une position intermédiaire crédible: l’économie du matériel local sans le fardeau de posséder l’usine de centre de données.

PeeringDB fait passer la lecture de l’immobilier à la surface de contrôle

Sans PeeringDB, DataCenter.BZ pourrait ressembler à une histoire d’immobilier et d’hébergement. Avec PeeringDB, cela devient une histoire d’interconnexion. La page d’organisation à l’adressehttps://www.peeringdb.com/org/7026répertorie toujours DataCenter.BZ, LLC avec des installations et une entrée de réseau. La page d’installation Worthington-Columbus à l’adressehttps://www.peeringdb.com/fac/1328répertorie cinq réseaux: Amplex Electric, DataCenter.BZ, Everstream, Fidelity Voice & Data et Horizon Telcom. La page d’installation Columbus à l’adressehttps://www.peeringdb.com/fac/1420répertorie la même organisation et la même famille d’adresses mais n’affiche actuellement aucun réseau pair sur cette page.

Le signal de cinq réseaux sur la page Worthington-Columbus est modeste par rapport à un grand hôtel de télécommunications, mais il est significatif pour une installation de colocation locale. Il montre que l’emplacement n’est pas simplement une salle alimentée; il a une pertinence d’interconnexion suffisante pour être représenté dans une base de données publique de peering. Les noms sont également logiques au niveau régional. Everstream et Horizon Telcom correspondent à un cadre de connectivité du centre de l’Ohio, tandis que l’entrée de réseau DataCenter.BZ pointe vers l’historique du réseau propre de l’installation. C’est précisément le type de preuve qui compte pour un fournisseur de services gérés: quels réseaux peuvent être atteints, quels opérateurs sont physiquement ou opérationnellement proches, et si le centre de données peut prendre en charge des connexions privées plutôt que du simple transit Internet générique.

Les preuves BGP ajoutent une autre couche, mais elles nécessitent une manipulation prudente. La page BGP Toolkit de Hurricane Electric à l’adressehttps://bgp.he.net/AS40715identifie actuellement AS40715 comme Cologix, Inc., affiche toujours le champ du site Web de l’entreprise commehttp://www.datacenter.bz/, et répertorie des préfixes dont un décrit comme DataCenter.BZ, LLC. BGP.tools à l’adressehttps://bgp.tools/as/40715identifie AS40715 comme Cologix, Inc., affiche le site Web commehttp://www.datacenter.bz/, marque le réseau actif et alloué sous ARIN, répertorie 10 préfixes IPv4 et un préfixe IPv6 originaires, et affiche 67.154.188.0/22 avec une description DataCenter.BZ, LLC. ARIN RDAP à l’adressehttps://rdap.arin.net/registry/autnum/40715donne la vue du registre: AS40715, nom COLOGIX-COL, date d’enregistrement 2008-03-03, dernière modification 2022-08-18. Ces pages ne font pas de AS40715 le sujet de l’article. Elles montrent que les enregistrements de routage préservent la transition de DataCenter.BZ à Cologix et que l’ancien nom reste visible dans les traces de ressources réseau.

La même mise en garde s’applique aux enregistrements de registre de route de style RADB. Ce sont des preuves opérationnelles, pas un récit d’entreprise. Ils peuvent révéler qui maintient les objets de routage, quels noms apparaissent encore dans les descriptions de route et comment les actifs hérités sont intégrés dans un réseau plus vaste. Ils ne disent pas à un acheteur la qualité du service client, l’historique de disponibilité, la tarification ou les conditions contractuelles. Pour cet article, leur rôle est plus étroit: ils confirment que l’empreinte de DataCenter.BZ s’étendait au-delà d’un nom de bâtiment dans les enregistrements d’administration de réseau et d’interconnexion.

PeeringDB met également en évidence l’incertitude de réputation autour de l’identité autonome de DataCenter.BZ. L’enregistrement de l’organisation existe, les enregistrements d’installation sont récemment mis à jour et la piste d’adresse est concrète. Mais le site Web actuel est en stationnement, la marque publique n’est plus active de la manière qu’un acheteur de colocation de détail attendrait, et les pages actuelles de Cologix sont la source la plus utile pour les détails opérationnels. Les preuves soutiennent donc une thèse d’entreprise héritée: DataCenter.BZ a construit le point de contrôle; Cologix le commercialise et l’étend maintenant.

La fibre de Columbus a rendu la colocation locale plus qu’un simple stockage local

La thèse de DataCenter.BZ dépend du fait que Columbus est plus qu’un endroit moins cher pour placer des racks. Le site Web d’Ohio IX à l’adressehttps://ohioix.net/décrit Columbus comme un emplacement stratégique pour l’infrastructure à haute capacité et indique qu’Ohio IX aide les fournisseurs de services, les réseaux de contenu et les entreprises à échanger du trafic Internet, à réduire les coûts, à améliorer les performances et à garder le trafic local plus proche des utilisateurs locaux. Il répertorie également Cologix Data Center parmi les points de présence du centre de l’Ohio. Le langage est promotionnel, mais le mécanisme est réel: l’échange local et la densité régionale d’opérateurs peuvent réduire la dépendance au backhaul et améliorer les options de routage.

La page Columbus actuelle de Cologix à l’adressehttps://cologix.com/data-centers/columbus/fait le même argument à l’échelle de la plateforme. Elle commercialise les centres de données de Columbus comme les installations les plus connectées de l’Ohio, indique que les clients peuvent utiliser un nœud AWS Direct Connect à Columbus, et répertorie plus de 45 fournisseurs de réseau, plus de 35 accès au cloud et un SLA de disponibilité de 99,999 %. Les chiffres exacts sont les revendications actuelles de Cologix, pas les revendications originales de DataCenter.BZ, mais ils montrent ce que la fondation acquise est devenue. L’ancienne couche de contrôle locale a été absorbée dans un produit d’interconnexion plus large.

COL3 approfondit la comparaison. La page COL3 de Cologix à l’adressehttps://cologix.com/data-centers/columbus/col3/décrit une installation certifiée Tier III, un centre de données de 160 000 pieds carrés et de plus de 18 MW directement lié à COL1 et COL2, avec plus de 45 réseaux uniques dans la salle de rencontre, plus de 16 entrées de fibre, une connectivité Columbus FiberNet, une disponibilité de fibre noire métropolitaine et des liaisons de fibre atteignant les 88 comtés de l’Ohio. COL4 à l’adressehttps://cologix.com/data-centers/columbus/col4/est décrit comme un centre de données Scalelogix de 256 000 pieds carrés avec jusqu’à 33 MW et plus de 50 réseaux uniques. COL5 à l’adressehttps://cologix.com/data-centers/columbus/col5/devrait être prêt pour le service au troisième trimestre 2026 avec 60 000 pieds carrés, 25 MW de puissance électrique, un accès direct à plus de 50 réseaux, des fournisseurs cloud, AWS Direct Connect, Google Cloud Platform et Ohio IX. COL7 à l’adressehttps://cologix.com/data-centers/columbus/col7/est positionné sur le campus de Johnstown avec une capacité de site de 36 MW et un accès direct par fibre à plus de 50 réseaux.

Ces installations ultérieures peuvent obscurcir l’histoire originale plus petite. DataCenter.BZ n’a pas commencé comme COL4 ou COL7. Son importance était qu’elle a donné à Cologix une base Columbus connectée. L’acquisition de 2014 n’a pas simplement ajouté de la superficie; elle a ajouté une position sur le marché dans une région où les entreprises voulaient des alternatives à Chicago et à New York, où la logique de reprise après sinistre favorisait la géographie intérieure, et où la fibre régionale pouvait soutenir des routes locales et nationales. C’est pourquoi le langage d’acquisition original se concentrait sur les salles de rencontre, OHIO-IX, la fibre noire, les clients et le terrain.

Le résultat est une lecture à deux niveaux de Columbus. Pour les hyperscalers et les grands acheteurs de cloud, Columbus rivalise maintenant en tant que marché de puissance et de terrain avec des campus de centres de données en croissance. Pour les petits acheteurs de services gérés et d’entreprise, Columbus rivalise toujours en tant que marché local d’interconnexion et de support. La valeur originale de DataCenter.BZ se situait dans le deuxième niveau. La plateforme actuelle de Cologix essaie de capturer les deux.

L’économie des racks favorise les acheteurs qui connaissent leur propre charge de travail

Le fournisseur de services gérés du scénario d’ouverture doit répondre à une question pratique: quelles charges de travail appartiennent à un rack local? La réponse n’est pas « tout ». Les applications Web banalisées, le calcul en rafale, les services distribués mondialement et les logiciels qui peuvent être reconstruits avec des services cloud gérés appartiennent souvent au cloud public. Mais les charges de travail avec une demande stable, une sortie coûteuse, un matériel spécialisé, des contrôles physiques sensibles à la conformité, une croissance de stockage prévisible ou des licences héritées peuvent être de bons candidats à la colocation.

L’offre historique de DataCenter.BZ correspondait à ce mélange. Elle décrivait la colocation à haute densité, les centres de données virtuels, le stockage, les serveurs, les systèmes de réseau, l’infrastructure à la demande, les cages privées, les baies personnalisées et le support de reprise après sinistre. L’entreprise vendait un pont entre l’infrastructure appartenant au client et l’infrastructure gérée par le fournisseur. Ce pont peut être attrayant pour les clients qui veulent un endroit connu pour le matériel mais ne veulent pas exploiter le bâtiment.

La comparaison des coûts est plus facile à voir dans les incréments de puissance et de réseau. Un seul serveur 1U à un prix local bas peut être moins cher qu’une instance cloud si la charge de travail est stable, la bande passante est prévisible et le client possède déjà le matériel. Un rack complet peut être moins cher qu’une migration cloud si les applications du client ne sont pas modernisées et que le besoin principal est la disponibilité en dehors du bureau. Mais la comparaison s’inverse lorsque le renouvellement de l’équipement, les pièces de rechange, les opérations de sécurité, l’architecture de sauvegarde, les licences et la main-d’œuvre sont inclus. La colocation est économique lorsque l’acheteur comprend le modèle opérationnel complet. Elle devient coûteuse lorsque l’acheteur la traite comme un simple espace bon marché.

La force de DataCenter.BZ était qu’elle pouvait vendre la certitude en tant que service. Un acheteur n’avait pas besoin de construire une salle de données, d’acheter des systèmes UPS redondants, de négocier avec plusieurs opérateurs ou de doter l’installation en personnel 24 heures sur 24. Il pouvait placer l’équipement dans une installation conçue à cet effet et utiliser des cross-connects, des interventions à distance et un support local. Plus l’acheteur valorisait un contrôle physique spécifique, plus le modèle devenait attrayant. Moins l’acheteur se souciait du contrôle physique, plus le cloud public était concurrentiel.

La composition des revenus explique également pourquoi la réputation du support local comptait. Une installation avec une puissance et une fibre équivalentes peut perdre des affaires si les clients ne font pas confiance aux interventions à distance, aux procédures d’accès, à la réponse aux tickets ou à la qualité de l’escalade. La couverture de l’acquisition de 2014 a souligné à plusieurs reprises le support local de haute qualité. Ce support n’était pas sentimental. C’était une couche monétisable. Lorsque le serveur d’un client est en panne à 2 heures du matin, la différence entre un ingénieur dans le bâtiment et une file d’attente de support à distance fait partie du produit.

Les signaux non officiels du marché soutiennent cette lecture sans prouver la qualité du service. Une discussion LowEndTalk de 2014 à l’adressehttps://lowendtalk.com/discussion/30169/need-stable-data-center-for-solocation-in-usmontre des acheteurs comparant les options de colocation aux États-Unis pour une configuration de réseau personnalisée, des sessions BGP, une connectivité Internet redondante et un personnel de centre de données réfléchi; un entité a suggéré Cologix à Columbus, et un autre a fait référence à Datacenter.BZ comme étant maintenant Cologix. Ce ne sont que des discussions de forum, pas des preuves clients vérifiées. Leur valeur est qu’elles montrent le vocabulaire d’achat du segment: routage personnalisé, redondance, support local et sélection pratique de l’installation.

La base de coûts était la puissance, le refroidissement, le personnel, la sécurité et le réinvestissement

Le modèle de revenus attrayant s’accompagne d’une base de coûts lourde. Les centres de données consomment du capital avant de produire une réputation. L’infrastructure électrique, les générateurs, les systèmes UPS, l’appareillage de commutation, l’usine de refroidissement, les systèmes de sécurité, la protection incendie, l’entretien des bâtiments, les assurances, les audits de conformité, la main-d’œuvre pour les interventions à distance et les opérations de réseau doivent tous être financés avant que le client ne voie une simple facture mensuelle.

Les documents publics de DataCenter.BZ mettaient l’accent sur 30 MW de puissance électrique, des alimentations de plusieurs sous-stations, une génération diesel de secours et un support sur site 24 heures sur 24. Les pages actuelles COL1 et COL2 de Cologix continuent de mettre l’accent sur 30 MW de puissance électrique disponibles sur place, des configurations redondantes, des alimentations électriques multiples, une capacité de carburant sur place, une surveillance 24 heures sur 24, un accès biométrique et des ingénieurs locaux. Ces caractéristiques sont précieuses parce qu’elles sont coûteuses. Un acheteur paie pour le droit de ne pas posséder cette complexité.

L’alimentation est maintenant le plus grand facteur de variation sur le marché de Columbus. L’annonce de 2024 de Cologix pour COL4 à l’adressehttps://cologix.com/news/cologix-first-colocation-provider-to-complete-ai-ready-data-center-columbus/indiquait que son portefeuille Columbus s’étendait alors sur quatre centres de données, 500 000 pieds carrés et 80 MW, tous connectés par un anneau de fibre diversifié. Elle décrivait également plus de 50 fournisseurs de services réseau et cloud uniques, AWS Direct Connect, Google Cloud Interconnect et Ohio IX. Son annonce d’acquisition de terrain de 2024 à l’adressehttps://cologix.com/news/cologix-expands-central-ohio-footprint-with-land-acquisition-for-new-ai-ready-800mw-data-center-campus/indiquait que Cologix avait acquis environ 154 acres à Johnstown pour un campus qui pourrait atteindre 800 MW sur 2,0 millions de pieds carrés à pleine construction.

Ces chiffres sont bien au-delà de l’ère DataCenter.BZ. Ils montrent comment la base de coûts de la colocation à Columbus a changé. Le marché initial était le contrôle régional à l’échelle de l’entreprise. Le nouveau marché est la capacité à haute densité dans un marché contraint en puissance et politiquement visible. Un petit acheteur se soucie toujours des racks, des interventions à distance et des cross-connects. Mais l’exploitant de l’installation est maintenant en concurrence pour la capacité électrique, les incitations fiscales, la main-d’œuvre de construction et les engagements électriques à long terme aux côtés de la demande hyperscale.

La mise à jour de février 2026 d’AEP Ohio à l’adressehttps://www.aepohio.com/company/news/view?releaseID=10753montre l’ampleur de cette pression. AEP a déclaré que les centres de données ou les développeurs avaient signé des contrats fermes pour 5 642 MW dans le cadre de son tarif pour centres de données, en plus de 12 219 MW de contrats de centres de données signés avant le tarif, pour un total de 17 861 MW de projets sous contrat prévus jusqu’en 2035. Elle a également déclaré que les demandes antérieures avaient dépassé 30 000 MW avant le filtrage tarifaire. Ces chiffres ne sont pas spécifiques à DataCenter.BZ, mais ils modifient l’environnement d’exploitation de Columbus. L’alimentation n’est plus simplement un coût d’intrant. C’est un actif limitant.

Le Bureau du conseil des consommateurs de l’Ohio ajoute le côté facture publique de la même histoire à l’adressehttps://www.occ.ohio.gov/factsheet/quick-facts-data-centers-ohio. Il indique que l’Ohio compte plus de 200 centres de données, la plupart dans le centre de l’Ohio; que la croissance des centres de données peut nécessiter des mises à niveau du transport et des sous-stations; et que le tarif pour centres de données d’AEP Ohio oblige les nouveaux grands centres de données à payer au moins 85 % de la capacité souscrite pendant une période pouvant aller jusqu’à 12 ans, même s’ils en utilisent moins. Pour un acheteur hérité de Scherers Court, cela ne signifie pas qu’un contrat de baie devient soudainement une négociation de service public hyperscale. Cela signifie que le prix de l’installation locale est influencé par un marché de l’électricité où la capacité inutilisée, l’engagement à long terme et la récupération des infrastructures sont désormais des questions politiques.

La mise à jour mensuelle de l’électricité de l’U.S. Energy Information Administration à l’adressehttps://www.eia.gov/electricity/monthly/update/end-use.phpajoute un contexte macro: les revenus moyens de la vente au détail d’électricité par kilowattheure augmentaient d’une année sur l’autre en 2026. Pour un exploitant de centre de données, même de petits changements dans le coût de l’électricité, les frais de capacité ou les obligations de demande minimale peuvent affecter matériellement la tarification et la marge. Pour un client, cela signifie que l’ancien marché de la colocation locale peut devenir moins prévisible lorsque les coûts du réseau et les règles de capacité changent.

La dépendance envers les fournisseurs se trouvait dans la salle de fibre et la cour de service public

La dépendance envers les fournisseurs de DataCenter.BZ n’était pas la même que la dépendance envers un fournisseur cloud d’une entreprise de logiciels. Elle dépendait des services publics, des fournisseurs de carburant, de la maintenance des générateurs et des UPS, des sous-traitants de refroidissement, des opérateurs, des fournisseurs de fibre, des vendeurs d’équipement, des auditeurs, des systèmes de sécurité et des techniciens qualifiés. La valeur publique de l’installation provenait de l’offre de choix d’opérateurs, mais le choix d’opérateurs lui-même nécessitait des relations commerciales et physiques. La salle de rencontre était un marché uniquement parce que les opérateurs et les réseaux avaient une raison d’y être.

Le point de présence de Hurricane Electric en 2012 montre comment une relation avec un fournisseur pouvait également devenir un atout commercial. Lorsqu’une dorsale mondiale place son équipement dans une installation, les clients existants obtiennent une autre option de route, et les clients extérieurs obtiennent une raison supplémentaire d’envisager l’installation. L’annonce à l’adressehttps://www.he.net/releases/2012-10-03.htmlindiquait que les clients de DataCenter.BZ pouvaient se connecter directement via un cross-connect, tandis que les entreprises non colocalisées pouvaient se connecter via des fournisseurs de transport disponibles dans l’installation. C’est le volant d’inertie de l’interconnexion en langage clair: plus d’opérateurs attirent plus de clients; plus de clients attirent plus d’opérateurs.

L’ère Cologix a amplifié ce volant d’inertie. Les pages actuelles de COL1, COL3, COL4, COL5 et COL7 mettent toutes l’accent sur les salles de rencontre, les entrées de fibre, le statut de neutralité vis-à-vis des opérateurs, les accès au cloud et Ohio IX. Mais la dépendance envers les fournisseurs demeure. Si une installation perd sa densité d’opérateurs, la qualité de ses interventions à distance, sa disponibilité électrique ou la confiance dans les services publics, sa valeur de couche de contrôle s’affaiblit. Un acheteur ne se place pas en colocation simplement parce que du béton existe. Il le fait parce que l’installation fournit un accès fiable aux réseaux, aux personnes et à l’alimentation.

La dépendance en amont est également visible dans les preuves de routage. AS40715 apparaît maintenant comme Cologix dans les outils BGP, avec Cologix comme pair/amont observé sur les pages BGP publiques. C’est attendu après une acquisition. Cela suggère que le réseau hérité n’est plus un centre stratégique indépendant de la même manière que l’ancienne marque DataCenter.BZ a pu se présenter. Pour les clients, cela peut être positif: une société mère plus grande peut apporter du capital, une portée réseau plus large, une connectivité cloud et une maturité opérationnelle. Cela peut également réduire l’ancienne sensation de fournisseur local si le service devient plus standardisé.

La leçon sur le risque fournisseur est que le contrôle local n’est pas l’indépendance vis-à-vis des grands systèmes. C’est un ensemble différent de dépendances. Au lieu de dépendre principalement d’une région hyperscale et de ses abstractions de service, le client dépend d’une installation locale, de la capacité du service public, d’opérateurs spécifiques, de la qualité des interventions à distance, de la fourniture de cross-connects et du cycle de réinvestissement du propriétaire. Le succès de DataCenter.BZ est venu du fait qu’elle a rendu cet ensemble attrayant pour les acheteurs du centre de l’Ohio.

Les clients ont acheté la proximité et la preuve

La liste des clients nommés de DataCenter.BZ n’est pas entièrement publique, mais les sources disponibles indiquent le profil du client. Les propres communiqués de l’entreprise faisaient référence aux opérateurs de télécommunications, aux entités gouvernementales, aux systèmes de santé et d’éducation, aux fournisseurs de services technologiques et aux entreprises du Fortune 1000. La page publique LinkedIn de l’entreprise à l’adressehttps://www.linkedin.com/company/datacenter.bzdécrit des solutions de centre de données et de télécommunications de qualité entreprise, la colocation à haute densité, les ressources de virtualisation et de cloud, la fibre noire métropolitaine, les centres de données virtuels et les réseaux de stockage, la reprise après sinistre et un site de secours sur place de 150 places. La page indique également que l’entreprise a été fondée en 2007 et comptait de 11 à 50 employés. Ces affirmations correspondent aux grandes lignes de l’étude de cas 7x24, qui répertoriait les entités gouvernementales, les établissements d’enseignement, les systèmes de santé et les entreprises du Fortune 1000 parmi les catégories de clients.

Ces affirmations sont auto-présentées, elles doivent donc être pesées en conséquence. Néanmoins, elles correspondent aux preuves d’acquisition. Une installation avec plus de 100 clients, des actifs de fibre noire, des salles de rencontre et des choix de réseaux régionaux servirait logiquement un mélange d’opérateurs, de fournisseurs de services gérés, d’institutions et d’entreprises du marché intermédiaire. Cela aurait également un sens pour les clients gouvernementaux, de santé et d’éducation qui avaient besoin de contrôle local, de support d’audit et de planification de la continuité.

Une trace de rapport financier public donne un exemple concret de la catégorie de service. Un rapport de l’auditeur de l’Ohio pour l’Electronic Classroom of Tomorrow, disponible à l’adressehttps://ohioauditor.gov/auditsearch/Reports/2013/Electronic_Classroom_of_Tomorrow_12-Franklin.pdf, inclut DataCenter.BZ dans les notes de location-exploitation pour l’espace d’équipement serveur et la propriété/équipement/sécurité de l’équipement serveur. Cela n’établit pas la qualité du service ou une relation actuelle. Cela montre que l’activité de DataCenter.BZ comprenait de véritables arrangements institutionnels de serveur-stockage, pas seulement des affirmations d’hébergement abstraites.

Pour les clients, la valeur pratique était la preuve. Un fournisseur local pouvait visiter l’installation, rencontrer le personnel, inspecter les cages, tester la réactivité des interventions à distance, cartographier les routes des opérateurs et négocier l’accès physique. Une région de cloud public n’offre pas ce type de preuve. Elle offre une preuve différente: échelle mondiale, étendue des services, certifications, API et opérations standardisées. De nombreux clients du marché intermédiaire ont besoin des deux. DataCenter.BZ était positionnée pour la partie qui nécessitait encore une installation.

La dépendance des clients allait dans les deux sens. DataCenter.BZ dépendait de clients qui paieraient pour la qualité plutôt que de courir après le prix d’hébergement le plus bas. Les clients dépendaient d’une installation qui pouvait rester capitalisée, maintenir les certifications, garder les opérateurs et préserver le support. Cet équilibre aide à expliquer pourquoi l’acquisition était rationnelle. Les clients ont gagné l’accès à la plateforme plus large de Cologix tout en conservant l’actif local. Cologix a gagné une base de clients fidèles et une base d’interconnexion à Columbus.

La concurrence a transformé un marché local en une compétition de plateforme

Le marché des centres de données de Columbus a radicalement changé depuis l’acquisition de DataCenter.BZ. Cologix n’est plus la seule histoire visible. L’expansion de Cologix elle-même a créé une plateforme interne plus grande. La page du centre de données de Columbus d’Expedient à l’adressehttps://expedient.com/data-centers/columbus/commercialise trois installations, 13,4 MW de charge informatique critique, 152 800 pieds carrés de taille totale et 59 600 pieds carrés de faux-plancher. La page Columbus de CenterSquare à l’adressehttps://www.csquare.com/data-centers/columbuscommercialise la colocation moderne, la disponibilité de l’alimentation, un langage de SLA de disponibilité à 100 % et des options de construction sur mesure. La page du centre de données de l’Ohio d’Iron Mountain à l’adressehttps://www.ironmountain.com/data-centers/locations/ohio-data-centercommercialise une installation de l’Ohio à Miamisburg desservant Cincinnati, Columbus et Dayton avec 44 000 pieds carrés et 1,4 MW de puissance. Google répertorie les communautés de centres de données du centre de l’Ohio à l’adressehttps://datacenters.google/locations/ohio, y compris New Albany, Lancaster et Columbus.

L’écart des références est le point. COL1/COL2 de Cologix vendent une histoire de campus dense en opérateurs à Scherers Court. Expedient vend une empreinte d’infrastructure gérée et de services cloud à Columbus avec des chiffres de taille et de charge informatique publiés. CenterSquare vend de la colocation et de la flexibilité de construction sur mesure. Iron Mountain vend une installation du sud-ouest de l’Ohio avec un langage de continuité d’entreprise. Google ne cherche pas à attirer les acheteurs de services gérés à un rack; il modifie le marché régional de l’électricité, de la main-d’œuvre, du terrain et des talents autour d’eux. L’ancienne niche de DataCenter.BZ était précieuse parce qu’elle se situait en dessous des achats hyperscale et au-dessus de l’hébergement de serveurs à bas prix. Cette niche ne survit que si la plateforme de Scherers Court peut conserver suffisamment d’intimité locale pendant que Cologix fait évoluer le marché.

Ces concurrents ne ciblent pas tous le même acheteur. Un hyperscaler construisant ses propres campus ne vend pas le même produit qu’un fournisseur de colocation 1U local. Mais ils façonnent le même marché régional du travail, de l’électricité, du terrain et la perception du centre de l’Ohio comme territoire d’infrastructure numérique. DataCenter.BZ a autrefois rivalisé en étant locale, neutre vis-à-vis des opérateurs et de haute qualité. Cologix rivalise maintenant en associant cette base locale à une plateforme nord-américaine et en étendant sa capacité.

La plateforme Cologix actuelle donne plus de valeur aux anciens actifs de DataCenter.BZ, mais elle rend également l’ancienne entreprise plus difficile à évaluer en tant qu’entité autonome. Un acheteur ne se demande plus: « Dois-je acheter auprès de DataCenter.BZ? » Il se demande: « La plateforme Columbus de Cologix, enracinée en partie dans l’ancienne empreinte de DataCenter.BZ, offre-t-elle une meilleure économie et un meilleur contrôle que les alternatives? » C’est une question commerciale différente.

Les signaux des concurrents modifient également la pression sur les prix. Les fournisseurs locaux à bas prix peuvent annoncer une tarification de rack simple. Les plateformes plus grandes peuvent mettre l’accent sur la densité du réseau, la conformité, les accès au cloud, le support et l’évolutivité de la puissance. Un client avec un serveur peut comparer avec la tarification de style CeraNet. Un client avec plusieurs baies, des besoins de conformité et des exigences d’interconnexion cloud peut comparer Cologix à Expedient, CenterSquare ou à une stratégie cloud directe. Un client avec des besoins à l’échelle du mégawatt est sur un marché complètement différent.

Le point idéal historique de DataCenter.BZ se situait entre l’hébergement à bas prix et les achats hyperscale. Ce milieu n’a pas disparu. Il est devenu plus contesté. Le gagnant est le fournisseur qui peut rendre la décision hybride facile: du matériel local là où cela a du sens, une connectivité cloud là où elle est utile, un support lorsque les choses se cassent et une tarification qui ne surprend pas le client après l’ajout de la puissance et de la bande passante.

Les signaux du marché indiquent une pertinence durable et une réelle incertitude

Les signaux du marché autour de DataCenter.BZ sont mitigés d’une manière qui est courante pour les entreprises d’infrastructure acquises. Les signaux positifs sont forts. Cologix a acheté l’entreprise. Cologix a publiquement attribué plus de 100 clients, de la fibre noire, du terrain, des bâtiments et un EBITDA annualisé à la transaction. PeeringDB contient toujours des enregistrements d’organisation et d’installation. Les pages actuelles de Cologix cartographient les emplacements de Scherers Court dans la plateforme Columbus. Ohio IX répertorie Cologix parmi les points de présence du centre de l’Ohio. Les enregistrements BGP montrent toujours l’ancien site Web et les traces de dénomination héritées de DataCenter.BZ.

Les signaux incertains sont également réels. Le domaine DataCenter.BZ est en stationnement. Le site public de la marque n’explique plus les services. Les enregistrements PeeringDB peuvent préserver des étiquettes héritées plutôt que la marque commerciale actuelle. Certaines pages d’index d’entreprises publiques suggèrent que la LLC originale de l’Ohio pourrait ne plus être active, bien que ces pages non officielles ne remplacent pas une vérification directe des registres de l’État. La page LinkedIn autonome de DataCenter.BZ reste visible, mais elle se lit comme un profil d’entreprise historique plutôt que comme un canal de vente actif.

Pour un jugement de recherche, l’incertitude ne détruit pas la thèse. Elle la clarifie. DataCenter.BZ n’est pas évaluée en tant qu’opérateur indépendant actuel avec un site Web frais et un mouvement de vente actif. Elle est évaluée en tant qu’entreprise du répertoire dont les preuves publiques la lient à un actif de colocation Columbus, une empreinte de réseau/d’interconnexion et une acquisition en 2014 qui a contribué à construire la plateforme Columbus de Cologix. La pertinence de l’entité est donc historico-opérationnelle plutôt que de détail autonome.

Le bavardage du marché est cohérent avec cela. Les références LowEndTalk de 2014 traitent Datacenter.BZ comme « maintenant Cologix » et placent Cologix Columbus dans l’ensemble des options de colocation américaines pour les acheteurs ayant besoin de BGP, de connectivité redondante et de support d’installation réfléchi. Un fil WebHostingTalk à l’adressehttps://www.webhostingtalk.com/showthread.php?t=1469793contient également une référence de mémoire de marché à Datacenter.bz faisant partie de Cologix pendant que les acheteurs débattaient des options de colocation dans le Midwest. Ce ne sont pas des preuves de la qualité de service actuelle. Elles sont utiles parce qu’elles montrent comment les acheteurs techniquement avertis se souvenaient de la transition: l’ancienne installation locale est devenue une partie d’un fournisseur de colocation plus grand tout en conservant sa pertinence pour Columbus.

Le plus grand risque de réputation n’est pas que DataCenter.BZ n’était pas importante. C’est que l’ancien nom peut induire les lecteurs en erreur s’il est traité comme une marque indépendante actuelle. Tout profil public doit distinguer l’entreprise héritée, les preuves d’installation acquise et la plateforme d’exploitation actuelle de Cologix. Cette distinction protège contre deux erreurs: surestimer l’indépendance actuelle de DataCenter.BZ et sous-estimer le rôle que ses actifs ont joué dans la colocation à Columbus.

La réglementation et la géopolitique fixent maintenant un prix différent pour la même installation

Le risque réglementaire et géopolitique autour d’une installation de colocation à Columbus était autrefois relativement local: zonage, fiabilité des services publics, carburant diesel, codes de prévention des incendies, audits de conformité, règles sur les données des clients et disponibilité des opérateurs. Ces risques comptent toujours. Mais la montée en puissance des grands campus d’IA et de cloud a entraîné le centre de l’Ohio dans une lutte plus large sur l’alimentation, les incitations fiscales, l’utilisation des terres et la répartition des coûts publics.

L’article 122.175 du Code révisé de l’Ohio à l’adressehttps://codes.ohio.gov/ohio-revised-code/section-122.175fournit la base légale de l’exonération fiscale pour l’équipement des centres de données informatiques de l’Ohio. Ce type de politique a contribué à rendre l’Ohio attrayant pour l’investissement dans les centres de données. Mais en 2026, la politique avait changé. Le site du gouverneur de l’Ohio à l’adressehttps://governor.ohio.gov/media/news-and-media/governor-dewine-announces-pause-of-data-center-tax-exemptiona annoncé une pause dans l’examen des nouvelles demandes d’exonération fiscale pour les centres de données pendant que les législateurs examinaient la croissance du secteur. Le reportage de Signal Cleveland à l’adressehttps://signalcleveland.org/ohio-approves-last-data-center-exemption-before-moratorium/indiquait que l’Ohio Tax Credit Authority avait approuvé des exonérations fiscales pour deux projets, dont Cologix, au moment de la pause.

Pour le segment de clientèle d’origine de DataCenter.BZ, cette lutte politique peut sembler lointaine. Un petit fournisseur de services gérés ne demande pas 800 MW. Mais l’effet indirect est significatif. Si les files d’attente d’interconnexion électrique se resserrent, si les frais de capacité augmentent, si le traitement fiscal change ou si les communautés locales résistent aux nouveaux projets, le coût et la disponibilité de la colocation peuvent changer pour tout le monde. Un client louant une baie ne négocie peut-être pas avec le service public, mais l’économie de l’alimentation de l’installation se répercute sur la tarification et les options d’expansion.

L’angle géopolitique est principalement domestique. Columbus se situe à l’intérieur d’une course à l’infrastructure américaine façonnée par les régions cloud, la gravité des données d’entreprise, les charges de travail d’IA, la politique fiscale, la planification du réseau et la concurrence régionale. Les plans du campus de Johnstown de Cologix et la présence d’Amazon, Google, Microsoft, Meta, Vantage, CyrusOne et d’autres dans le centre de l’Ohio, comme le note la couverture de Data Center Dynamics à l’adressehttps://www.datacenterdynamics.com/en/news/cologix-buys-land-in-ohio-for-800MW-campus/, montrent que la région est passée d’une histoire de marché secondaire à un champ de bataille d’infrastructure nationale. L’héritage de DataCenter.BZ fait partie de cet arc: un opérateur de colocation local a contribué à démontrer que Columbus pouvait soutenir une interconnexion dense avant que le marché ne monte en échelle.

Le risque opérationnel reste plus concret. Un client de colocation locale doit encore se demander si l’installation a suffisamment de marge de puissance, si les interventions à distance sont réactives, si la diversité de la fibre est réelle, si les accès au cloud sont tarifés de manière raisonnable, si les contrats des opérateurs sont flexibles, si les fenêtres de livraison d’équipement et d’accès correspondent aux besoins du client et si le support est suffisamment local pour la tolérance au risque du client. Ces questions sont l’endroit où l’ancienne proposition de valeur de DataCenter.BZ survit à l’intérieur de Cologix ou perd de sa pertinence au profit des alternatives.

Ce qui changerait le jugement

Le jugement actuel est que DataCenter.BZ a compté en tant que couche de contrôle de la colocation à Columbus dont la valeur a été validée par l’acquisition et étendue par Cologix. Plusieurs faits pourraient changer ce point de vue.

Premièrement, des registres d’entreprise vérifiés de l’État pourraient clarifier le statut juridique actuel de DataCenter.BZ, LLC et si l’entité d’origine reste active, fusionnée, dissoute ou autrement maintenue. Cela n’effacerait pas l’historique de l’installation, mais cela affinerait le langage sur le statut de l’entreprise. Deuxièmement, une confirmation de l’opérateur actuel pourrait expliquer pourquoi PeeringDB continue d’afficher des enregistrements DataCenter.BZ, LLC et comment ces enregistrements correspondent à la gestion des installations de Cologix. Troisièmement, des données actuelles sur les clients ou les services pourraient montrer si des services sont encore vendus sous le nom DataCenter.BZ, bien que le site Web en stationnement rende cela peu probable.

Quatrièmement, un historique plus détaillé de l’installation pourrait réconcilier les chiffres de superficie entre les anciens communiqués, la couverture de l’acquisition, les adresses PeeringDB et les pages actuelles COL1/COL2 de Cologix. Le dossier public comprend 32 000 pieds carrés de faux-plancher dans les documents d’acquisition, des descriptions de 44 000 pieds carrés sur les pages actuelles COL1/COL2, et des chiffres de campus ultérieurs plus grands pour COL3 et au-delà. La bonne réponse peut être que différentes sources comptent différemment le faux-plancher, la taille du bâtiment, le campus ou les phases de l’installation. Cinquièmement, des preuves de routage et de PeeringDB mises à jour pourraient montrer si AS40715 et les enregistrements d’installation associés restent significatifs sur le plan opérationnel ou sont principalement des étiquettes héritées.

Sixièmement, des preuves de tarification spécifiques à Cologix Columbus affineraient l’économie. Les comparateurs publics locaux et les paliers de sortie AWS aident à cadrer les alternatives de l’acheteur, mais la tarification personnalisée de la colocation d’entreprise dépend de la densité des baies, de l’engagement de puissance, des cross-connects, de la bande passante, de la connectivité cloud, du support, de la durée du contrat et des exigences de construction. Septièmement, des preuves clients clarifieraient si l’ancienne réputation de support de haute qualité a survécu à l’intérieur de la plateforme plus grande. Les sources de l’acquisition présentent ce support comme une force; les clients actuels détermineraient s’il reste un différenciateur.

Enfin, le régime d’alimentation et de fiscalité de l’Ohio pourrait modifier tout le calcul de Columbus. Si les règles du tarif des centres de données, les exonérations fiscales, la capacité des services publics ou l’opposition communautaire augmentent matériellement les coûts, la valeur des installations connectées existantes peut augmenter parce qu’elles ont déjà une position d’alimentation et de réseau. Alternativement, si ces coûts se répercutent de manière trop agressive, les petits acheteurs peuvent choisir le cloud public ou des installations secondaires à moindre coût. Le marché d’origine de DataCenter.BZ était le contrôle local à un prix rationnel. La durabilité de ce marché dépend maintenant de la capacité de Cologix à préserver l’économie du contrôle local tout en opérant sur un marché de plus en plus façonné par une demande à l’échelle du mégawatt.

Pour le fournisseur de services gérés du scénario d’ouverture, la réponse est donc conditionnelle plutôt que nostalgique. La colocation locale l’emporte sur une région hyperscale anonyme lorsque le client a besoin de contrôle physique, d’une économie stable prévisible, d’un choix d’opérateurs, d’interventions à distance et d’un endroit suffisamment proche pour comprendre. Une région hyperscale gagne lorsque l’étendue du service, l’élasticité et l’abstraction comptent plus que la proximité. La contribution de DataCenter.BZ à Columbus a été de prouver que l’option locale pouvait être plus qu’une salle de serveurs. Elle pouvait être une couche de contrôle. La tâche de Cologix a été de maintenir cette couche utile alors que Columbus devient un marché de centres de données beaucoup plus vaste et plus coûteux.