SoftLayer и экономика сохранения видимости сервера

Покупатель, который по-прежнему хочет знать, какой сервер принадлежит ему

Самый показательный клиент SoftLayer — это не разработчик, которому нужна дешёвая виртуальная машина для теста на выходные. Это покупатель, который уже столкнулся с противоположной проблемой: рабочая нагрузка перенесена в высокоабстрактное публичное облако, оплачивается множеством мелких счётчиков, защищена множеством общих средств контроля, а затем выясняется, что она слишком стабильна, слишком зарегулирована, слишком чувствительна к задержкам, слишком привязана к конкретной сети или слишком упряма в эксплуатации, чтобы там оставаться.

Такому покупателю по-прежнему нужны облачный заказ, почасовая или помесячная коммерческая гибкость, управление через API, а также доступ к хранилищу, резервному копированию, поддержке и приватному подключению. Но он также хочет знать, что сервер является однотенантным, что сетевой путь спроектирован, а не угадан, что публичный исходящий трафик не станет неограниченным сюрпризом и что изоляция основана на аппаратном контроле, а не только на логике арендаторов.

SoftLayer Technologies важна, потому что построила крупный бизнес вокруг такого покупателя ещё до того, как рынок публичных облаков научился описывать эту проблему как «гибридное облако». В 2013 году IBM приобрела SoftLayer не ради покупки небольшого хостингового бренда. Она купила операционную модель, в которой облако могло означать физические серверы в той же мере, что и виртуальные инстансы, приватные сети — в той же мере, что и доступ в публичный интернет, а контроль над инфраструктурой — в той же мере, что и скорость для разработчиков. В анонсе IBM говорилось, что SoftLayer даёт клиентам выбор между выделенными и общими серверами, физическими и виртуальными устройствами, публичными и приватными облачными схемами, полнофункциональным API, автоматизацией и глобальной сетью с низкой задержкой (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). В сообщении о закрытии сделки говорилось, что SoftLayer войдёт в новое подразделение облачных сервисов IBM и вместе с IBM SmartCloud станет частью глобальной платформы (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html).

Опорные цифры здесь необычно конкретны для давнего приобретения в сфере частных облаков. На момент анонса у SoftLayer, как сообщалось, было 13 дата-центров в США, Азии и Европе и 100 000 устройств под управлением (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). Продавец, GI Partners, сообщила, что компания управляла более чем 100 000 серверов, межсетевых экранов и балансировщиков нагрузки, обслуживала более 21 000 клиентов в более чем 140 странах и эксплуатировала 13 дата-центров по всему миру (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Газета Los Angeles Times сообщила о сумме сделки в 2 млрд долларов, отметив при этом, что IBM не раскрыла условия (https://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html). По состоянию на 2026 год публичные сетевые данные по-прежнему показывают крупную поверхность IBM Cloud под сетевой идентичностью SoftLayer: PeeringDB указывает AS36351 как «SoftLayer Technologies, Inc. (an IBM Company)», также известную как IBM Cloud, с 1 800 префиксами IPv4, 450 префиксами IPv6 и трафиком 1–5 Тбит/с (https://www.peeringdb.com/net/1613). Текущая страница цен IBM на выделенные серверы сообщает, что классическая инфраструктура предлагает более 11 миллионов комбинаций конфигураций и 20 Тбайт бесплатного трафика, а выделенные серверы VPC можно развернуть из предустановленных профилей за 10 минут или быстрее (https://www.ibm.com/products/bare-metal-servers/pricing).

Эти цифры объясняют, почему история SoftLayer — это не ностальгия. Они описывают ту часть облачной экономики, которая так и не стала полностью абстрактной. Некоторым рабочим нагрузкам на самом деле нужно не «облако» в маркетинговом смысле. Им нужен контролируемый сервер, предсказуемое поведение сети, достаточная приватная полоса, известный канал поддержки, план маршрутизации и коммерческая структура, которая не наказывает за стабильное использование. Стратегическая ценность SoftLayer заключалась в том, чтобы сделать эти старые требования достаточно современными, чтобы они вписались в IBM Cloud.

IBM купила бизнес по контролю, а не только мощности

В 2013 году облачный рынок уже двигался в сторону абстракции. Amazon Web Services сделала виртуальный инстанс умственной моделью по умолчанию. OpenStack пытался стандартизировать программное обеспечение частных облаков. Корпоративные покупатели начинали говорить о гибридных развёртываниях, но многие по-прежнему рассматривали публичное облако и выделенный хостинг как отдельные категории. Привлекательность SoftLayer была в том, что она размывала эту границу со стороны инфраструктуры.

IBM могла сказать корпоративному покупателю, что одна и та же платформа поддерживает публичное облако, размещаемое частное облако, выделенные серверы и виртуальные инстансы, не заставляя каждую рабочую нагрузку проходить через одни и те же допущения об общей виртуализации.

Это различие видно в формулировках IBM при приобретении. В релизе 2013 года говорилось, что SoftLayer позволяет клиентам приобретать облачные сервисы корпоративного класса на выделенных или общих серверах и что её архитектура охватывает физические и виртуальные устройства (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). В релизе о закрытии сделки говорилось, что SoftLayer позволит IBM сочетать безопасность, конфиденциальность и надёжность частного облака с экономичностью и скоростью публичного облака (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html). Формулировка звучит как маркетинг, но экономическое утверждение конкретно: IBM покупала платформу, где переход в облако не требовал отказа от контроля на уровне сервера.

Это имело значение, потому что естественная клиентская база IBM не была похожа на потребительский интернет-стартап. Банки, страховщики, медицинские организации, государственные подрядчики, поставщики ПО, аутсорсинговые контракты, поставщики управляемых услуг и промышленные предприятия часто заботятся об аудируемости, физической изоляции, маршрутизации, эскалации поддержки, переносимости лицензий, контроле операционной системы и предсказуемости производительности. Часть этих потребностей можно удовлетворить в современных проектах виртуальных частных облаков.

Другие легче продать, когда покупатель может указать на однотенантный физический сервер и срок контракта.

Покупка также дала IBM более убедительный ответ на коммерческую проблему. Традиционный корпоративный клиент может захотеть перенести за пределы собственной площадки только часть рабочей нагрузки, а не переписывать всё под облачно-нативные операции. Модель SoftLayer позволяла IBM продавать посадочную зону, которая ощущалась ближе к существующей среде клиента: выделенные машины, VLAN, шлюзовые устройства, балансировщики нагрузки, межсетевые экраны, дополнительные хранилища, продукты резервного копирования, тикеты поддержки и проектирование сети. Такой покупатель не обязательно враждебен публичному облаку.

Он не хочет терять операционные рычаги до того, как бизнес-обоснование будет доказано.

История с частным капиталом подтверждает этот вывод. GI Partners приобрела EV1 и The Planet в 2006 году, приобрела SoftLayer в 2010 году и объединила SoftLayer и The Planet перед продажей IBM (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Это была не чисто программная история. Это была консолидация выделенного хостинга, сетевых операций и сервисных возможностей дата-центров в автоматизированного инфраструктурного провайдера. Ценным активом были не только серверы. Это было ноу-хау, необходимое для превращения физической инфраструктуры в воспроизводимый коммерческий продукт.

Собственный текущий язык продуктов IBM по-прежнему сохраняет это различие. Документация по выделенным серверам определяет классический выделенный сервер как почасовой или помесячный, однотенантный, выделенный клиенту, не используемый совместно ни в какой части, предоставляемый без гипервизора и разворачиваемый в одном или нескольких дата-центрах (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). На странице начала работы говорится, что IBM Cloud Bare Metal Servers можно разворачивать и управлять ими как облачными сервисами с почасовой и помесячной оплатой на классической или VPC-инфраструктуре (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started). Иными словами, продукт сохранил главное обещание SoftLayer: облачный заказ по-прежнему может привести к получению физического сервера.

Идентичность SoftLayer теперь живёт в сети и в средствах управления продуктом

SoftLayer уже не стоит понимать как самостоятельную публичную операционную компанию. Обоснованное текущее прочтение таково: SoftLayer продолжает существовать как унаследованный бренд, набор платформенных API, публичная сетевая идентичность и линия проектирования внутри IBM Cloud. Это не слабый набор фактов. Для инфраструктуры сетевая идентичность и операционная непрерывность часто важнее, чем бренд, обращённый к потребителю.

Публичные регистрационные данные ARIN по-прежнему содержат старое название. Запись организации RDAP для SOFTL идентифицирует SoftLayer Technologies Inc. по адресу 4849 Alpha Road, Даллас, Техас; регистрация произошла в 2005 году, последнее изменение — в 2024 году (https://rdap.arin.net/registry/entity/SOFTL). Запись RDAP для AS36351 называет SOFTLAYER и указывает регистранта как IBM Cloud по адресу IBM в Армонке (https://rdap.arin.net/registry/autnum/36351). BGP.tools показывает AS36351 как IBM Cloud, зарегистрированный в декабре 2005 года, активный и выделенный в ARIN, с апстримами, включая Arelion, Lumen, NTT America, Bharti Airtel, Telstra, Hurricane Electric, Tata Communications и Telxius (https://bgp.tools/as/36351). PeeringDB даёт форму для пиринга: SoftLayer Technologies, Inc. (an IBM Company), также известная как IBM Cloud, AS-SOFTLAYER, североамериканский охват, избирательная политика пиринга, 1 800 префиксов IPv4, 450 префиксов IPv6 и трафик 1–5 Тбит/с (https://www.peeringdb.com/net/1613).

Между количеством префиксов в PeeringDB и количеством анонсируемых маршрутов в BGP.tools есть важное различие. PeeringDB — это самостоятельно поддерживаемый каталог межсоединений, полезный для понимания политики пиринга и контактов операторов. BGP.tools отражает наблюдаемую маршрутизацию и на просмотренной для этой статьи странице показывал 339 анонсируемых префиксов IPv4 и 72 анонсируемых префикса IPv6 (https://bgp.tools/as/36351). Эти два измерения не следует считать одинаковыми. Экономический вывод не в точном количестве маршрутов, а в том, что сетевая идентичность SoftLayer остаётся привязанной к крупной поверхности маршрутизации IBM Cloud, и в публичных данных маршрутизации видны множество клиентских и сервисных префиксов.

API SoftLayer — ещё один сигнал непрерывности. В документации IBM Cloud говорится, что интерфейс прикладного программирования SoftLayer — это интерфейс разработки, который даёт разработчикам и администраторам прямой доступ к бэкенду IBM Cloud; он обеспечивает работу многих функций консоли и позволяет автоматизировать задачи, используя SOAP, XML-RPC или REST (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). SoftLayer Development Network по-прежнему публикует примечания к релизам, ссылки на SDK и справочники по CLI под именем SoftLayer, а на её главной странице видны примечания к релизам API за 2026 год (https://sldn.softlayer.com/). Это не сентиментальность по отношению к бренду. Это зрелая управляющая плоскость, к которой по-прежнему могут обращаться клиенты, скрипты, инструменты и партнёрские интеграции.

Эта непрерывность несёт и ценность, и риск. Она даёт существующим клиентам стабильный способ управлять классической инфраструктурой, заказывать устройства, проверять ресурсы и автоматизировать операции. Но это также означает, что IBM вынуждена поддерживать унаследованное поведение, старые названия, зрелые ожидания клиентов и обратную совместимость. Чем ценнее старая поверхность управления для клиентов, тем осторожнее IBM должна её менять. Это одна из причин, почему бизнес по контролю над серверами не исчезает быстро, даже когда рыночный язык поворачивается в сторону VPC, контейнеров и ИИ-платформ.

Публичный след межсоединений также показывает, почему SoftLayer никогда не была просто «хостингом». В подробной записи PeeringDB перечислены публичные точки обмена трафиком, включая AMS-IX, DE-CIX Chicago, DE-CIX Dallas, DE-CIX Frankfurt, DE-CIX Madrid, Equinix Ashburn, Equinix Chicago, Equinix Dallas, Equinix Hong Kong, Equinix Madrid, Equinix Miami и другие, с ёмкостью от 10G и 20G до 100G и 200G на отдельных подключениях (https://www.peeringdb.com/net/1613). Представление записи PeeringDB через API при запросе с параметром depth=2 возвращает 73 публичных пиринговых подключения и 40 точек межсоединений для этой сети (https://www.peeringdb.com/api/net/1613?depth=2). Точный состав может меняться, но эти данные подтверждают операционную поверхность, построенную вокруг маршрутизации, межсоединений и управления трафиком, а не только вокруг площадей в дата-центре.

Выделенные серверы возвращают облачную экономику к математике утилизации

Экономический центр статьи прост: выделенный сервер — это облако, продаваемое с оставленным на виду риском запасов. Гипермасштабная виртуальная машина — это абстракция над пулом. Выделенный физический сервер — это конкретная машина, которую нужно купить, запитать, подключить кабелями, охладить, протестировать, мониторить, ремонтировать, обновлять, защищать, подключать и в конечном счёте заполнять выручкой. Историческая инновация SoftLayer состояла в том, чтобы сделать эту физическую машину заказываемой через облакоподобный интерфейс.

Экономическая задача IBM — сохранить этот интерфейс привлекательным, не позволяя лежащему в основе оборудованию превращаться в запасы с низкой утилизацией.

Текущие страницы продуктов IBM показывают, как это решается. Классические выделенные серверы позиционируются как настраиваемые, с более чем 11 миллионами комбинаций конфигураций и 20 Тбайт бесплатного трафика, и предназначены для крупных, стабильных и предсказуемых операций (https://www.ibm.com/products/bare-metal-servers/pricing). Серверы с быстрым предоставлением уже сконфигурированы и готовы к настройке через 30–40 минут после выделения (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Индивидуальные серверы зависят от сложности, количества и вариантов тестирования (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). В той же документации говорится, что предоставление выделенного сервера обычно занимает до 4 часов, а расширенное аппаратное тестирование добавляет ещё 2 часа; если тесты выявляют критические или неустранимые аппаратные ошибки, перед продолжением предоставления компоненты заменяются (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm).

Эти детали важны, потому что описывают кривую издержек. Предварительно сконфигурированный сервер может быть быстрее, потому что IBM уже стандартизировала его форму. Индивидуальный сервер медленнее, потому что клиент просит IBM собрать или выделить более специфичный физический актив. Аппаратное тестирование защищает надёжность, но откладывает начало выручки и потребляет труд. Однотенантная конструкция создаёт изоляцию, но не позволяет IBM использовать эту машину для другого арендатора, пока её держит клиент.

Для покупателя продукт может ощущаться облачным, но база издержек остаётся ближе к эксплуатации дата-центра, чем к чистому программному обеспечению.

Именно здесь заявление о 20 Тбайт бесплатного трафика стратегически важно. Для стабильных рабочих нагрузок определённость по трафику — часть продукта. Видеоплатформа, вендор аналитики, сервис резервного копирования, игровой бэкенд, репозиторий программного обеспечения, финансовый сервис данных или хост корпоративной интеграции часто может оценить базовый трафик лучше, чем волатильный стартап может оценить пиковые вычисления. Если покупатель может сопоставить ежемесячную стоимость сервера с известным включённым пулом трафика, план на выделенном сервере может выглядеть менее рискованным, чем счёт за публичное облако, состоящий из часов вычислений, операций ввода-вывода хранилища, NAT-шлюзов, межзонального трафика, интернет-исходящего трафика и счётчиков управляемых сервисов. Страница цен IBM прямо выделяет классические выделенные серверы как подходящие для крупных, стабильных и предсказуемых операций (https://www.ibm.com/products/bare-metal-servers/pricing).

Резервирования и условия контрактов показывают другую сторону сделки об утилизации. На странице цен IBM говорится, что резервирования выделенных серверов VPC могут снизить расходы до 35 процентов при сроке один год или до 60 процентов при сроке три года, а также что резервирования гарантируют ёмкость в выбранной зоне доступности и дата-центре на весь срок действия (https://www.ibm.com/products/bare-metal-servers/pricing). В документации по классическим контрактным срокам говорится, что контрактный срок один год сохраняет ёмкость выделенного сервера в выбранном дата-центре и POD на весь срок контракта, но клиент не может изменить конфигурацию после завершения заказа и не может расторгнуть контрактный срок (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers). Это не просто скидка. Это перенос риска утилизации. IBM даёт ценовое облегчение, потому что клиент даёт определённость спроса.

Та же логика применялась к SoftLayer в 2013 году. Платформа со 100 000 устройств под управлением и 21 000 клиентов могла быть ценной, потому что имела достаточно разнообразия и масштаба, чтобы сглаживать спрос по многим типам клиентов (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Более мелкая компания выделенного хостинга может застрять с неправильными серверами на неправильных рынках. Более крупная платформа может стандартизировать типовые сборки, повторно использовать компоненты, направлять спрос между площадками и добавлять более маржинальные услуги. Но даже в масштабе IBM физический сервер, который не арендован, — это простаивающий капитал. Поэтому бизнес вознаграждает точность прогнозов, дисциплину закупок, своевременность обновления оборудования, проектирование стандартных конфигураций, квалификацию продаж и удержание клиентов.

Это делает SoftLayer хорошим примером для изучения разницы между «ростом облака» и «маржой облака». В годовом отчёте IBM за 2025 год компания описывается как сосредоточенная на гибридном облаке и ИИ; общая выручка за 2025 год составила 67,535 млрд долларов, выручка от программного обеспечения — 29,962 млрд долларов, выручка Hybrid Cloud — 7,327 млрд долларов, а выручка от инфраструктуры — 15,718 млрд долларов (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). Но IBM не раскрывает строку выручки SoftLayer. Публичные данные не позволяют внешнему читателю рассчитать валовую маржу или утилизацию для классических выделенных серверов IBM Cloud. Лучший публичный метод — читать механику продукта: что IBM устанавливает в ценах, что резервирует, что включает, что измеряет и какие операционные обязательства оставляет видимыми.

Сетевой биллинг — скрытая причина, по которой SoftLayer по-прежнему имеет смысл

Для многих корпоративных рабочих нагрузок решающая переменная — не процессор, а предсказуемость сети. Выделенный сервер полезен только тогда, когда клиент может доверять тому, как трафик входит, выходит и перемещается приватно. Первоначальное предложение SoftLayer включало безопасную связь с низкой задержкой и глобальную сеть (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). Текущая документация IBM сохраняет эту сетевую логику в центре.

Каждый выделенный сервер IBM Cloud включает доступ к приватной сети, а публичный интерфейс — это выбор при предоставлении, а не автоматическое допущение (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). На странице параметров сети говорится, что доступ к приватной сети включён всегда, а клиент выбирает, будет ли у сервера также публичный доступ в интернет; серверу, предоставленному только с приватным доступом, нельзя позже добавить публичный интерфейс (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Там же перечислены варианты скорости порта: 100 Мбит/с, 1 Гбит/с, 10 Гбит/с и 25 Гбит/с, причём 25 Гбит/с доступны только для избранных вариантов серверов и избранных дата-центров (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

На той же странице операционный компромисс изложен явно. Автоматическое резервирование портов — настройка по умолчанию и рекомендуемая: два физических сетевых порта настраиваются с агрегированием LACP и на сети, и на операционной системе во время предоставления. Резервирование под управлением пользователя даёт два порта, но требует действий клиента. Отсутствие резервирования поддерживается только для специализированных нужд и должно выбираться лишь после консультации с IBM Sales или Support при определённых условиях (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Это классическая экономика SoftLayer. Продукт даёт клиентам выбор на уровне оборудования, но выбор сопряжён с эксплуатационными обязательствами.

Публичный исходящий трафик — ещё один ключевой счётчик. В документации IBM по параметрам сети говорится, что клиенты выбирают включённый объём исходящего публичного трафика на расчётный период; превышение оплачивается за гигабайт; входящий публичный трафик бесплатен (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). В документации по графикам трафика говорится, что исходящие публичные данные, переданные из дата-центров IBM Cloud по всему миру, учитываются как плата за исходящий трафик, а графики показывают использование публичной и приватной сети, связанное с устройством (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs). В документации по резервному копированию говорится, что для приватного сетевого трафика при передаче данных между устройствами одного аккаунта ограничение по трафику не применяется (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery).

Это создаёт продуктовую позицию, отличную от чистого публичного облака. IBM может сказать клиенту: держите трафик восток-запад приватным, где возможно, используйте включённые или безлимитные приватные пути внутри аккаунта, выбирайте правильный пакет публичного исходящего трафика и подключайте прямое соединение, когда нужно. Клиент по-прежнему платит за использование публичного интернета, но архитектура даёт ему рычаги для снижения неопределённости. Именно такой контроль нужен покупателю со стабильной нагрузкой.

Direct Link показывает, насколько далеко может идти этот контроль. В документации IBM по Direct Link on Classic говорится, что настройка включает базовую конфигурацию сети и протокол пограничной маршрутизации BGP, а инженеры IBM работают с клиентом над включением VRF (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). Там же сказано, что IBM выделяет сеть /31 или /30 для каждого подключения на инфраструктуре кросс-коннектных маршрутизаторов IBM Cloud и что BGP обязателен для управления маршрутизацией через Direct Link (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). В FAQ говорится, что использование трафика через Direct Link между клиентами и IBM Cloud бесплатно и не тарифицируется, а исходящий трафик из сервисов IBM Cloud в публичный интернет тарифицируется (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). Также отмечается, что Direct Link может предоставлять разнесённые подключения, но резервирование создаётся проектированием BGP у клиента, а не одним изначально избыточным сервисом (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs).

Для покупателя, которому важны изоляция для соответствия требованиям, предсказуемый сетевой биллинг и приватная связность, именно поэтому IBM сохранила бизнес по контролю над серверами. Сервер сам по себе — не актив. Актив — это возможность объединить выделенную машину, приватную адресацию, выбор VLAN, Direct Link, VRF, скорость порта, варианты резервирования и политику трафика в инфраструктурный контракт. SoftLayer дала IBM словарь для такой продажи.

Изоляция для соответствия требованиям — это операционная, а не только контрактная задача

Выделенные серверы привлекательны для чувствительных к риску покупателей, потому что дают более простую историю об изоляции. Однотенантный физический сервер не решает автоматически вопросы соответствия, безопасности или устойчивости. Клиенту по-прежнему нужно обновлять операционные системы, управлять учётными данными, шифровать данные, проектировать резервное копирование, контролировать входящий доступ, отслеживать журналы и доказывать процедуры. Но заявление об изоляции начинается с другой точки: сервер выделен, провайдер не навязывает гипервизор, и у клиента больше прямого контроля над решениями на уровне хоста.

Документация IBM здесь осторожна. В ней говорится, что выделенный сервер закреплён за клиентом и не используется совместно с другими клиентами, при этом клиент управляет сервером, а предоставляется он без гипервизора (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Также сказано, что некоторые рабочие нагрузки следует распределять по нескольким дата-центрам и POD, чтобы избежать единой доменной зоны отказа; простого запуска нескольких приложений недостаточно, если место развёртывания выбрано неверно (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Это серьёзное эксплуатационное предупреждение. Выделенный сервер даёт контроль, но контроль переносит на клиента больше ответственности за проектирование.

Сетевая изоляция работает аналогично. В руководстве IBM по объединению защищённых приватных сетей через сеть IBM описывается классическая инфраструктура и отмечается, что большинство рабочих нагрузок можно реализовать с помощью IBM Cloud VPC, но затем показано, как защищённые приватные сети в разных дата-центрах можно связать через приватную сеть IBM с помощью VRF или расширения VLAN, шлюзовых устройств, маршрутизации и правил межсетевого экрана (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Там отмечается, что нет ограничений на выбор двух дата-центров, кроме влияния задержки, а приватные подсети, идентификаторы VLAN, адреса шлюзов и правила межсетевого экрана должны быть записаны и настроены (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Это не язык полностью управляемой абстракции. Это язык инфраструктурной инженерии.

Именно здесь модель SoftLayer остаётся полезной для регулируемых и требовательных к контролю клиентов. Клиент может строить привычные схемы сегментации: публичные и приватные интерфейсы, межсетевые экраны, шлюзовые устройства, VLAN, приватные подсети, Direct Link, анонсирование удалённых сетей, BGP, резервное копирование, приватная передача данных и выделенные хосты. IBM получает возможность продавать облачные сервисы, не делая вид, что каждую корпоративную рабочую нагрузку нужно в первый же день переработать под один современный шаблон. Покупатель получает шаг миграции, который ощущается безопаснее полной переработки.

Компромисс в том, что ручная экспертиза не исчезает. В документации Direct Link говорится, что клиенты отвечают за управление анонсированием маршрутов в сеть IBM Cloud и из неё, а неспособность спланировать поведение пересылки BGP может привести к нежелательным результатам, таким как асимметричная маршрутизация или неверно предпочитаемые пути (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). Страница параметров сети предупреждает, что резервирование под управлением пользователя требует от клиента умения настраивать резервирование, а без этого во время планового обслуживания возникает отсутствие резервирования сетевой связи (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Покупатель не может купить выделенный сервер и предположить устойчивость. Он должен управлять тем контролем, который запросил.

Этот компромисс — суть рынка. Абстрактное облако выигрывает, когда клиенты хотят меньше низкоуровневых решений. Облако в стиле SoftLayer выигрывает, когда клиенты хотят вернуть себе решения, потому что этого требуют рабочая нагрузка, регулятор, лицензия, путь с задержками, профиль производительности или план миграции. Преимущество IBM в том, что она может продавать обе истории в рамках одних корпоративных отношений. Её риск в том, что клиенты накажут её, если какая-либо из историй станет неясной.

Давление замещения облаком никогда не исчезало

Давление на модель SoftLayer очевидно: большая часть нового потребления облака предпочитает абстракцию. Разработчикам нужны управляемые базы данных, бессерверные функции, контейнерные платформы, объектное хранилище, интеграция идентичности, наблюдаемость, ИИ-сервисы и региональные API. Финансовым командам нужны программы скидок и централизованное управление. Командам безопасности нужны стандартизированные средства контроля. Платформенным командам нужна инфраструктура, которую можно создавать и уничтожать без ожидания аппаратных тестов. Для таких покупателей физический сервер может выглядеть исключением.

Страница цен IBM отражает этот раскол. Выделенные серверы VPC представлены как предустановленные профили, разворачиваемые за 10 минут или быстрее в программно-определяемой сети и идеально подходящие для высокой доступности и максимальной эластичности (https://www.ibm.com/products/bare-metal-servers/pricing). Классические выделенные серверы представлены как широко настраиваемые, с более чем 11 миллионами комбинаций и 20 Тбайт бесплатного трафика, идеально подходящие для стабильных предсказуемых операций (https://www.ibm.com/products/bare-metal-servers/pricing). Это не противоречие. Так IBM сегментирует рынок: выделенные серверы VPC — для клиентов, которым нужны современные облачные конструкции вокруг выделенного оборудования, классические выделенные серверы — для клиентов, которым по-прежнему нужна старая поверхность управления.

Угроза замещения также исходит от прозрачности издержек. Провайдеры публичных облаков сделали ценообразование гранулярным, а гранулярное ценообразование может как помогать, так и мешать аргументам в пользу выделенных серверов. AWS объявила, что с 1 февраля 2024 года будет взимать 0,005 доллара за каждый публичный IPv4-адрес в час для всех публичных IPv4-адресов, подключённых или не подключённых, что делает год непрерывно выделенного публичного IPv4-адреса стоимостью 43,80 доллара до учёта других сервисных расходов (https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/). Такая строка расходов подталкивает покупателей разбираться в использовании адресов, проектировании NAT и публичной экспозиции. Она также упрощает сравнение с провайдерами выделенной инфраструктуры, у которых пакеты адресов и трафика включены, даже если сравнение никогда не бывает идеальным.

Страницы конкурентов показывают то же рыночное давление. OVHcloud позиционирует выделенные серверы вокруг выделенных ресурсов, защиты от DDoS, приватных сетей и предсказуемой инфраструктуры для рабочих нагрузок, которым нужен контроль (https://us.ovhcloud.com/bare-metal/). Hetzner перечисляет выделенные корневые серверы с агрессивными ежемесячными ценами, которые могут сделать ориентированное на предприятия предложение IBM дорогим для чувствительных к цене европейских покупателей (https://www.hetzner.com/dedicated-rootserver). TrustRadius, сайт отзывов и сравнений, а не первичный продавец, указывает IBM Cloud Bare Metal Servers от 0,51 доллара в час и от 241 доллара в месяц, отмечая почасовые или помесячные варианты и 500 Гбайт в месяц исходящего трафика в сводке цен (https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricing). Такие сторонние цены следует рассматривать как рыночный сигнал, а не контракт, но они показывают, как покупатели сравнивают IBM с более дешёвыми и простыми альтернативами.

Защита IBM не в том, чтобы быть самым дешёвым выделенным сервером. Она в том, чтобы связать выделенные серверы с архитектурой гибридного облака, корпоративной поддержкой, программным обеспечением IBM, стратегией Red Hat/OpenShift, прямым подключением, корпоративными клиентами, близкими к мейнфреймам, регулируемыми рабочими нагрузками, схемами SAP и VMware и глобальными закупками. На странице IBM для инвесторов говорится, что компания позиционируется вокруг гибридного облака и ИИ (https://www.ibm.com/investor). В годовом отчёте за 2025 год сообщается, что выручка Hybrid Cloud в составе программного обеспечения составила 7,327 млрд долларов, а годовая повторяющаяся выручка OpenShift достигла 1,9 млрд долларов на конец 2025 года (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). Роль SoftLayer внутри этой IBM не в том, чтобы вести повествование. Она в том, чтобы предложить вариант физической и классической инфраструктуры, когда продажа гибридного облака доходит до рабочей нагрузки, которой всё ещё нужен сам сервер.

Риск в том, что продукт, сохранённый ради контроля, станет продуктом, сохранённым по инерции. Если классическая инфраструктура остаётся ценной, потому что клиенты активно нуждаются в её функциях, IBM может получать выгоду из устойчивой ниши. Если она остаётся только потому, что миграции сложны, она становится унаследованным бременем. Разница видна в качестве использования: выбирают ли клиенты классические выделенные серверы ради предсказуемых операций, приватной полосы и физической изоляции или застревают на них потому, что старые приложения и скрипты дорого переносить?

Публичные данные не могут ответить на это с точностью, но они корректно ставят вопрос.

Операционная поверхность больше, чем сам сервер

Исходную конструкцию SoftLayer следует понимать как операционную поверхность: контроль сервера, контроль сети, подключение хранилища, идентичность, поддержка, автоматизация через API, биллинг и размещение в дата-центрах. Текущая документация IBM сохраняет эту широту. Выделенный сервер можно сочетать с блочным и файловым хранилищем от 20 до 12 000 Гбайт на момент предоставления, хотя дополнительное хранилище нужно подключать после предоставления сервера (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Среди дополнений к выделенному серверу — аппаратный межсетевой экран, мониторинг, резервное копирование, реагирование, дополнительные публичные IP-адреса и варианты IPv6-адресов (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). В параметрах сети есть варианты только с публичным доступом, только с приватным, приватные интерфейсы, включённые по умолчанию, выбор публичного исходящего трафика, выбор VLAN, выбор подсети и запросы дополнительных IP-адресов (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

Поверхность API важна, потому что меняет экономику труда. Если клиент может заказывать, проверять, перенастраивать и отменять инфраструктуру программно, физический сервер становится частью более крупной системы эксплуатации, а не разовым тикетом. В документации IBM по API виртуальных серверов говорится, что API SoftLayer обеспечивает работу многих функций консоли IBM Cloud и может автоматизировать все части среды IBM Cloud, доступные через API (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). SoftLayer Development Network предоставляет SDK для Python, Java, Go, Perl, PHP и Ruby, а также плагин классической инфраструктуры для IBM Cloud CLI (https://sldn.softlayer.com/). Это глубокая установленная база поведения инструментов.

Однако управляющая плоскость также фиксирует ожидания. Давно работающий корпоративный скрипт может предполагать определённые имена объектов, поведение методов, схемы аутентификации, коды площадок, соглашения по VLAN или поведение позиций биллинга. Примечание к релизу API в 2026 году об удалении устаревших сервисных методов — обычное событие обслуживания, но для старой платформы оно всё равно может иметь значение для клиентов (https://sldn.softlayer.com/). Эта проблема есть у каждого зрелого инфраструктурного бизнеса. Чем мощнее поверхность управления, тем больше она становится частью собственного операционного кода клиента.

Площадки и маршрутизация добавляют ещё один слой. Публичная страница PeeringDB показывает AS-SOFTLAYER и публичную политику пиринга, которая является избирательной, предпочитает несколько площадок, не требует соотношения трафика и не требует контракта (https://www.peeringdb.com/net/1613). Среди ёмкостей обмена, перечисленных на странице: 200G в DE-CIX Dallas, 200G в DE-CIX Frankfurt, 200G в DE-CIX Madrid, 100G в DE-CIX Chicago, 80G в Equinix Ashburn, 60G в Equinix Chicago, 60G в Equinix Miami и менее крупные подключения на многих других точках обмена (https://www.peeringdb.com/net/1613). Эти цифры не доказывают удовлетворённость клиентов или выручку. Они показывают маршрутный след, поддерживающий глобальную инфраструктурную платформу.

Этот след — и актив, и издержки. Порты обмена, кросс-коннекты, ёмкость маршрутизаторов, маршрутная политика, управление трафиком, обработка злоупотреблений, реагирование на DDoS, окна обслуживания, обязательства по колокации и сетевая инженерия не монетизируются сами по себе. Они важны, когда удерживают клиентов от ухода. Клиент со стабильной рабочей нагрузкой, требованиями BGP, приватной связностью и предсказуемым трафиком может быть липким, потому что переезд — это не просто миграция сервера. Это миграция сети и операций.

Поэтому экономика SoftLayer подходит IBM лучше, чем могла бы подойти чисто бюджетной хостинговой компании. IBM может привязать инфраструктуру сетевого контроля к более широкому корпоративному аккаунту. Она может продавать консалтинг по миграции и модернизации. Она может соединить выделенные серверы с Red Hat, VMware, SAP, интеграцией IBM Z, состоянием безопасности и управляемыми услугами. Тогда выделенный сервер — не вся история маржи. Это якорь, удерживающий конкретную рабочую нагрузку внутри границ аккаунта IBM.

Данные также показывают, чего нельзя узнать из открытых источников

Публичные данные сильны в части идентичности, сетевой поверхности, истории приобретений, механики продукта и ценовой позиции. Они слабы в части текущих финансов, специфичных для SoftLayer. IBM не раскрывает выручку SoftLayer, утилизацию классических выделенных серверов IBM Cloud, валовую маржу по дата-центрам, отток по классам рабочих нагрузок, стоимость поддержки на сервер, долю классических рабочих нагрузок, переведённых на выделенные серверы VPC, экономику запасов IPv4 или реальную присоединённую выручку от Direct Link, поддержки, хранилища, резервного копирования и дополнений безопасности.

Это означает, что любая оценка должна быть консервативной.

Самое важное отсутствующее число — утилизация по классам оборудования и площадкам. Платформа выделенных серверов может выглядеть здоровой, если заголовочная сеть велика, а страница продукта широка, но при этом нести карманы застрявшего оборудования. Старые поколения процессоров могут быть дешёвыми в продаже, но дорогими по энергоэффективности. Конфигурации с большим объёмом памяти или готовые к GPU могут давать лучшие цены, но требуют осторожных закупок. На одних рынках может быть сильный спрос на приватную связность и предсказуемую полосу, на других потребуется дисконтирование.

Публичные страницы показывают широту продукта, а не заполняемость.

Второе отсутствующее число — поток миграции. Страницы продуктов IBM теперь различают выделенные серверы VPC и классическую инфраструктуру. Рациональная стратегия IBM состояла бы в том, чтобы переводить клиентов на новые конструкции, где возможно, сохраняя классический контроль, где необходимо. Но без публичной метрики миграции внешние читатели не могут узнать, растут ли классические выделенные серверы, стабильны ли они, постепенно сокращаются или сохраняются в основном для старых аккаунтов. Материалы IBM для инвесторов подчёркивают гибридное облако, Red Hat и ИИ больше, чем классическую инфраструктуру (https://www.ibm.com/investor/services/annual-report). Это не значит, что классические выделенные серверы неважны. Это значит, что их важность операционно специфична, а не заголовочно-стратегическая.

Третье отсутствующее число — качество поддержки. Клиенты выделенных серверов оценивают провайдера, когда что-то физически ломается или меняется маршрут. Документация IBM предупреждает, что аппаратные сбои, программные ошибки, сетевые проблемы и обслуживание могут вызывать простои, а для доступности необходимо распределять приложения по нескольким дата-центрам и POD (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Это технически честно. Но клиенты всё равно переживают сбой через отклик поддержки. Публичные страницы продукта не могут сказать, достаточно ли быстра поддержка IBM в момент, когда выходит из строя диск, сбоит VLAN, неверен маршрут Direct Link или сервер с только приватным доступом был заказан ошибочно.

Четвёртое отсутствующее число — издержки злоупотреблений и репутации. Хостинговые сети привлекают легитимные корпоративные рабочие нагрузки, но публичное IP-пространство и выделенные серверы также привлекают спам, скрапинг, бот-активность, фишинговую инфраструктуру и перепродавцов с высоким риском. Записи PeeringDB и BGP доказывают масштаб, но не доказывают качество репутации. Здесь важны позиция IBM в сетевом контроле, процессы поддержки и управление адресами, потому что грязный диапазон адресов или повторяющиеся инциденты со злоупотреблениями могут сделать дешёвый сервер дорогим. Публичные данные не позволяют оценить это напрямую.

Эти неопределённости не следует считать дефектами статьи. Они и есть экономика. Публичная запись говорит нам, почему IBM могла бы сохранить бизнес по контролю над серверами. Она не говорит, приносит ли каждая стойка, каждое поколение процессоров и каждая когорта клиентов привлекательную доходность.

Что сегодня оценивал бы покупатель

Крупный покупатель, решающий, размещать ли стабильные рабочие нагрузки на выделенных серверах IBM Cloud, оценивал бы иной набор фактов, чем разработчик, выбирающий виртуальный инстанс. Он начал бы с идентичности и непрерывности: SoftLayer была приобретена IBM, текущий продукт — IBM Cloud Bare Metal Servers, API и классические средства управления остаются документированными, а сетевая идентичность по-прежнему появляется в данных ARIN, PeeringDB и BGP (https://rdap.arin.net/registry/entity/SOFTL,https://rdap.arin.net/registry/autnum/36351,https://www.peeringdb.com/net/1613иhttps://bgp.tools/as/36351). Затем он проверил бы обещания продукта: однотенантность, отсутствие гипервизора провайдера, почасовая или помесячная оплата, быстрое предоставление, 20 Тбайт бесплатного классического трафика, включение приватной сети, варианты скорости порта, варианты резервирования, Direct Link, BGP, VRF и приватное перемещение данных (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm,https://www.ibm.com/products/bare-metal-servers/pricing,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-optionsиhttps://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link).

Покупатель также проверил бы поведение при сбоях. Если рабочей нагрузке нужна непрерывная доступность, собственная документация IBM говорит, что необходимо рассмотреть несколько серверов приложений и размещение в разных дата-центрах и POD (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Если покупатель хочет более дешёвый одиночный сервер без избыточного канала, он должен принять, что плановое обслуживание может прерывать связь. Если покупатель хочет Direct Link, он должен понимать, что резервирование создаётся через проектирование BGP и разнесённые подключения, а не самим существованием одного сервиса (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). Если он хочет развёртывание только с приватным доступом, он должен решить это при предоставлении, потому что публичный интерфейс нельзя добавить позже к серверу, предоставленному только с приватным доступом (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

Кредитор или приобретатель задал бы более сложные вопросы, которые IBM не публикует: повторяющаяся выручка по когортам, утилизация по площадкам, возраст оборудования, стоимость электропитания дата-центра, объём тикетов поддержки, выручка от превышения публичного исходящего трафика, стоимость приватной сети, доля подключений Direct Link, подключение хранилища и резервного копирования, концентрация клиентов, доля продлений по контрактным срокам и количество аккаунтов, которые всё ещё зависят от старого поведения API SoftLayer. Он отделил бы здоровый спрос, обусловленный контролем, от унаследованного спроса, обусловленного инерцией.

Первый заслуживает инвестиций. Второй заслуживает планирования миграции и защиты маржи.

Регулятора интересовали бы заявления о контроле и ясность для клиентов. Выделенные серверы могут помочь с изоляцией, но только если клиенты понимают, какие обязательства остаются за ними. Документация IBM прямо говорит, что клиент управляет сервером, а резервное копирование клиентских устройств не выполняется IBM, пока клиент не инициирует плановое или разовое резервное копирование через соответствующие решения (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmиhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery). Чувствительный к соответствию покупатель должен читать это внимательно. Однотенантность — это не управляемое соответствие. Это физическая и операционная отправная точка.

Вывод оценки сбалансирован. SoftLayer даёт IBM заслуживающую доверия поверхность управления для рабочих нагрузок, которые плохо вписываются в абстрактное облако. Публичные данные подтверждают реальную сеть, реальную непрерывность API, реальную механику продукта и реальную значимость для гибридного облака. Но публичные данные не подтверждают простого утверждения, что SoftLayer как унаследованное имя сама по себе является двигателем роста. Её ценность встроена: контроль серверов внутри IBM Cloud, полезный, когда клиент хочет облако, не теряя машину.

Реестр доказательств для публичных утверждений

Данные о приобретении и историческом масштабе взяты из анонса IBM о приобретении, сообщения IBM о закрытии сделки, сообщения GI Partners о продаже и отчёта Los Angeles Times о заявленной сумме сделки в 2 млрд долларов:https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html,https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html,https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibmиhttps://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html.

Текущие данные о сети и идентичности взяты из ARIN RDAP, PeeringDB, представления API PeeringDB и BGP.tools:https://rdap.arin.net/registry/entity/SOFTL,https://rdap.arin.net/registry/autnum/36351,https://rdap.arin.net/registry/entity/IBMC-24,https://www.peeringdb.com/net/1613,https://www.peeringdb.com/api/net/1613?depth=2иhttps://bgp.tools/as/36351.

Данные о продукте и ценах на выделенные серверы взяты со страницы цен IBM на выделенные серверы и из документации IBM Cloud по выделенным серверам:https://www.ibm.com/products/bare-metal-servers/pricing,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs,https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recoveryиhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr.

Данные об API и управляющей плоскости взяты из справочников API IBM Cloud и SoftLayer Development Network:https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference,https://cloud.ibm.com/docs/virtual-router-appliance?topic=virtual-router-appliance-vra-apiиhttps://sldn.softlayer.com/.

Данные о приватной связности и VLAN взяты из документации IBM Cloud по Direct Link и VLAN:https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link,https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs,https://cloud.ibm.com/catalog/infrastructure/direct-link-cloud-exchangeиhttps://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures.

Стратегический и финансовый контекст IBM взят со страницы IBM для инвесторов и из годового отчёта за 2025 год:https://www.ibm.com/investor,https://www.ibm.com/investor/services/annual-reportиhttps://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf.

Данные о замещении и сравнении рынка взяты из цен AWS на публичные IPv4-адреса, страниц OVHcloud о выделенных серверах, Hetzner о выделенных корневых серверах, сводок цен TrustRadius на выделенные серверы IBM и обсуждения на Hacker News 2013 года как неформального сигнала рынка разработчиков:https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/,https://us.ovhcloud.com/bare-metal/,https://www.hetzner.com/dedicated-rootserver,https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricingиhttps://news.ycombinator.com/item?id=5819227.

Итог и контрольные точки

Устойчивый урок SoftLayer в том, что облако не отменило сервер. Оно изменило, как сервер покупается, подключается, автоматизируется и финансируется. IBM сохранила логику контроля серверов SoftLayer, потому что некоторым корпоративным рабочим нагрузкам по-прежнему нужны физическая изоляция, предсказуемая полоса, приватная маршрутизация, известное размещение и низкоуровневый операционный выбор. Тот факт, что IBM сейчас позиционирует себя в первую очередь вокруг гибридного облака и ИИ, не ослабляет этот аргумент. Он делает его точнее.

Гибридному облаку нужны места, где старая и новая инфраструктура могут встретиться, и конструкция SoftLayer даёт IBM одно из таких мест.

Позитивный сценарий в том, что IBM может продолжать монетизировать наследие SoftLayer как инфраструктурный вариант с высоким уровнем контроля: классические выделенные серверы для стабильных предсказуемых операций, выделенные серверы VPC для новых облачных схем, Direct Link для приватной связности, непрерывность API SoftLayer для существующей автоматизации и корпоративные отношения IBM для рабочих нагрузок, которые не может обслужить один лишь дешёвый хостинг.

Цифры, поддерживающие этот сценарий: 13 исходных дата-центров, 100 000 устройств, 21 000 клиентов, заявленная сумма приобретения 2 млрд долларов, 1 800 префиксов IPv4 в PeeringDB, 450 префиксов IPv6, трафик 1–5 Тбит/с в PeeringDB, более 11 миллионов классических комбинаций конфигураций, 20 Тбайт бесплатного трафика на классической инфраструктуре, развёртывание выделенных серверов VPC за 10 минут или быстрее и быстрое предоставление классических серверов за 30–40 минут.

Негативный сценарий в том, что контроль может стать бременем. Если классическая инфраструктура сохраняется главным образом потому, что старые рабочие нагрузки трудно переносить, IBM вынуждена защищать маржу, неся унаследованную поддержку, старое поведение API, обновление оборудования, репутацию адресов, сложность дата-центров и ожидания клиентов. Если более дешёвые провайдеры выделенных серверов давят на товарные аккаунты, а гиперскейлеры поглощают высокоуровневые рабочие нагрузки управляемыми сервисами, IBM должна продолжать доказывать, почему её слой контроля серверов заслуживает места внутри премиальных отношений гибридного облака.

Контрольные точки конкретны. Во-первых, следите, продолжает ли IBM улучшать и выделенные серверы VPC, и классические выделенные серверы, а не позволяет одному направлению тихо истощать другое. Во-вторых, следите, становятся ли Direct Link, VRF и средства управления приватной сетью проще для клиентов без потери прозрачности. В-третьих, следите за изменениями публичной маршрутизации и PeeringDB вокруг AS36351, потому что они показывают, остаётся ли сеть широкой и актуальной.

В-четвёртых, следите за ценами на IPv4 и адресной политикой в отрасли, потому что дефицит публичных адресов может усилить позиции провайдеров с дисциплинированным распределением и включённым трафиком. В-пятых, следите за годовыми отчётами IBM на предмет сдвигов в акцентах на инфраструктуру, гибридное облако и Red Hat, потому что ценность SoftLayer всё больше зависит от того, насколько хорошо IBM упаковывает физический контроль вместе с программной стратегией.

SoftLayer — не лицо современной IBM. В этом и суть. Это та часть IBM Cloud, которая по-прежнему отвечает упрямому покупателю с упрямой потребностью: дайте мне удобство облака, но не заставляйте сервер исчезать.