SoftLayer e a economia de manter o servidor visível

O comprador que ainda quer saber qual máquina é sua

O cliente mais revelador da SoftLayer não é o desenvolvedor que quer uma máquina virtual barata para um teste de fim de semana. É o comprador que já viveu o problema oposto: uma carga de trabalho movida para uma nuvem pública altamente abstrata, faturada por muitos medidores minúsculos, protegida por muitos controles compartilhados e então descoberta como sendo muito estável, muito regulada, muito sensível à latência, muito específica de rede ou operacionalmente teimosa para ser feliz ali.

Esse comprador ainda quer pedidos em nuvem, flexibilidade comercial horária ou mensal, controle de API e acesso a armazenamento, backup, suporte e conectividade privada. Mas também quer saber que o servidor é de único locatário, que o caminho de rede é projetado em vez de adivinhado, que a saída pública não é uma surpresa sem limites e que o isolamento é baseado em controle de hardware e não apenas em lógica de locatário.

A SoftLayer Technologies é importante porque construiu um grande negócio em torno desse comprador antes que o mercado de nuvem pública aprendesse a descrever o problema como "nuvem híbrida". A IBM não adquiriu a SoftLayer em 2013 para comprar uma pequena marca de hospedagem. Comprou um modelo operacional no qual a nuvem poderia significar servidores físicos tanto quanto instâncias virtuais, rede privada tanto quanto alcance pela internet pública e controle de infraestrutura tanto quanto velocidade para desenvolvedores. O anúncio da IBM disse que a SoftLayer dava aos clientes uma escolha entre servidores dedicados e compartilhados, dispositivos físicos e virtuais, padrões de nuvem pública e privada, uma API completa, automação e uma rede global de baixa latência (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). O anúncio de fechamento disse que a SoftLayer se juntaria a uma nova divisão de serviços em nuvem da IBM, combinando-se com a IBM SmartCloud em uma plataforma global (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html).

A espinha dorsal de números concretos é incomumente concreta para uma antiga aquisição de nuvem privada. No anúncio, a SoftLayer foi descrita como operando 13 data centers nos Estados Unidos, Ásia e Europa, com 100.000 dispositivos sob gerenciamento (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). A GI Partners, o vendedor, disse que a empresa geria mais de 100.000 servidores, firewalls e balanceadores de carga, atendia mais de 21.000 clientes em mais de 140 países e operava 13 data centers globalmente (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). O Los Angeles Times reportou o valor do negócio em 2 bilhões de dólares, observando que a IBM não divulgou os termos (https://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html). Em 2026, as evidências públicas de rede ainda mostram uma grande superfície da IBM Cloud sob a identidade de rede da SoftLayer: o PeeringDB lista AS36351 como "SoftLayer Technologies, Inc. (an IBM Company)", também conhecido como IBM Cloud, com 1.800 prefixos IPv4, 450 prefixos IPv6 e tráfego de 1 a 5 Tbps (https://www.peeringdb.com/net/1613). A página atual de preços de bare metal da IBM diz que a infraestrutura clássica oferece mais de 11 milhões de combinações de configuração e 20 TB de largura de banda sem custo, enquanto o bare metal VPC pode implantar perfis predefinidos em 10 minutos ou menos (https://www.ibm.com/products/bare-metal-servers/pricing).

Esses números explicam por que a história da SoftLayer não é nostalgia. Eles descrevem a parte da economia da nuvem que nunca se tornou totalmente abstrata. Algumas cargas de trabalho não estão realmente pedindo "uma nuvem" no sentido de marketing. Elas estão pedindo um servidor controlado, comportamento de rede previsível, largura de banda privada suficiente, um canal de suporte conhecido, um plano de roteamento e uma estrutura comercial que não puna o uso constante. O valor estratégico da SoftLayer foi tornar esses requisitos antigos modernos o suficiente para caber dentro da IBM Cloud.

A IBM comprou um negócio de controle, não apenas capacidade

O mercado de nuvem em 2013 já estava se movendo em direção à abstração. A Amazon Web Services tinha tornado a instância virtual o modelo mental padrão. O OpenStack estava tentando padronizar o software de nuvem privada. Os compradores corporativos começavam a falar sobre implantações híbridas, mas muitos ainda tratavam a nuvem pública e a hospedagem dedicada como categorias separadas. O apelo da SoftLayer era que ela borrava a linha do lado da infraestrutura.

A IBM podia dizer a um comprador corporativo que a mesma plataforma suportava nuvem pública, nuvem privada hospedada, servidores bare metal e instâncias virtuais, sem forçar cada carga de trabalho pelas mesmas suposições de virtualização compartilhada.

Essa distinção é visível na linguagem de aquisição da IBM. O comunicado de 2013 disse que a SoftLayer permitia que os clientes comprassem serviços de nuvem de nível empresarial em servidores dedicados ou compartilhados, e que sua arquitetura abrangia dispositivos físicos e virtuais (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). O comunicado de fechamento disse que a SoftLayer permitiria que a IBM combinasse segurança, privacidade e confiabilidade da nuvem privada com economia e velocidade da nuvem pública (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html). A redação parece marketing, mas a alegação econômica é específica: a IBM estava comprando uma plataforma onde a adoção da nuvem não exigia abrir mão do controle em nível de servidor.

Isso importava porque a base natural de clientes da IBM não se parecia com uma startup de internet de consumo. Bancos, seguradoras, organizações de saúde, contratantes governamentais, fornecedores de software, contas de terceirização, provedores de serviços gerenciados e empresas industriais frequentemente se importam com auditabilidade, isolamento físico, roteamento, escalonamento de suporte, portabilidade de licenças, controle do sistema operacional e previsibilidade de desempenho. Algumas dessas necessidades podem ser atendidas em designs modernos de nuvem privada virtual.

Algumas são mais fáceis de vender quando o comprador pode apontar para um servidor físico de único locatário e um prazo contratual.

A aquisição também deu à IBM uma resposta mais credível para um problema comercial. Uma conta empresarial tradicional pode querer mover apenas parte de uma carga de trabalho para fora das instalações, não reescrever tudo para operações nativas da nuvem. O modelo da SoftLayer permitia que a IBM vendesse uma zona de aterrissagem que parecia mais próxima do ambiente existente do cliente: máquinas dedicadas, VLANs, appliances de gateway, balanceadores de carga, firewalls, complementos de armazenamento, produtos de backup, tickets de suporte e engenharia de rede. Esse tipo de comprador não é necessariamente hostil à nuvem pública.

É hostil a perder alavancagem operacional antes que o caso de negócio seja comprovado.

O histórico de private equity reforça o ponto. A GI Partners adquiriu a EV1 e a The Planet em 2006, adquiriu a SoftLayer em 2010 e fundiu a SoftLayer e a The Planet antes de vender para a IBM (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Esta não foi uma história de puro software. Foi uma consolidação de hospedagem dedicada, operações de rede e capacidades de serviço de data center em um provedor de infraestrutura automatizado. O ativo valioso não eram apenas servidores. Era o know-how necessário para transformar infraestrutura física em um produto comercial repetível.

A própria linguagem atual de produto da IBM ainda mantém essa distinção viva. Sua documentação de bare metal define o servidor bare metal clássico como horário ou mensal, de único locatário, dedicado ao cliente, não compartilhado em nenhuma parte, provisionado sem hipervisor e implantado em um ou mais data centers (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). A página de introdução diz que os IBM Cloud Bare Metal Servers podem ser implantados e gerenciados como serviços em nuvem com faturamento horário e mensal em infraestrutura clássica ou VPC (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started). Em outras palavras, o produto manteve a promessa central da SoftLayer: um pedido de nuvem ainda pode resultar em um servidor físico.

A identidade SoftLayer agora vive na rede e nos controles do produto

A SoftLayer não é mais bem compreendida como uma empresa operacional pública independente. A leitura atual defensável é que a SoftLayer sobrevive como uma marca legada, um conjunto de APIs de plataforma, uma identidade de rede pública e uma linhagem de design dentro da IBM Cloud. Isso não é um padrão de fatos fraco. Para infraestrutura, identidade de rede e continuidade operacional frequentemente importam mais do que a marca voltada ao consumidor.

O registro público da ARIN ainda carrega o nome mais antigo. O registro da organização RDAP para SOFTL identifica a SoftLayer Technologies Inc. na 4849 Alpha Road em Dallas, Texas, com um evento de registro em 2005 e um evento de última alteração em 2024 (https://rdap.arin.net/registry/entidade/SOFTL). O registro RDAP para AS36351 nomeia SOFTLAYER e lista o registrante como IBM Cloud no endereço da IBM em Armonk (https://rdap.arin.net/registry/autnum/36351). O BGP.tools apresenta AS36351 como IBM Cloud, registrado em dezembro de 2005, ativo e alocado sob a ARIN, com upstreams incluindo Arelion, Lumen, NTT America, Bharti Airtel, Telstra, Hurricane Electric, Tata Communications e Telxius (https://bgp.tools/as/36351). O PeeringDB fornece a forma voltada para peering: SoftLayer Technologies, Inc. (an IBM Company), também conhecido como IBM Cloud, AS-SOFTLAYER, escopo norte-americano, política de peering seletiva, 1.800 prefixos IPv4, 450 prefixos IPv6 e tráfego de 1 a 5 Tbps (https://www.peeringdb.com/net/1613).

Há uma distinção importante entre as contagens de prefixos do PeeringDB e as contagens de rotas originadas do BGP.tools. O PeeringDB é um diretório de interconexão automantido, útil para contexto de política de peering e contato do operador. O BGP.tools reflete o roteamento observado e mostrou 339 prefixos IPv4 originados e 72 prefixos IPv6 originados na página revisada para este artigo (https://bgp.tools/as/36351). As duas medições não devem ser tratadas como idênticas. O ponto econômico não é a contagem exata de rotas. É que a identidade de rede SoftLayer permanece anexada a uma grande superfície de roteamento da IBM Cloud, com muitos prefixos de clientes e serviços visíveis nos dados públicos de roteamento.

A API da SoftLayer é outro sinal de continuidade. A documentação da IBM Cloud diz que a SoftLayer Application Programming Interface é a interface de desenvolvimento que dá a desenvolvedores e administradores interação direta com o backend da IBM Cloud; ela alimenta muitos recursos do console e pode automatizar tarefas, usando SOAP, XML-RPC ou REST (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). A SoftLayer Development Network ainda publica notas de versão, links de SDK e referências de CLI sob o nome SoftLayer, com notas de versão da API de 2026 visíveis em sua página inicial (https://sldn.softlayer.com/). Isso não é sentimento de marca. Mostra um plano de controle maduro que clientes, scripts, ferramentas e integrações de parceiros ainda podem tocar.

Essa continuidade tem valor e risco. Dá aos clientes existentes uma maneira estável de gerenciar infraestrutura clássica, solicitar dispositivos, inspecionar recursos e automatizar operações. Também significa que a IBM deve carregar comportamento legado, nomes antigos, expectativas maduras de clientes e compatibilidade retroativa. Quanto mais valiosa a antiga superfície de controle é para os clientes, mais cuidadosamente a IBM precisa alterá-la. Essa é uma razão pela qual os negócios de controle de servidor não desaparecem rapidamente mesmo quando a linguagem do mercado se volta para VPCs, contêineres e plataformas de IA.

A pegada pública de interconexão também mostra por que a SoftLayer nunca foi meramente "hospedagem". O registro detalhado do PeeringDB mostra pontos de troca públicos incluindo 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 e outros, com capacidades variando de 10G e 20G a 100G e 200G em conexões selecionadas (https://www.peeringdb.com/net/1613). A visualização da API do registro PeeringDB retorna 73 conexões de troca pública e 40 instalações de interconexão para a rede quando solicitada com profundidade (https://www.peeringdb.com/api/net/1613?depth=2). A combinação exata pode mudar, mas a evidência confirma uma superfície operacional construída em torno de roteamento, interconexão e gerenciamento de tráfego, não apenas espaço físico de data center.

Bare metal transforma a economia da nuvem de volta em matemática de utilização

O centro econômico do artigo é simples: bare metal é nuvem vendida com risco de inventário deixado visível. Uma máquina virtual hiperescala é uma abstração sobre um pool. Um servidor físico dedicado é uma máquina específica que deve ser comprada, alimentada, cabeadas, resfriada, testada, monitorada, reparada, atualizada, protegida, conectada e, finalmente, preenchida com receita. A inovação histórica da SoftLayer foi tornar essa máquina física pedível através de uma interface semelhante à nuvem. O desafio econômico da IBM é manter essa interface atraente sem deixar o hardware subjacente se tornar inventário de baixa utilização.

As páginas atuais de produto da IBM mostram como isso é gerenciado. O bare metal clássico é apresentado como personalizável, com mais de 11 milhões de combinações de configuração e 20 TB de largura de banda sem custo, voltado para operações grandes, estáveis e previsíveis (https://www.ibm.com/products/bare-metal-servers/pricing). Servidores de provisionamento rápido são pré-configurados e prontos para configurar 30-40 minutos após o provisionamento (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Servidores personalizados dependem da complexidade, quantidade e opções de teste (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). A mesma documentação diz que o provisionamento de bare metal geralmente leva até 4 horas, e que testes estendidos de hardware levam 2 horas extras; testes que encontram erros críticos ou irrecuperáveis de hardware levam à substituição do componente antes que o provisionamento continue (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm).

Esses detalhes importam porque descrevem a curva de custo. Um servidor pré-configurado pode ser mais rápido porque a IBM já padronizou a forma. Um servidor personalizado é mais lento porque o cliente está pedindo à IBM para montar ou alocar um ativo físico mais específico. O teste de hardware protege a confiabilidade, mas atrasa o início da receita e consome mão de obra. Um design de único locatário cria isolamento, mas impede a IBM de usar essa máquina para outro locatário enquanto o cliente a mantém.

O produto pode parecer semelhante à nuvem para o comprador, mas a base de custo permanece mais próxima das operações de data center do que do software puro.

É aqui que a alegação de 20 TB de largura de banda sem custo é estrategicamente importante. Para cargas de trabalho estáveis, a certeza de largura de banda faz parte do produto. Uma plataforma de vídeo, fornecedor de análise, serviço de backup, backend de jogo, repositório de software, serviço de dados financeiros ou host de integração empresarial pode frequentemente estimar seu tráfego base melhor do que uma startup volátil pode estimar o pico de computação. Se o comprador pode mapear um custo mensal de servidor para um pool de largura de banda incluído conhecido, um plano de servidor dedicado pode parecer menos arriscado do que uma conta de nuvem pública composta por horas de computação, E/S de armazenamento, gateways NAT, tráfego entre zonas, saída da internet e medidores de serviços gerenciados. A página de preços da IBM distingue explicitamente o bare metal clássico como bom para operações grandes, estáveis e previsíveis (https://www.ibm.com/products/bare-metal-servers/pricing).

Reservas e termos contratuais mostram o outro lado da troca de utilização. A página de preços da IBM diz que as reservas de bare metal VPC podem reduzir a despesa em até 35% com um prazo de um ano ou até 60% com um prazo de três anos, e que as reservas garantem capacidade na zona de disponibilidade e data center selecionados durante toda a vigência do prazo (https://www.ibm.com/products/bare-metal-servers/pricing). A documentação de contrato clássico diz que um prazo contratual de um ano mantém a capacidade de bare metal no data center e POD selecionados durante toda a vigência do contrato, mas o cliente não pode alterar a configuração após a conclusão do pedido e não pode cancelar o prazo contratual (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers). Isso não é apenas desconto. É uma transferência de risco de utilização. A IBM dá alívio de preço porque o cliente dá certeza de demanda.

A mesma lógica se aplicava à SoftLayer em 2013. Uma plataforma com 100.000 dispositivos sob gerenciamento e 21.000 clientes poderia ser valiosa porque tinha variedade e escala suficientes para suavizar a demanda entre muitos tipos de clientes (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Uma empresa menor de hospedagem dedicada pode ficar presa com os servidores errados nos mercados errados. Uma plataforma maior pode padronizar construções comuns, reutilizar peças, direcionar a demanda entre locais e anexar serviços de margem mais alta. Mas mesmo na escala da IBM, um servidor físico que não é alugado é capital ocioso. O negócio, portanto, recompensa a precisão da previsão, a disciplina de aquisição, o tempo de atualização de hardware, o design de configuração padrão, a qualificação de vendas e a retenção.

Isso torna a SoftLayer um bom estudo de caso na diferença entre "crescimento da nuvem" e "margem da nuvem". O relatório anual de 2025 da IBM descreve uma empresa agora centrada em nuvem híbrida e IA, com receita total de US$ 67,535 bilhões, receita de software de US$ 29,962 bilhões, receita de Hybrid Cloud de US$ 7,327 bilhões e receita de infraestrutura de US$ 15,718 bilhões (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). Mas a IBM não divulga uma linha de receita da SoftLayer. A evidência pública não permite que um leitor externo calcule a margem bruta ou a utilização do bare metal clássico da IBM Cloud. O melhor método público é ler a mecânica do produto: o que a IBM precifica, o que reserva, o que inclui, o que mede e quais compromissos operacionais mantém visíveis.

A faturação de rede é a razão oculta pela qual a SoftLayer ainda faz sentido

Para muitas cargas de trabalho empresariais, a variável decisiva não é a CPU. É a previsibilidade da rede. Um servidor bare metal é útil apenas se o cliente puder confiar em como o tráfego entra, sai e se move privadamente. A proposta original da SoftLayer incluía comunicação segura de baixa latência e uma rede global (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). A documentação atual da IBM mantém essa lógica de rede central.

Cada servidor bare metal da IBM Cloud inclui acesso à rede privada, e uma interface pública é uma escolha de provisionamento, não uma suposição automática (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). A página de opções de rede diz que o acesso à rede privada está sempre incluído, enquanto o cliente escolhe se o servidor também tem acesso à internet pública; um servidor provisionado apenas privado não pode ter uma interface pública adicionada posteriormente (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Ela também lista opções de velocidade de porta de 100 Mbps, 1 Gbps, 10 Gbps e 25 Gbps, com 25 Gbps limitada a opções de servidor selecionadas e data centers selecionados (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

A mesma página torna explícita a troca operacional. A redundância automática de porta é a configuração padrão e recomendada, fornecendo duas portas de rede físicas configuradas com LACP bonding tanto na rede quanto no sistema operacional durante o provisionamento; a redundância gerenciada pelo usuário fornece duas portas, mas requer ação do cliente; nenhuma redundância é mantida apenas para necessidades especializadas e deve ser selecionada apenas em consulta com as Vendas ou Suporte da IBM sob condições específicas (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Essa é a economia clássica da SoftLayer. O produto dá aos clientes escolhas em nível de hardware, mas as escolhas vêm com obrigações operacionais.

A saída pública é outro medidor chave. A documentação de opções de rede da IBM diz que os clientes escolhem o tráfego público de saída incluído por período de faturamento; o excesso é cobrado por GB; o tráfego público de entrada é gratuito (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). A documentação do gráfico de largura de banda diz que os dados públicos de saída transferidos dos data centers da IBM Cloud em todo o mundo são avaliados como encargos de largura de banda de saída, enquanto os gráficos de largura de banda mostram o uso da rede pública e privada associado a um dispositivo (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs). A documentação de backup diz que nenhum limite de largura de banda é aplicado para tráfego de rede privada quando os dados se movem entre dispositivos que compartilham uma conta (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery).

Isso cria uma postura de produto diferente da nuvem pública pura. A IBM pode dizer a um cliente: mantenha o tráfego leste-oeste privado sempre que possível, use caminhos privados incluídos ou sem medição dentro da conta, escolha o bucket de saída pública certo e anexe conectividade direta quando necessário. O cliente ainda paga pelo uso da internet pública, mas a arquitetura dá a ele botões para reduzir a incerteza. Esse é exatamente o tipo de controle que um comprador de estado estável deseja.

O Direct Link mostra até onde esse controle pode ir. A documentação do IBM Direct Link on Classic diz que a configuração envolve configuração básica de rede e Border Gateway Protocol, com engenheiros da IBM trabalhando com o cliente para habilitar a capacidade VRF (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). Diz que a IBM atribui uma rede /31 ou /30 para cada conexão na infraestrutura do roteador de cross-connect da IBM Cloud, e que o BGP é obrigatório para gerenciar o roteamento através do Direct Link (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). O FAQ diz que o uso de largura de banda através do Direct Link entre clientes e a IBM Cloud é gratuito e não medido, enquanto a largura de banda de saída dos serviços da IBM Cloud para a internet pública é medida (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). Também diz que o Direct Link pode fornecer conexões diversas, mas a redundância é criada pelo design BGP do cliente, não por um único serviço inerentemente redundante (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs).

Para um comprador que se preocupa com isolamento de conformidade, faturamento de rede previsível e conectividade privada, é por isso que a IBM manteve o negócio de controle de servidor. O servidor sozinho não é o ativo. O ativo é a capacidade de combinar uma máquina dedicada, endereçamento privado, seleção de VLAN, Direct Link, VRF, velocidade de porta, escolhas de redundância e política de largura de banda em um contrato de infraestrutura. A SoftLayer deu à IBM um vocabulário para essa venda.

O isolamento de conformidade é operacional, não apenas contratual

O bare metal atrai compradores sensíveis a risco porque lhes dá uma história mais simples sobre isolamento. Um servidor físico de único locatário não resolve automaticamente conformidade, segurança ou resiliência. O cliente ainda precisa aplicar patches nos sistemas operacionais, gerenciar credenciais, criptografar dados, projetar backup, controlar ingressos, monitorar logs e provar procedimentos. Mas a alegação de isolamento começa de um lugar diferente: o servidor é dedicado, nenhum hipervisor é imposto pelo provedor, e o cliente tem controle mais direto sobre decisões em nível de host.

A documentação da IBM é cuidadosa sobre isso. Diz que o servidor bare metal é dedicado ao cliente e não compartilhado com outros clientes, enquanto o cliente gerencia o servidor e ele é provisionado sem hipervisor (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Também diz que algumas cargas de trabalho devem ser espalhadas por vários data centers e PODs para evitar um único domínio de falha; simplesmente iniciar vários aplicativos não é suficiente se o local de implantação estiver errado (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Este é um aviso operacional sério. O bare metal dá controle, mas o controle transfere mais responsabilidade de design para o cliente.

O isolamento de rede funciona de forma semelhante. O tutorial da IBM para vincular redes privadas seguras sobre a rede IBM descreve a infraestrutura clássica e diz que a maioria das cargas de trabalho pode ser implementada usando IBM Cloud VPC, mas então mostra como redes privadas seguras em diferentes data centers podem ser vinculadas sobre a rede privada IBM usando VRF ou VLAN spanning, appliances de gateway, roteamento e regras de firewall (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Observa que não há restrição sobre quais dois data centers podem ser usados, exceto o impacto da latência, e que sub-redes privadas, IDs de VLAN, endereços de gateway e regras de firewall devem ser registrados e configurados (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Essa não é a linguagem de uma abstração totalmente gerenciada. É a linguagem da engenharia de infraestrutura.

É precisamente aqui que o modelo da SoftLayer permanece útil para contas reguladas e com controle pesado. O cliente pode construir padrões de segmentação familiares: interfaces públicas e privadas, firewalls, appliances de gateway, VLANs, sub-redes privadas, Direct Link, anúncio de rede remota, BGP, backup, transferência privada de dados e hosts dedicados. A IBM consegue vender serviços em nuvem sem fingir que toda carga de trabalho empresarial deve ser refatorada no mesmo padrão moderno no primeiro dia. O comprador obtém uma etapa de migração que parece mais segura do que uma reescrita completa.

A troca é que a experiência manual não é eliminada. A documentação do Direct Link diz que os clientes são responsáveis por gerenciar os anúncios de rota para e da rede IBM Cloud, e que a falha em planejar o comportamento de encaminhamento BGP pode criar resultados indesejados, como roteamento assimétrico ou caminhos preferidos incorretamente (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). A página de opções de rede adverte que a redundância gerenciada pelo usuário requer que o cliente saiba como configurar a redundância, e que não fazê-lo cria falta de redundância de comunicação de rede durante a manutenção de rotina (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Um comprador não pode comprar um servidor dedicado e assumir resiliência. Deve operar o controle que pediu.

Essa troca é o coração do mercado. A nuvem abstrata vence quando os clientes querem menos decisões de baixo nível. A nuvem estilo SoftLayer vence quando os clientes querem as decisões de volta porque a carga de trabalho, o regulador, a licença, o caminho de latência, o perfil de desempenho ou o plano de migração exige isso. A vantagem da IBM é que ela pode vender ambas as narrativas sob um relacionamento empresarial. Seu risco é que os clientes a punam se qualquer narrativa se tornar pouco clara.

A pressão de substituição da nuvem nunca desapareceu

A pressão contra o modelo da SoftLayer é óbvia: a maior parte do novo consumo de nuvem prefere abstração. Desenvolvedores querem bancos de dados gerenciados, funções serverless, plataformas de contêineres, armazenamento de objetos, integração de identidade, observabilidade, serviços de IA e APIs regionais. Equipes financeiras querem programas de desconto e governança central. Equipes de segurança querem controles padronizados. Equipes de plataforma querem infraestrutura que possa ser criada e destruída sem esperar por testes de hardware. Para esses compradores, um servidor físico pode parecer uma exceção.

A própria página de preços da IBM reflete essa divisão. O bare metal VPC é apresentado como perfis predefinidos implantados em 10 minutos ou menos em uma rede definida por software, ideal para alta disponibilidade e elasticidade máxima (https://www.ibm.com/products/bare-metal-servers/pricing). O bare metal clássico é apresentado como altamente personalizável com mais de 11 milhões de combinações e 20 TB de largura de banda sem custo, ideal para operações estáveis e previsíveis (https://www.ibm.com/products/bare-metal-servers/pricing). Isso não é uma contradição. É a IBM segmentando o mercado: bare metal VPC para clientes que querem construções modernas de nuvem em torno de hardware dedicado, bare metal clássico para clientes que ainda precisam da superfície de controle mais antiga.

A ameaça de substituição também vem da transparência de custos. Os provedores de nuvem pública tornaram os preços granulares, e os preços granulares podem ajudar ou prejudicar o caso do bare metal. A AWS anunciou que a partir de 1º de fevereiro de 2024 cobraria $0,005 por hora por cada endereço IPv4 público, anexado ou não, o que faz com que um ano de um endereço IPv4 público continuamente alocado custe $43,80 antes de outros custos de serviço (https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/). Esse tipo de item de linha empurra os compradores a entender o uso de endereços, design de NAT e exposição pública. Também torna mais fácil comparar provedores de infraestrutura dedicada com pacotes de endereço e largura de banda incluídos, mesmo que a comparação nunca seja perfeita.

As páginas dos concorrentes mostram a mesma pressão de mercado. A OVHcloud posiciona o bare metal em torno de recursos dedicados, anti-DDoS, rede privada e infraestrutura previsível para cargas de trabalho que precisam de controle (https://us.ovhcloud.com/bare-metal/). A Hetzner lista servidores root dedicados com preços mensais agressivos que podem fazer a proposta orientada a empresas da IBM parecer cara para compradores europeus sensíveis a preço (https://www.hetzner.com/dedicated-rootserver). A TrustRadius, um site de análise e comparação, não um vendedor primário, lista os IBM Cloud Bare Metal Servers a partir de $0,51 por hora e $241 por mês, observando opções horárias ou mensais e 500 GB/mês de largura de banda de saída em seu resumo de preços (https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricing). Esse preço de terceiros deve ser tratado como um sinal de mercado, não como um contrato, mas mostra como os compradores comparam a IBM com alternativas mais baratas e simples.

A defesa da IBM não é ser o servidor dedicado mais barato. É conectar o bare metal à arquitetura de nuvem híbrida, suporte empresarial, software IBM, estratégia Red Hat/OpenShift, conectividade direta, contas empresariais adjacentes ao mainframe, cargas de trabalho reguladas, padrões SAP e VMware e aquisição global. A página de investidores da IBM diz que a empresa está posicionada em torno de nuvem híbrida e IA (https://www.ibm.com/investor). Seu relatório anual de 2025 diz que a receita de Hybrid Cloud sob Software foi de $7,327 bilhões e a receita recorrente anual do OpenShift atingiu $1,9 bilhão no final de 2025 (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). O papel da SoftLayer dentro dessa IBM não é liderar a narrativa. É fornecer a opção de infraestrutura física e clássica quando a venda de nuvem híbrida atinge uma carga de trabalho que ainda quer a caixa.

O risco é que um produto mantido para controle se torne um produto mantido por inércia. Se a infraestrutura clássica permanece valiosa porque os clientes precisam ativamente de seus recursos, a IBM pode colher um nicho durável. Se permanece apenas porque as migrações são difíceis, torna-se um fardo legado. A diferença é visível na qualidade do uso: os clientes estão escolhendo bare metal clássico para operações previsíveis, largura de banda privada e isolamento físico, ou estão presos a ele porque aplicativos e scripts mais antigos são caros de mover? A evidência pública não pode responder com precisão, mas enquadra a questão corretamente.

A superfície operacional é maior que o servidor

O design original da SoftLayer deve ser entendido como uma superfície operacional: controle de servidor, controle de rede, anexação de armazenamento, identidade, suporte, automação de API, faturamento e colocação de instalações. A documentação atual da IBM preserva essa amplitude. O bare metal pode ser combinado com armazenamento em bloco e arquivo de 20 a 12.000 GB no momento do provisionamento, embora o armazenamento adicional deva ser conectado após o servidor ser provisionado (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Os complementos de bare metal incluem firewall de hardware, monitoramento, backup, resposta, endereços IP públicos secundários e opções de endereço IPv6 (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). As opções de rede incluem escolhas apenas públicas, apenas privadas, interfaces privadas incluídas por padrão, seleção de saída pública, seleção de VLAN, seleção de sub-rede e solicitações de endereço IP secundário (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

A superfície da API importa porque muda a economia do trabalho. Se um cliente pode solicitar, inspecionar, reconfigurar e cancelar infraestrutura programaticamente, o servidor físico se torna parte de um sistema operacional maior, em vez de um ticket único. A documentação da API de servidor virtual da IBM diz que a SoftLayer API alimenta muitos recursos do console da IBM Cloud e pode automatizar todas as partes do ambiente IBM Cloud acessíveis através da API (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). A SoftLayer Development Network expõe SDKs para Python, Java, Go, Perl, PHP e Ruby, bem como um plugin de infraestrutura clássica para a CLI da IBM Cloud (https://sldn.softlayer.com/). Essa é uma base instalada profunda de comportamento de ferramentas.

O plano de controle, no entanto, também trava expectativas. Um script empresarial de longa execução pode assumir nomes de objeto específicos, comportamento de método, padrões de autenticação, códigos de localização, convenções de VLAN ou comportamento de item de faturamento. Uma nota de versão da API em 2026 que remove métodos de serviço obsoletos é um evento normal de manutenção, mas para uma plataforma antiga ainda pode importar para os clientes (https://sldn.softlayer.com/). Todo negócio maduro de infraestrutura tem esse problema. Quanto mais poderosa a superfície de controle, mais ela se torna parte do próprio código operacional do cliente.

Instalações e roteamento adicionam outra camada. A página pública do PeeringDB mostra AS-SOFTLAYER e uma política de peering pública que é seletiva, prefere múltiplos locais, não tem exigência de proporção e não tem exigência de contrato (https://www.peeringdb.com/net/1613). As capacidades de troca listadas na página incluem 200G no DE-CIX Dallas, 200G no DE-CIX Frankfurt, 200G no DE-CIX Madrid, 100G no DE-CIX Chicago, 80G no Equinix Ashburn, 60G no Equinix Chicago, 60G no Equinix Miami e links menores em muitas outras trocas (https://www.peeringdb.com/net/1613). Esses números não provam satisfação do cliente ou receita. Eles mostram a pegada de roteamento que suporta uma plataforma global de infraestrutura.

Essa pegada é tanto ativo quanto custo. Portas de troca, cross-connects, capacidade de roteador, política de rota, engenharia de tráfego, tratamento de abuso, resposta a DDoS, janelas de manutenção, compromissos de colocation e engenharia de rede não se monetizam sozinhos. Eles importam quando mantêm os clientes de sair. Um cliente com uma carga de trabalho estável, requisitos de BGP, conectividade privada e tráfego previsível pode ser pegajoso porque mudar não é apenas uma migração de servidor. É uma migração de rede e operações.

É por isso que a economia da SoftLayer se encaixa melhor na IBM do que em uma empresa de hospedagem puramente de baixo custo. A IBM pode anexar infraestrutura de controle de rede a uma conta empresarial mais ampla. Pode vender consultoria em torno de migração e modernização. Pode conectar bare metal a Red Hat, VMware, SAP, integração IBM Z, postura de segurança e serviços gerenciados. O servidor dedicado não é então toda a história da margem. É a âncora que mantém uma carga de trabalho específica dentro do limite da conta da IBM.

A evidência também mostra o que não pode ser conhecido publicamente

A evidência pública é forte em identidade, superfície de rede, histórico de aquisição, mecânica de produto e postura de preços. É fraca em finanças atuais específicas da SoftLayer. A IBM não divulga receita da SoftLayer, utilização de bare metal clássico da IBM Cloud, margem bruta por data center, churn por classe de carga de trabalho, custo de suporte por servidor, porcentagem de cargas de trabalho clássicas convertidas para bare metal VPC, economia de inventário IPv4, ou a verdadeira receita agregada de Direct Link, suporte, armazenamento, backup e complementos de segurança. Isso significa que qualquer avaliação deve ser conservadora.

O número ausente mais importante é a utilização por classe de hardware e localização. Uma plataforma bare metal pode parecer saudável se a rede principal for grande e a página de produto for ampla, enquanto ainda carrega bolsões de hardware encalhado. Gerações mais antigas de CPU podem ser baratas de vender, mas caras em eficiência energética. Configurações de alta memória ou prontas para GPU podem comandar preços melhores, mas exigem aquisição cuidadosa. Alguns mercados podem ter forte demanda por conectividade privada e largura de banda previsível; outros podem exigir descontos.

As páginas públicas mostram amplitude de produto, não taxa de ocupação.

O segundo número ausente é o fluxo de migração. As páginas de produto da IBM agora distinguem bare metal VPC e infraestrutura clássica. Uma estratégia racional da IBM moveria os clientes para construções mais novas sempre que possível, preservando o controle clássico quando necessário. Mas sem uma métrica pública de migração, leitores externos não podem saber se o bare metal clássico está crescendo, estável, diminuindo graciosamente ou retido principalmente para contas mais antigas. Os materiais de investidores da IBM enfatizam nuvem híbrida, Red Hat e IA mais do que infraestrutura clássica (https://www.ibm.com/investor/services/annual-report). Isso não significa que o bare metal clássico seja sem importância. Significa que sua importância é operacionalmente específica, não estratégica principal.

O terceiro número ausente é a qualidade do suporte. Os clientes de bare metal julgam o provedor quando algo físico quebra ou uma rota muda. A documentação da IBM adverte que falhas de hardware, bugs de software, problemas de rede e manutenção podem causar interrupções, e que espalhar aplicativos por vários data centers e PODs é necessário para disponibilidade (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Isso é tecnicamente honesto. Mas os clientes ainda experimentam falhas através da resposta de suporte. As páginas públicas de produto não podem nos dizer se o suporte da IBM é rápido o suficiente no momento em que um drive falha, uma VLAN se comporta mal, uma rota Direct Link está errada ou um servidor apenas privado foi pedido incorretamente.

O quarto número ausente é o custo de abuso e reputação. Redes de hospedagem atraem cargas de trabalho empresariais legítimas, mas o espaço IP público e servidores dedicados também atraem spam, raspagem, atividade de bot, infraestrutura de phishing e revendedores de alto risco. Os registros PeeringDB e BGP provam escala; não provam qualidade de reputação. A postura de controle de rede, processos de suporte e gerenciamento de endereços da IBM importam aqui porque uma faixa de endereços suja ou incidente repetido de abuso pode tornar um servidor barato caro. A evidência pública não nos permite pontuar isso diretamente.

Essas incertezas não devem ser tratadas como defeitos no artigo. Elas são a economia. O registro público nos diz por que a IBM manteria um negócio de controle de servidor. Não nos diz se cada rack, geração de CPU e coorte de cliente obtém retornos atraentes.

O que um comprador subscreveria hoje

Um grande comprador decidindo se coloca cargas de trabalho estáveis no bare metal da IBM Cloud subscreveria um conjunto diferente de fatos do que um desenvolvedor escolhendo uma instância virtual. Começaria com identidade e continuidade: a SoftLayer foi adquirida pela IBM, o produto atual é IBM Cloud Bare Metal Servers, a API e os controles de infraestrutura clássica permanecem documentados, e a identidade de rede ainda aparece nos dados ARIN, PeeringDB e BGP (https://rdap.arin.net/registry/entidade/SOFTL,https://rdap.arin.net/registry/autnum/36351,https://www.peeringdb.com/net/1613ehttps://bgp.tools/as/36351). Testaria então as promessas do produto: único locatário, sem hipervisor do provedor, faturamento horário ou mensal, provisionamento rápido, 20 TB de largura de banda clássica sem custo, inclusão de rede privada, opções de velocidade de porta, escolhas de redundância, Direct Link, BGP, VRF e movimento privado de dados (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-optionsehttps://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link).

O comprador também testaria o comportamento de falha. Se uma carga de trabalho precisar de disponibilidade contínua, a própria documentação da IBM diz que vários servidores de aplicação e a colocação em vários data centers e PODs devem ser considerados (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Se um comprador quiser um servidor único de custo mais baixo sem link redundante, deve aceitar que a manutenção de rotina pode interromper a comunicação. Se o comprador quiser Direct Link, deve entender que a redundância é criada através do design BGP e conexões diversas, não pela existência de um único serviço (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). Se quiser implantação apenas privada, deve decidir isso no provisionamento porque a interface pública não pode ser adicionada posteriormente a um servidor apenas privado (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).

Um credor ou adquirente faria as perguntas mais difíceis que a IBM não publica: receita recorrente por coorte, utilização por localização, idade do hardware, custo de energia do data center, volume de tickets de suporte, receita de excesso de saída pública, custo da rede privada, taxa de anexação do Direct Link, anexação de armazenamento e backup, concentração de clientes, taxa de renovação em termos contratuais e o número de contas que ainda dependem do comportamento mais antigo da API SoftLayer. Separaria a demanda saudável impulsionada por controle da demanda legada impulsionada por inércia. A primeira merece investimento.

A segunda merece planejamento de migração e proteção de margem.

Um regulador se importaria com alegações de controle e clareza do cliente. O bare metal pode ajudar com o isolamento, mas apenas se os clientes entenderem quais obrigações permanecem deles. A documentação da IBM é explícita de que o cliente gerencia o servidor e que os backups de dispositivos do cliente não são concluídos pela IBM a menos que o cliente inicie backups programados ou únicos através de soluções relevantes (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmehttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery). Um comprador sensível à conformidade deve ler isso com atenção. Locação única não é conformidade gerenciada. É um ponto de partida físico e operacional.

A conclusão da subscrição é equilibrada. A SoftLayer dá à IBM uma superfície de controle credível para cargas de trabalho que não se encaixam perfeitamente na nuvem abstrata. A evidência pública suporta uma rede real, continuidade real da API, mecânica real do produto e relevância real da nuvem híbrida. Mas a evidência pública não suporta uma alegação simples de que a SoftLayer, como nome legado, é um motor de crescimento por si só. Seu valor está embutido: controle de servidor dentro da IBM Cloud, útil quando o cliente quer nuvem sem perder a máquina.

Registro de evidências para as alegações públicas

A evidência de aquisição e escala histórica vem do anúncio de aquisição da IBM, do anúncio de fechamento da IBM, do anúncio de venda da GI Partners e do relatório do Los Angeles Times sobre o valor do negócio reportado de US$ 2 bilhões: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-ibmehttps://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html.

A evidência atual de rede e identidade vem da ARIN RDAP, PeeringDB, visualização da API do PeeringDB e BGP.tools:https://rdap.arin.net/registry/entidade/SOFTL,https://rdap.arin.net/registry/autnum/36351,https://rdap.arin.net/registry/entidade/IBMC-24,https://www.peeringdb.com/net/1613,https://www.peeringdb.com/api/net/1613?depth=2ehttps://bgp.tools/as/36351.

A evidência de produto e preços bare metal vem da página de preços bare metal da IBM e da documentação bare metal da 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-recoveryehttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr.

A evidência da API e do plano de controle vem das referências da API da IBM Cloud e da 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-apiehttps://sldn.softlayer.com/.

A evidência de conectividade privada e VLAN vem da documentação do IBM Cloud Direct Link e 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-exchangeehttps://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures.

O contexto estratégico e financeiro da IBM vem da página de investidores da IBM e do relatório anual de 2025:https://www.ibm.com/investor,https://www.ibm.com/investor/services/annual-reportehttps://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf.

A evidência de substituição e comparação de mercado vem dos preços IPv4 públicos da AWS, bare metal da OVHcloud, servidores root dedicados da Hetzner, resumos de preços bare metal da IBM na TrustRadius e a discussão de 2013 no Hacker News como um sinal informal do mercado de desenvolvedores: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/pricingehttps://news.ycombinator.com/item?id=5819227.

Conclusão e pontos de observação

A lição duradoura da SoftLayer é que a nuvem não aboliu o servidor. Ela mudou a forma como o servidor é comprado, conectado, automatizado e financiado. A IBM manteve a lógica de controle de servidor da SoftLayer porque algumas cargas de trabalho empresariais ainda precisam de isolamento físico, largura de banda previsível, roteamento privado, colocação conhecida e escolha operacional de baixo nível. O fato de a IBM agora se comercializar principalmente em torno de nuvem híbrida e IA não enfraquece esse argumento. Torna o argumento mais preciso.

A nuvem híbrida precisa de lugares onde infraestrutura antiga e nova possam se encontrar, e o design da SoftLayer dá à IBM um desses lugares.

O caso positivo é que a IBM pode continuar monetizando o legado da SoftLayer como uma opção de infraestrutura de alto controle: bare metal clássico para operações estáveis e previsíveis, bare metal VPC para padrões de nuvem mais novos, Direct Link para conectividade privada, continuidade da API SoftLayer para automação existente e os relacionamentos de conta empresarial da IBM para cargas de trabalho que não podem ser atendidas apenas por hospedagem de baixo custo.

Os números que suportam este caso são 13 data centers originais, 100.000 dispositivos, 21.000 clientes, uma aquisição reportada de US$ 2 bilhões, 1.800 prefixos IPv4 no PeeringDB, 450 prefixos IPv6, tráfego de 1-5 Tbps no PeeringDB, mais de 11 milhões de combinações de configuração clássica, 20 TB de largura de banda sem custo no clássico, implantação de bare metal VPC em 10 minutos ou menos e provisionamento rápido de 30 a 40 minutos para servidores clássicos.

O caso negativo é que o controle pode se tornar um fardo. Se a infraestrutura clássica for retida principalmente porque cargas de trabalho mais antigas são difíceis de mover, a IBM deve proteger a margem enquanto carrega suporte legado, comportamento antigo da API, atualização de hardware, reputação de endereço, complexidade de data center e expectativas do cliente.

Se provedores de bare metal mais baratos pressionarem contas de commodities e hiperscaladores absorverem cargas de trabalho de alto nível em serviços gerenciados, a IBM deve continuar provando por que sua camada de controle de servidor pertence a um relacionamento premium de nuvem híbrida.

Os pontos de observação são concretos. Primeiro, observar se a IBM continua melhorando tanto o bare metal VPC quanto o bare metal clássico, em vez de deixar um silenciosamente definhar o outro. Segundo, observar se o Direct Link, VRF e controles de rede privada se tornam mais fáceis para os clientes sem perder transparência. Terceiro, observar mudanças públicas de roteamento e PeeringDB em torno de AS36351, porque mostram se a rede permanece ampla e atual.

Quarto, observar preços IPv4 e política de endereços em toda a indústria, porque a escassez de endereços públicos pode fortalecer o caso de provedores com alocação disciplinada e largura de banda incluída. Quinto, observar os relatórios anuais da IBM para mudanças na ênfase de infraestrutura, nuvem híbrida e Red Hat, porque o valor da SoftLayer está cada vez mais ligado a quão bem a IBM empacota controle físico com estratégia de software.

A SoftLayer não é o rosto da IBM moderna. Esse é o ponto. É a parte da IBM Cloud que ainda responde a um comprador teimoso com uma necessidade teimosa: dê-me a conveniência da nuvem, mas não faça o servidor desaparecer.