Resumen
- Qué explica: SoftLayer Technologies fue adquirida por IBM en 2013 por unos 2.000 millones de dólares.
- Tema principal: Network-resource evidence
- Contexto: Cloud Service
El comprador que aún quiere saber qué máquina es la suya
El cliente más revelador de SoftLayer no es el desarrollador que busca una máquina virtual barata para una prueba de fin de semana. Es el comprador que ya ha vivido el problema opuesto: una carga de trabajo trasladada a una nube pública altamente abstracta, facturada por muchos pequeños medidores, protegida por muchos controles compartidos, y que luego resultó ser demasiado estable, demasiado regulada, demasiado sensible a la latencia, demasiado específica de la red o demasiado obstinada operativamente para estar satisfecha allí. Ese comprador aún desea pedidos en la nube, flexibilidad comercial por hora o por mes, control de API y acceso a almacenamiento, copias de seguridad, soporte y conectividad privada. Pero también quiere saber que el servidor es de uso exclusivo, que la ruta de red está diseñada en lugar de adivinada, que la salida pública no es una sorpresa ilimitada y que el aislamiento se basa en el control del hardware en lugar de solo en la lógica del inquilino.
SoftLayer Technologies es importante porque construyó un gran negocio en torno a ese comprador antes de que el mercado de la nube pública aprendiera a describir el problema como "nube híbrida". IBM no adquirió SoftLayer en 2013 para comprar una pequeña marca de hosting. Compró un modelo operativo en el que la nube podía significar tanto servidores físicos como instancias virtuales, redes privadas tanto como alcance de internet público, y control de infraestructura tanto como velocidad de desarrollo. El anuncio de IBM decía que SoftLayer ofrecía a los clientes la posibilidad de elegir entre servidores dedicados y compartidos, dispositivos físicos y virtuales, patrones de nube pública y privada, una API completa, automatización y una red global de baja latencia (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). El anuncio de cierre decía que SoftLayer se uniría a una nueva división de servicios en la nube de IBM, combinándose con IBM SmartCloud en una plataforma global (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html).
La columna vertebral de números concretos es inusualmente sólida para una antigua adquisición de nube privada. En el momento del anuncio, se describía a SoftLayer operando 13 centros de datos en Estados Unidos, Asia y Europa, con 100.000 dispositivos bajo gestión (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). GI Partners, el vendedor, afirmó que la empresa gestionaba más de 100.000 servidores, firewalls y balanceadores de carga, atendía a más de 21.000 clientes en más de 140 países y operaba 13 centros de datos en todo el mundo (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). El Los Angeles Times informó que el valor del acuerdo era de 2.000 millones de dólares, aunque señaló que IBM no reveló los términos (https://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html). A partir de 2026, la evidencia de la red pública todavía muestra una gran superficie de IBM Cloud bajo la identidad de red de SoftLayer: PeeringDB enumera AS36351 como "SoftLayer Technologies, Inc. (an IBM Company)", también conocida como IBM Cloud, con 1.800 prefijos IPv4, 450 prefijos IPv6 y entre 1 y 5 Tbps de tráfico (https://www.peeringdb.com/net/1613). La página actual de precios de servidores bare-metal de IBM dice que la infraestructura clásica ofrece más de 11 millones de combinaciones de configuración y 20 TB de ancho de banda sin costo, mientras que los bare-metal VPC pueden implementar perfiles predefinidos en 10 minutos o menos (https://www.ibm.com/products/bare-metal-servers/pricing).
Esas cifras explican por qué la historia de SoftLayer no es nostalgia. Describen la parte de la economía de la nube que nunca se volvió completamente abstracta. Algunas cargas de trabajo no necesitan realmente "una nube" en el sentido de marketing. Necesitan un servidor controlado, un comportamiento de red predecible, suficiente ancho de banda privado, un canal de soporte conocido, un plan de enrutamiento y una estructura comercial que no penalice el uso constante. El valor estratégico de SoftLayer fue hacer que esos viejos requisitos se sintieran lo suficientemente modernos como para integrarse en IBM Cloud.
IBM compró un negocio de control, no solo capacidad
El mercado de la nube en 2013 ya se movía hacia la abstracción. Amazon Web Services había convertido la instancia virtual en el modelo mental predeterminado. OpenStack intentaba estandarizar el software de nube privada. Los compradores empresariales comenzaban a hablar de implementaciones híbridas, pero muchos aún trataban la nube pública y el alojamiento dedicado como categorías separadas. El atractivo de SoftLayer era que difuminaba la línea desde el lado de la infraestructura. IBM podía decirle a un comprador empresarial que la misma plataforma admitía nube pública, nube privada alojada, servidores bare-metal e instancias virtuales, sin forzar cada carga de trabajo a través de las mismas suposiciones de virtualización compartida.
Esa distinción es visible en el lenguaje de adquisición de IBM. El comunicado de 2013 decía que SoftLayer permitía a los clientes comprar servicios de nube de clase empresarial en servidores dedicados o compartidos, y que su arquitectura abarcaba dispositivos físicos y virtuales (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). El comunicado de cierre decía que SoftLayer permitiría a IBM combinar la seguridad, privacidad y fiabilidad de la nube privada con la economía y velocidad de la nube pública (https://www.prnewswire.com/news-releases/ibm-closes-acquisition-of-softlayer-technologies-214589711.html). La redacción suena a marketing, pero la afirmación económica es específica: IBM estaba comprando una plataforma donde la adopción de la nube no requería renunciar al control a nivel de servidor.
Eso importaba porque la base natural de clientes de IBM no se parecía a una startup de internet para consumidores. Los bancos, aseguradoras, organizaciones sanitarias, contratistas gubernamentales, proveedores de software, cuentas de externalización, proveedores de servicios gestionados y empresas industriales a menudo se preocupan por la auditabilidad, el aislamiento físico, el enrutamiento, la escalada de soporte, la portabilidad de licencias, el control del sistema operativo y la previsibilidad del rendimiento. Algunas de esas necesidades pueden satisfacerse en diseños modernos de nube privada virtual. Otras son más fáciles de vender cuando el comprador puede señalar un servidor físico de uso exclusivo y un plazo contractual.
La adquisición también dio a IBM una respuesta más creíble a un problema comercial. Una cuenta empresarial tradicional podría querer trasladar solo una parte de una carga de trabajo fuera de las instalaciones, sin reescribir todo para operaciones nativas de la nube. El modelo de SoftLayer permitió a IBM vender una zona de aterrizaje que se sentía más cercana al entorno existente del cliente: máquinas dedicadas, VLANs, dispositivos de puerta de enlace, balanceadores de carga, firewalls, complementos de almacenamiento, productos de copia de seguridad, tickets de soporte e ingeniería de redes. Ese tipo de comprador no es necesariamente hostil a la nube pública. Es hostil a perder influencia operativa antes de que se demuestre el caso de negocio.
El historial de capital privado refuerza este punto. GI Partners adquirió EV1 y The Planet en 2006, adquirió SoftLayer en 2010 y fusionó SoftLayer y The Planet antes de venderlo a IBM (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Esto no fue una historia puramente de software. Fue una consolidación de alojamiento dedicado, operaciones de red y capacidades de servicios de centro de datos en un proveedor de infraestructura automatizado. El activo valioso no eran solo los servidores. Era el saber hacer necesario para convertir la infraestructura física en un producto comercial repetible.
El lenguaje actual de los productos de IBM mantiene viva esa distinción. Su documentación de bare-metal define el servidor bare-metal clásico como por horas o meses, de uso exclusivo, dedicado al cliente, sin compartir en ninguna parte, aprovisionado sin hipervisor y desplegado en uno o más centros de datos (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). La página de introducción dice que los servidores bare-metal de IBM Cloud se pueden desplegar y gestionar como servicios en la nube con facturación por horas y meses en infraestructura clásica o VPC (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-getting-started). En otras palabras, el producto ha mantenido la promesa central de SoftLayer: un pedido en la nube puede resultar aún en un servidor físico.
La identidad de SoftLayer ahora vive en la red y en los controles del producto
SoftLayer ya no se entiende mejor como una empresa operativa pública independiente. La lectura actual defendible es que SoftLayer sobrevive como una marca heredada, un conjunto de API de plataforma, una identidad de red pública y un linaje de diseño dentro de IBM Cloud. Eso no es un patrón de hechos débil. Para la infraestructura, la identidad de red y la continuidad operativa a menudo importan más que la marca orientada al consumidor.
La evidencia del registro público de ARIN aún lleva el nombre anterior. El registro de organización RDAP para SOFTL identifica a SoftLayer Technologies Inc. en 4849 Alpha Road en Dallas, Texas, con un evento de registro en 2005 y un último cambio en 2024 (https://rdap.arin.net/registry/entity/SOFTL). El registro RDAP para AS36351 nombra SOFTLAYER y enumera al registrante como IBM Cloud en la dirección de Armonk de IBM (https://rdap.arin.net/registry/autnum/36351). BGP.tools presenta AS36351 como IBM Cloud, registrado en diciembre de 2005, activo y asignado bajo ARIN, con proveedores upstream que incluyen Arelion, Lumen, NTT America, Bharti Airtel, Telstra, Hurricane Electric, Tata Communications y Telxius (https://bgp.tools/as/36351). PeeringDB proporciona la forma orientada al peering: SoftLayer Technologies, Inc. (an IBM Company), también conocida como IBM Cloud, AS-SOFTLAYER, ámbito norteamericano, política de peering selectiva, 1.800 prefijos IPv4, 450 prefijos IPv6 y entre 1 y 5 Tbps de tráfico (https://www.peeringdb.com/net/1613).
Existe una diferencia importante entre los recuentos de prefijos de PeeringDB y los recuentos de rutas originadas de BGP.tools. PeeringDB es un directorio de interconexión automantenido, útil para el contexto de políticas de peering y contacto del operador. BGP.tools refleja el enrutamiento observado y mostraba 339 prefijos IPv4 originados y 72 prefijos IPv6 originados en la página revisada para este artículo (https://bgp.tools/as/36351). Las dos mediciones no deben tratarse como idénticas. El punto económico no es el número exacto de rutas. Es que la identidad de red de SoftLayer permanece unida a una gran superficie de enrutamiento de IBM Cloud, con muchos prefijos de clientes y servicios visibles en los datos de enrutamiento público.
La API de SoftLayer es otra señal de continuidad. La documentación de IBM Cloud dice que la SoftLayer Application Programming Interface es la interfaz de desarrollo que brinda a los desarrolladores y administradores una interacción directa con el backend de IBM Cloud; impulsa muchas características de la consola y puede automatizar tareas, utilizando SOAP, XML-RPC o REST (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). La SoftLayer Development Network todavía publica notas de lanzamiento, enlaces SDK y referencias CLI bajo el nombre de SoftLayer, con notas de lanzamiento de API de 2026 visibles en su página principal (https://sldn.softlayer.com/). Esto no es sentimentalismo de marca. Muestra un plano de control maduro que los clientes, scripts, herramientas e integraciones de socios todavía pueden tocar.
Esa continuidad tiene valor y riesgo. Da a los clientes existentes una forma estable de gestionar la infraestructura clásica, pedir dispositivos, inspeccionar recursos y automatizar operaciones. También significa que IBM debe arrastrar comportamientos heredados, nombres antiguos, expectativas maduras de los clientes y compatibilidad hacia atrás. Cuanto más valiosa sea la antigua superficie de control para los clientes, con más cuidado tendrá que cambiarla IBM. Esa es una de las razones por las que los negocios de control de servidores no desaparecen rápidamente incluso cuando el lenguaje del mercado se dirige hacia VPCs, contenedores y plataformas de IA.
La huella de interconexión pública también muestra por qué SoftLayer nunca fue simplemente "alojamiento". El registro detallado de PeeringDB muestra puntos de intercambio público que incluyen 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 y otros, con capacidades que van desde 10G y 20G hasta 100G y 200G en conexiones seleccionadas (https://www.peeringdb.com/net/1613). La vista API del registro de PeeringDB devuelve 73 conexiones de intercambio público y 40 instalaciones de interconexión para la red cuando se solicita con profundidad (https://www.peeringdb.com/api/net/1613?depth=2). La combinación exacta puede cambiar, pero la evidencia confirma una superficie operativa construida en torno al enrutamiento, la interconexión y la gestión del tráfico, no solo el espacio físico del centro de datos.
El bare metal convierte la economía de la nube de nuevo en matemáticas de utilización
El centro económico del artículo es simple: el bare metal es la nube vendida con el riesgo de inventario dejado visible. Una máquina virtual a hiperescala es una abstracción sobre un conjunto. Un servidor físico dedicado es una máquina específica que debe ser comprada, alimentada, cableada, refrigerada, probada, monitoreada, reparada, renovada, asegurada, conectada y, en última instancia, llenada de ingresos. La innovación histórica de SoftLayer fue hacer que esa máquina física se pudiera pedir a través de una interfaz similar a la nube. El desafío económico de IBM es mantener esa interfaz atractiva sin permitir que el hardware subyacente se convierta en inventario de baja utilización.
Las páginas de producto actuales de IBM muestran cómo se gestiona eso. El bare metal clásico se presenta como personalizable, con más de 11 millones de combinaciones de configuración y 20 TB de ancho de banda sin costo, dirigido a operaciones grandes, estables y predecibles (https://www.ibm.com/products/bare-metal-servers/pricing). Los servidores de aprovisionamiento rápido están preconfigurados y listos para configurar 30-40 minutos después del aprovisionamiento (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Los servidores personalizados dependen de la complejidad, la cantidad y las opciones de prueba (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). La misma documentación dice que el aprovisionamiento de bare metal generalmente toma hasta 4 horas, y que las pruebas de hardware extendidas toman 2 horas adicionales; las pruebas que encuentren errores de hardware críticos o irrecuperables conducen al reemplazo de componentes antes de que continúe el aprovisionamiento (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm).
Esos detalles importan porque describen la curva de costes. Un servidor preconfigurado puede ser más rápido porque IBM ya ha estandarizado la forma. Un servidor personalizado es más lento porque el cliente le pide a IBM que ensamble o asigne un activo físico más específico. Las pruebas de hardware protegen la fiabilidad pero retrasan el inicio de ingresos y consumen mano de obra. Un diseño de uso exclusivo crea aislamiento pero impide que IBM use esa máquina para otro inquilino mientras el cliente la mantiene. El producto puede parecerse a la nube para el comprador, pero la base de costes sigue estando más cerca de las operaciones del centro de datos que del software puro.
Aquí es donde la afirmación de 20 TB de ancho de banda sin costo es estratégicamente importante. Para cargas de trabajo constantes, la certeza del ancho de banda es parte del producto. Una plataforma de video, un proveedor de análisis, un servicio de copia de seguridad, un backend de juegos, un repositorio de software, un servicio de datos financieros o un host de integración empresarial a menudo puede estimar su tráfico de referencia mejor de lo que una startup explosiva puede estimar el pico de cómputo. Si el comprador puede mapear un costo mensual del servidor a un conjunto conocido de ancho de banda incluido, un plan de servidor dedicado puede parecer menos riesgoso que una factura de nube pública compuesta por horas de cómputo, E/S de almacenamiento, puertas de enlace NAT, tráfico entre zonas, salida a internet y medidores de servicios gestionados. La página de precios de IBM distingue explícitamente el bare metal clásico como bueno para operaciones grandes, estables y predecibles (https://www.ibm.com/products/bare-metal-servers/pricing).
Las reservas y los plazos contractuales muestran la otra cara de la negociación de utilización. La página de precios de IBM dice que las reservas de bare-metal VPC pueden reducir el gasto hasta un 35 por ciento con un plazo de un año o hasta un 60 por ciento con un plazo de tres años, y que las reservas garantizan capacidad en la zona de disponibilidad y centro de datos seleccionados durante la vida del plazo (https://www.ibm.com/products/bare-metal-servers/pricing). La documentación de plazo contractual clásico dice que un plazo contractual de un año mantiene la capacidad bare-metal en el centro de datos y POD seleccionados durante la vida del contrato, pero el cliente no puede cambiar la configuración después de que se complete el pedido y no puede cancelar el plazo contractual (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-reserved-bare-metal-servers). Eso no es solo descuento. Es una transferencia del riesgo de utilización. IBM da alivio de precios porque el cliente da certeza de demanda.
La misma lógica se aplicaba a SoftLayer en 2013. Una plataforma con 100.000 dispositivos bajo gestión y 21.000 clientes podía ser valiosa porque tenía suficiente variedad y escala para suavizar la demanda entre muchos tipos de clientes (https://www.gipartners.com/news/gi-completes-sale-of-softlayer-technologies-to-ibm). Una empresa más pequeña de alojamiento dedicado puede quedar atrapada con los servidores equivocados en los mercados equivocados. Una plataforma más grande puede estandarizar construcciones comunes, reutilizar piezas, dirigir la demanda entre ubicaciones y adjuntar servicios de mayor margen. Pero incluso a escala de IBM, un servidor físico que no se alquila es capital ocioso. Por lo tanto, el negocio recompensa la precisión de las previsiones, la disciplina de adquisiciones, el momento de la renovación del hardware, el diseño de configuración estándar, la calificación de ventas y la retención.
Eso convierte a SoftLayer en un buen caso de estudio sobre la diferencia entre "crecimiento de la nube" y "margen de la nube". El informe anual de IBM de 2025 describe una compañía ahora centrada en la nube híbrida y la IA, con ingresos totales en 2025 de 67.535 millones de dólares, ingresos por software de 29.962 millones de dólares, ingresos por nube híbrida de 7.327 millones de dólares e ingresos por infraestructura de 15.718 millones de dólares (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). Pero IBM no revela una línea de ingresos de SoftLayer. La evidencia pública no permite a un lector externo calcular el margen bruto o la utilización del bare metal clásico de IBM Cloud. El mejor método público es leer la mecánica del producto: qué precios fija IBM, qué reserva, qué incluye, qué mide y qué compromisos operativos mantiene visibles.
La facturación de red es la razón oculta por la que SoftLayer todavía tiene sentido
Para muchas cargas de trabajo empresariales, la variable decisiva no es la CPU. Es la previsibilidad de la red. Un servidor bare-metal es útil solo si el cliente puede confiar en cómo el tráfico entra, sale y se mueve de forma privada. La propuesta original de SoftLayer incluía comunicación segura de baja latencia y una red global (https://www.prnewswire.com/news-releases/ibm-to-acquire-softlayer-to-accelerate-adoption-of-cloud-computing-in-the-enterprise-210061861.html). La documentación actual de IBM mantiene esa lógica de red como central.
Cada servidor bare-metal de IBM Cloud incluye acceso a la red privada, y una interfaz pública es una elección de aprovisionamiento en lugar de una suposición automática (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). La página de opciones de red dice que el acceso a la red privada siempre está incluido, mientras que el cliente elige si el servidor también tiene acceso a internet público; a un servidor aprovisionado solo como privado no se le puede agregar una interfaz pública más tarde (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). También enumera opciones de velocidad de puerto de 100 Mbps, 1 Gbps, 10 Gbps y 25 Gbps, con 25 Gbps limitado a opciones de servidor seleccionadas y centros de datos seleccionados (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
La misma página hace explícito el intercambio operativo. La redundancia automática de puertos es la configuración predeterminada y recomendada, que proporciona dos puertos físicos de red configurados con enlace LACP tanto en la red como en el sistema operativo durante el aprovisionamiento; la redundancia gestionada por el usuario proporciona dos puertos pero requiere acción del cliente; la no redundancia se mantiene solo para necesidades especializadas y debe seleccionarse solo en consulta con ventas o soporte de IBM bajo condiciones específicas (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Esa es la economía clásica de SoftLayer. El producto ofrece a los clientes opciones a nivel de hardware, pero las opciones vienen con obligaciones operativas.
La salida pública es otro medidor clave. La documentación de opciones de red de IBM dice que los clientes eligen el tráfico público saliente incluido por período de facturación; el exceso se cobra por GB; el tráfico público entrante es gratuito (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). La documentación de gráficos de ancho de banda dice que los datos públicos salientes transferidos desde los centros de datos de IBM Cloud en todo el mundo se evalúan como cargos por ancho de banda saliente, mientras que los gráficos de ancho de banda muestran el uso de la red pública y privada asociado con un dispositivo (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-bm-view-bandwidth-graphs). La documentación de copia de seguridad dice que no se aplica límite de ancho de banda para el tráfico de red privada cuando los datos se mueven entre dispositivos que comparten una cuenta (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery).
Esto crea una postura de producto diferente a la de la nube pública pura. IBM puede decirle a un cliente: mantenga el tráfico este-oeste privado cuando sea posible, use rutas privadas incluidas o no medidas dentro de la cuenta, elija el depósito de salida pública adecuado y adjunte conectividad directa cuando sea necesario. El cliente aún paga por el uso de internet público, pero la arquitectura le brinda controles para reducir la incertidumbre. Ese es exactamente el tipo de control que desea un comprador de estado estable.
Direct Link muestra hasta dónde puede llegar ese control. La documentación de Direct Link on Classic de IBM dice que la configuración implica una configuración básica de red y Border Gateway Protocol, con ingenieros de IBM trabajando con el cliente para habilitar la capacidad VRF (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). Dice que IBM asigna una red /31 o /30 para cada conexión en la infraestructura de enrutador de conexión cruzada de IBM Cloud, y que BGP es obligatorio para gestionar el enrutamiento a través de Direct Link (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). Las preguntas frecuentes dicen que el uso de ancho de banda a través de Direct Link entre los clientes y IBM Cloud es gratuito y no medido, mientras que el ancho de banda saliente de los servicios de IBM Cloud a internet público es medido (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). También dice que Direct Link puede proporcionar conexiones diversas, pero la redundancia se crea mediante el diseño BGP del cliente, no por un único servicio inherentemente redundante (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs).
Para un comprador que se preocupa por el aislamiento de cumplimiento, la facturación de red predecible y la conectividad privada, esa es la razón por la que IBM mantuvo el negocio de control de servidores. El servidor por sí solo no es el activo. El activo es la capacidad de combinar una máquina dedicada, direccionamiento privado, selección de VLAN, Direct Link, VRF, velocidad de puerto, opciones de redundancia y política de ancho de banda en un contrato de infraestructura. SoftLayer le dio a IBM un vocabulario para esa venta.
El aislamiento de cumplimiento es operativo, no solo contractual
El bare metal atrae a los compradores sensibles al riesgo porque les da una historia más simple sobre el aislamiento. Un servidor físico de uso exclusivo no resuelve automáticamente el cumplimiento, la seguridad o la resiliencia. El cliente todavía tiene que parchear los sistemas operativos, gestionar credenciales, cifrar datos, diseñar copias de seguridad, controlar la entrada, supervisar registros y probar procedimientos. Pero la afirmación de aislamiento comienza desde un lugar diferente: el servidor está dedicado, no se impone un hipervisor por parte del proveedor y el cliente tiene un control más directo sobre las decisiones a nivel de host.
La documentación de IBM es cuidadosa al respecto. Dice que el servidor bare-metal está dedicado al cliente y no se comparte con otros clientes, mientras que el cliente gestiona el servidor y se aprovisiona sin un hipervisor (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). También dice que algunas cargas de trabajo deben distribuirse en múltiples centros de datos y PODs para evitar un único dominio de fallo; simplemente levantar múltiples aplicaciones no es suficiente si la ubicación de implementación es incorrecta (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Esta es una advertencia operativa seria. El bare metal da control, pero el control transfiere más responsabilidad de diseño al cliente.
El aislamiento de red funciona de manera similar. El tutorial de IBM para vincular redes privadas seguras sobre la red de IBM describe la infraestructura clásica y dice que la mayoría de las cargas de trabajo se pueden implementar utilizando IBM Cloud VPC, pero luego muestra cómo las redes privadas seguras en diferentes centros de datos se pueden vincular a través de la red privada de IBM utilizando VRF o expansión de VLAN, dispositivos de puerta de enlace, enrutamiento y reglas de firewall (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Señala que no existe restricción sobre qué dos centros de datos se pueden usar, aparte del impacto de la latencia, y que las subredes privadas, los ID de VLAN, las direcciones de puerta de enlace y las reglas de firewall deben registrarse y configurarse (https://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures). Ese no es el lenguaje de una abstracción completamente gestionada. Es el lenguaje de la ingeniería de infraestructura.
Aquí es precisamente donde el modelo de SoftLayer sigue siendo útil para cuentas reguladas y con mucho control. El cliente puede construir patrones de segmentación familiares: interfaces públicas y privadas, firewalls, dispositivos de puerta de enlace, VLANs, subredes privadas, Direct Link, anuncio de red remota, BGP, copia de seguridad, transferencia privada de datos y hosts dedicados. IBM puede vender servicios en la nube sin pretender que cada carga de trabajo empresarial deba refactorizarse al mismo patrón moderno desde el primer día. El comprador obtiene un paso de migración que se siente más seguro que una reescritura completa.
La compensación es que la experiencia manual no se elimina. La documentación de Direct Link dice que los clientes son responsables de gestionar los anuncios de rutas hacia y desde la red de IBM Cloud, y que la falta de planificación del comportamiento de reenvío BGP puede crear resultados no deseados, como enrutamiento asimétrico o rutas preferidas incorrectamente (https://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link). La página de opciones de red advierte que la redundancia gestionada por el usuario requiere que el cliente sepa cómo configurar la redundancia, y que no hacerlo crea una falta de redundancia de comunicación de red durante el mantenimiento de rutina (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options). Un comprador no puede comprar un servidor dedicado y asumir resistencia. Debe operar el control que solicitó.
Esa compensación es el corazón del mercado. La nube abstracta gana cuando los clientes quieren menos decisiones de bajo nivel. La nube al estilo SoftLayer gana cuando los clientes quieren recuperar las decisiones porque la carga de trabajo, el regulador, la licencia, la ruta de latencia, el perfil de rendimiento o el plan de migración lo exigen. La ventaja de IBM es que puede vender ambas narrativas bajo una misma relación empresarial. Su riesgo es que los clientes lo castiguen si alguna de las narrativas se vuelve confusa.
La presión de sustitución de la nube nunca desapareció
La presión contra el modelo de SoftLayer es obvia: la mayoría del nuevo consumo de nube prefiere la abstracción. Los desarrolladores quieren bases de datos gestionadas, funciones sin servidor, plataformas de contenedores, almacenamiento de objetos, integración de identidad, observabilidad, servicios de IA y API regionales. Los equipos financieros quieren programas de descuento y gobernanza central. Los equipos de seguridad quieren controles estandarizados. Los equipos de plataforma quieren infraestructura que se pueda crear y destruir sin esperar pruebas de hardware. Para esos compradores, un servidor físico puede parecer una excepción.
La propia página de precios de IBM refleja esta división. El bare metal VPC se presenta como perfiles predefinidos que se implementan en 10 minutos o menos a través de una red definida por software, ideal para alta disponibilidad y máxima elasticidad (https://www.ibm.com/products/bare-metal-servers/pricing). El bare metal clásico se presenta como altamente personalizable con más de 11 millones de combinaciones y 20 TB de ancho de banda sin costo, ideal para operaciones estables y predecibles (https://www.ibm.com/products/bare-metal-servers/pricing). Eso no es una contradicción. Es IBM segmentando el mercado: bare metal VPC para clientes que quieren construcciones modernas de nube alrededor de hardware dedicado, bare metal clásico para clientes que aún necesitan la superficie de control más antigua.
La amenaza de sustitución también proviene de la transparencia de costes. Los proveedores de nube pública han hecho que los precios sean granulares, y los precios granulares pueden ayudar o perjudicar el caso del bare metal. AWS anunció que a partir del 1 de febrero de 2024 cobraría $0.005 por dirección IPv4 pública por hora para todas las direcciones IPv4 públicas, adjuntas o no, lo que hace que un año de una dirección IPv4 pública asignada continuamente cueste $43.80 antes de otros costes de servicio (https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/). Ese tipo de línea de pedido empuja a los compradores a comprender el uso de direcciones, el diseño NAT y la exposición pública. También facilita la comparación de proveedores de infraestructura dedicada que incluyen paquetes de direcciones y ancho de banda, incluso si la comparación nunca es perfecta.
Las páginas de los competidores muestran la misma presión del mercado. OVHcloud posiciona el bare metal en torno a recursos dedicados, anti-DDoS, redes privadas e infraestructura predecible para cargas de trabajo que necesitan control (https://us.ovhcloud.com/bare-metal/). Hetzner enumera servidores raíz dedicados con precios mensuales agresivos que pueden hacer que la propuesta orientada a empresas de IBM parezca cara para los compradores europeos sensibles al precio (https://www.hetzner.com/dedicated-rootserver). TrustRadius, un sitio de reseñas y comparación en lugar de un vendedor principal, enumera los servidores bare-metal de IBM Cloud con un precio inicial de $0.51 por hora y $241 por mes, al tiempo que señala opciones por hora o mes y 500 GB/mes de ancho de banda saliente en su resumen de precios (https://www.trustradius.com/products/ibm-cloud-bare-metal-servers/pricing). Esos precios de terceros deben tratarse como una señal del mercado en lugar de un contrato, pero muestra cómo los compradores comparan a IBM con alternativas más baratas y simples.
La defensa de IBM no es ser el servidor dedicado más barato. Es conectar el bare metal a la arquitectura de nube híbrida, soporte empresarial, software de IBM, estrategia Red Hat/OpenShift, conectividad directa, cuentas empresariales adyacentes al mainframe, cargas de trabajo reguladas, patrones SAP y VMware, y adquisiciones globales. La página de inversores de IBM dice que la compañía está posicionada en torno a la nube híbrida y la IA (https://www.ibm.com/investor). Su informe anual de 2025 dice que los ingresos de la nube híbrida bajo software fueron de 7.327 millones de dólares y que los ingresos recurrentes anuales de OpenShift alcanzaron los 1.900 millones de dólares a finales de 2025 (https://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf). El papel de SoftLayer dentro de esa IBM no es liderar la narrativa. Es proporcionar la opción física y de infraestructura clásica cuando la venta de nube híbrida llega a una carga de trabajo que todavía quiere el servidor.
El riesgo es que un producto mantenido por control se convierta en un producto mantenido por inercia. Si la infraestructura clásica sigue siendo valiosa porque los clientes necesitan activamente sus características, IBM puede cosechar un nicho duradero. Si permanece solo porque las migraciones son difíciles, se convierte en una carga heredada. La diferencia es visible en la calidad de uso: ¿están los clientes eligiendo el bare metal clásico para operaciones predecibles, ancho de banda privado y aislamiento físico, o están atrapados en él porque las aplicaciones y scripts más antiguos son costosos de mover? La evidencia pública no puede responder eso con precisión, pero enmarca la pregunta correctamente.
La superficie operativa es más grande que el servidor
El diseño original de SoftLayer debe entenderse como una superficie operativa: control del servidor, control de red, conexión de almacenamiento, identidad, soporte, automatización de API, facturación y ubicación de instalaciones. La documentación actual de IBM conserva esa amplitud. El bare metal puede emparejarse con almacenamiento en bloque y archivos de 20 a 12.000 GB en el momento del aprovisionamiento, aunque el almacenamiento adicional debe conectarse después de que el servidor se aprovisiona (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Los complementos del bare metal incluyen firewall de hardware, supervisión, copia de seguridad, respuesta, direcciones IP secundarias públicas y opciones de dirección IPv6 (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bm). Las opciones de red incluyen opciones solo públicas, solo privadas, interfaces privadas incluidas por defecto, selección de salida pública, selección de VLAN, selección de subred y solicitudes de direcciones IP secundarias (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
La superficie de API importa porque cambia la economía laboral. Si un cliente puede pedir, inspeccionar, reconfigurar y cancelar infraestructura mediante programación, el servidor físico se convierte en parte de un sistema de operaciones más grande en lugar de un ticket único. La documentación de la API del servidor virtual de IBM dice que la API de SoftLayer impulsa muchas funciones de la consola de IBM Cloud y puede automatizar todas las partes del entorno de IBM Cloud accesibles a través de la API (https://cloud.ibm.com/docs/virtual-servers?topic=virtual-servers-api-reference). La SoftLayer Development Network expone SDKs para Python, Java, Go, Perl, PHP y Ruby, así como un complemento de infraestructura clásica para la CLI de IBM Cloud (https://sldn.softlayer.com/). Esa es una base instalada profunda de comportamiento de herramientas.
El plano de control, sin embargo, también fija expectativas. Un script empresarial de larga duración puede asumir nombres de objetos particulares, comportamiento de métodos, patrones de autenticación, códigos de ubicación, convenciones VLAN o comportamiento de elementos de facturación. Una nota de lanzamiento de API en 2026 que elimina métodos de servicio obsoletos es un evento de mantenimiento normal, pero para una plataforma antigua aún puede ser importante para los clientes (https://sldn.softlayer.com/). Todo negocio de infraestructura maduro tiene este problema. Cuanto más poderosa es la superficie de control, más se convierte en parte del propio código operativo del cliente.
Las instalaciones y el enrutamiento añaden otra capa. La página pública de PeeringDB muestra AS-SOFTLAYER y una política de peering público que es selectiva, prefiere múltiples ubicaciones, no tiene requisito de ratio ni requisito de contrato (https://www.peeringdb.com/net/1613). Las capacidades de intercambio enumeradas en la página incluyen 200G en DE-CIX Dallas, 200G en DE-CIX Frankfurt, 200G en DE-CIX Madrid, 100G en DE-CIX Chicago, 80G en Equinix Ashburn, 60G en Equinix Chicago, 60G en Equinix Miami, y enlaces más pequeños en muchos otros intercambios (https://www.peeringdb.com/net/1613). Esas cifras no prueban la satisfacción del cliente ni los ingresos. Muestran la huella de enrutamiento que respalda una plataforma de infraestructura global.
Esa huella es tanto activo como coste. Los puertos de intercambio, las conexiones cruzadas, la capacidad del enrutador, la política de rutas, la ingeniería de tráfico, el manejo de abusos, la respuesta DDoS, las ventanas de mantenimiento, los compromisos de coubicación y la ingeniería de redes no se monetizan por sí mismos. Importan cuando evitan que los clientes se vayan. Un cliente con una carga de trabajo estable, requisitos BGP, conectividad privada y tráfico predecible puede ser pegajoso porque mudarse no es solo una migración de servidor. Es una migración de red y operaciones.
Es por eso que la economía de SoftLayer encaja mejor en IBM que en una empresa de alojamiento de bajo costo puro. IBM puede adjuntar infraestructura de control de red a una cuenta empresarial más amplia. Puede vender consultoría en torno a la migración y modernización. Puede conectar el bare metal a Red Hat, VMware, SAP, integración de IBM Z, postura de seguridad y servicios gestionados. El servidor dedicado no es entonces toda la historia del margen. Es el ancla que mantiene una carga de trabajo particular dentro del límite de cuenta de IBM.
La evidencia también muestra lo que no se puede saber públicamente
La evidencia pública es sólida en identidad, superficie de red, historial de adquisiciones, mecánica del producto y postura de precios. Es débil en los aspectos financieros actuales específicos de SoftLayer. IBM no revela los ingresos de SoftLayer, la utilización del bare metal clásico de IBM Cloud, el margen bruto por centro de datos, la rotación por clase de carga de trabajo, el coste de soporte por servidor, el porcentaje de cargas de trabajo clásicas convertidas a bare metal VPC, la economía del inventario IPv4 o los ingresos reales adjuntos de Direct Link, soporte, almacenamiento, copia de seguridad y complementos de seguridad. Eso significa que cualquier valoración debe ser conservadora.
El número más importante que falta es la utilización por clase de hardware y ubicación. Una plataforma bare-metal puede parecer saludable si la red principal es grande y la página de producto es amplia, mientras que aún lleva bolsas de hardware varado. Las generaciones de CPU más antiguas pueden ser baratas de vender pero costosas en eficiencia energética. Las configuraciones de alta memoria o preparadas para GPU pueden tener mejores precios pero requieren una adquisición cuidadosa. Algunos mercados pueden tener una fuerte demanda de conectividad privada y ancho de banda predecible; otros pueden requerir descuentos. Las páginas públicas muestran la amplitud del producto, no la tasa de ocupación.
El segundo número que falta es el flujo de migración. Las páginas de productos de IBM ahora distinguen entre bare metal VPC e infraestructura clásica. Una estrategia racional de IBM movería a los clientes hacia construcciones más nuevas cuando fuera posible, preservando el control clásico cuando fuera necesario. Pero sin una métrica de migración pública, los lectores externos no pueden saber si el bare metal clásico está creciendo, estable, reduciéndose gradualmente o retenido principalmente para cuentas antiguas. Los materiales de inversores de IBM enfatizan la nube híbrida, Red Hat y la IA más que la infraestructura clásica (https://www.ibm.com/investor/services/annual-report). Eso no significa que el bare metal clásico no sea importante. Significa que su importancia es operativamente específica en lugar de estratégica de titulares.
El tercer número que falta es la calidad del soporte. Los clientes de bare metal juzgan al proveedor cuando algo físico se rompe o una ruta cambia. La documentación de IBM advierte que los fallos de hardware, los errores de software, los problemas de red y el mantenimiento pueden causar interrupciones, y que es necesario distribuir las aplicaciones en múltiples centros de datos y PODs para la disponibilidad (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Eso es técnicamente honesto. Pero los clientes aún experimentan el fracaso a través de la respuesta de soporte. Las páginas de producto públicas no pueden decirnos si el soporte de IBM es lo suficientemente rápido en el momento en que falla una unidad, una VLAN se comporta mal, una ruta de Direct Link es incorrecta o un servidor solo privado se pidió incorrectamente.
El cuarto número que falta es el coste de abuso y reputación. Las redes de alojamiento atraen cargas de trabajo empresariales legítimas, pero el espacio IP público y los servidores dedicados también atraen spam, scraping, actividad de bots, infraestructura de phishing y revendedores de alto riesgo. Los registros de PeeringDB y BGP prueban la escala; no prueban la calidad de la reputación. La postura de control de red, los procesos de soporte y la gestión de direcciones de IBM importan aquí porque un rango de direcciones sucio o un incidente de abuso repetido puede hacer que un servidor barato sea costoso. La evidencia pública no nos permite puntuar eso directamente.
Estas incertidumbres no deben tratarse como defectos del artículo. Son la economía. El registro público nos dice por qué IBM mantendría un negocio de control de servidores. No nos dice si cada rack, generación de CPU y cohorte de clientes obtiene rendimientos atractivos.
Lo que un comprador suscribiría hoy
Un gran comprador que decida si colocar cargas de trabajo estables en bare metal de IBM Cloud suscribiría un conjunto de hechos diferente al de un desarrollador que elige una instancia virtual. Comenzaría con la identidad y la continuidad: SoftLayer fue adquirida por IBM, el producto actual es IBM Cloud Bare Metal Servers, la API y los controles de infraestructura clásica permanecen documentados, y la identidad de red todavía aparece en los datos de ARIN, PeeringDB y BGP (https://rdap.arin.net/registry/entity/SOFTL,https://rdap.arin.net/registry/autnum/36351,https://www.peeringdb.com/net/1613yhttps://bgp.tools/as/36351). Luego probaría las promesas del producto: uso exclusivo, sin hipervisor del proveedor, facturación por horas o meses, aprovisionamiento rápido, 20 TB de ancho de banda clásico sin costo, inclusión de red privada, opciones de velocidad de puerto, opciones de redundancia, Direct Link, BGP, VRF y movimiento privado de datos (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-optionsyhttps://cloud.ibm.com/docs/direct-link?topic=direct-link-configure-ibm-cloud-direct-link).
El comprador también probaría el comportamiento ante fallos. Si una carga de trabajo necesita disponibilidad continua, la propia documentación de IBM dice que se deben considerar múltiples servidores de aplicaciones y la distribución en centros de datos y PODs (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr). Si un comprador quiere un servidor único de menor coste sin enlace redundante, debe aceptar que el mantenimiento de rutina puede interrumpir la comunicación. Si el comprador quiere Direct Link, debe entender que la redundancia se crea a través del diseño BGP y conexiones diversas, no solo por la existencia de un servicio (https://cloud.ibm.com/docs/direct-link?topic=direct-link-faqs). Si quiere una implementación solo privada, debe decidirlo en el aprovisionamiento porque no se puede agregar una interfaz pública más tarde a un servidor solo privado (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-network-options).
Un prestamista o adquirente haría las preguntas más difíciles que IBM no publica: ingresos recurrentes por cohorte, utilización por ubicación, antigüedad del hardware, coste de energía del centro de datos, volumen de tickets de soporte, ingresos por exceso de salida pública, coste de red privada, tasa de conexión de Direct Link, conexión de almacenamiento y copia de seguridad, concentración de clientes, tasa de renovación en plazos contractuales y el número de cuentas que aún dependen del comportamiento anterior de la API de SoftLayer. Separaría la demanda saludable impulsada por el control de la demanda heredada impulsada por la inercia. La primera merece inversión. La segunda merece planificación de migración y protección de márgenes.
A un regulador le importarían las afirmaciones de control y la claridad para el cliente. El bare metal puede ayudar con el aislamiento, pero solo si los clientes entienden qué obligaciones siguen siendo suyas. La documentación de IBM es explícita en que el cliente gestiona el servidor y que las copias de seguridad de los dispositivos del cliente no las completa IBM a menos que el cliente inicie copias de seguridad programadas o únicas a través de las soluciones pertinentes (https://cloud.ibm.com/docs/bare-metal?topic=bare-metal-about-bmyhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-sm-back-up-recovery). Un comprador sensible al cumplimiento debe leer eso cuidadosamente. El uso exclusivo no es cumplimiento gestionado. Es un punto de partida físico y operativo.
La conclusión de suscripción es equilibrada. SoftLayer le da a IBM una superficie de control creíble para cargas de trabajo que no encajan perfectamente en la nube abstracta. La evidencia pública respalda una red real, continuidad real de API, mecánica de producto real y relevancia real de nube híbrida. Pero la evidencia pública no respalda una afirmación simple de que SoftLayer, como nombre heredado, sea un motor de crecimiento por sí solo. Su valor está integrado: control del servidor dentro de IBM Cloud, útil cuando el cliente quiere la nube sin perder la máquina.
Registro de evidencias para las afirmaciones públicas
La evidencia de la adquisición y la escala histórica proviene del anuncio de adquisición de IBM, el anuncio de cierre de IBM, el anuncio de venta de GI Partners y el informe del Los Angeles Times sobre el valor del acuerdo reportado de 2.000 millones de dólares: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-ibmyhttps://www.latimes.com/business/technology/la-fi-tn-ibm-cloud-computing-softlayer-2-billion-20130604-story.html.
La evidencia actual de la red e identidad proviene de ARIN RDAP, PeeringDB, la vista API de PeeringDB y 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=2yhttps://bgp.tools/as/36351.
La evidencia del producto bare-metal y precios proviene de la página de precios de bare-metal de IBM y la documentación de bare-metal de 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-recoveryyhttps://cloud.ibm.com/docs/bare-metal?topic=bare-metal-ha-dr.
La evidencia de API y plano de control proviene de las referencias de API de IBM Cloud y la 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-apiyhttps://sldn.softlayer.com/.
La evidencia de conectividad privada y VLAN proviene de la documentación de Direct Link y VLAN de IBM Cloud: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-exchangeyhttps://cloud.ibm.com/docs/vlans?topic=vlans-linking-secure-network-enclosures.
El contexto estratégico y financiero de IBM proviene de la página de inversores de IBM y el informe anual de 2025:https://www.ibm.com/investor,https://www.ibm.com/investor/services/annual-reportyhttps://www.sec.gov/Archives/edgar/data/51143/000005114326000027/ibmars2025.pdf.
La evidencia de sustitución y comparación de mercado proviene de los precios de IPv4 pública de AWS, bare metal de OVHcloud, servidores raíz dedicados de Hetzner, resúmenes de precios de bare-metal de IBM en TrustRadius y la discusión de Hacker News de 2013 como una señal informal del mercado de desarrolladores: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/pricingyhttps://news.ycombinator.com/item?id=5819227.
Conclusión y puntos a vigilar
La lección perdurable de SoftLayer es que la nube no abolió el servidor. Cambió cómo se compra, conecta, automatiza y financia el servidor. IBM mantuvo la lógica de control de servidores de SoftLayer porque algunas cargas de trabajo empresariales todavía necesitan aislamiento físico, ancho de banda predecible, enrutamiento privado, ubicación conocida y opciones operativas de bajo nivel. El hecho de que IBM ahora se comercialice principalmente en torno a la nube híbrida y la IA no debilita ese argumento. Lo hace más preciso. La nube híbrida necesita lugares donde la infraestructura antigua y la nueva puedan encontrarse, y el diseño de SoftLayer le da a IBM uno de esos lugares.
El caso positivo es que IBM puede seguir monetizando el legado de SoftLayer como una opción de infraestructura de alto control: bare metal clásico para operaciones estables y predecibles, bare metal VPC para patrones de nube más nuevos, Direct Link para conectividad privada, continuidad de la API de SoftLayer para la automatización existente y las relaciones de cuentas empresariales de IBM para cargas de trabajo que no pueden ser atendidas solo por alojamiento de bajo costo. Las cifras que respaldan este caso son 13 centros de datos originales, 100.000 dispositivos, 21.000 clientes, una adquisición reportada de 2.000 millones de dólares, 1.800 prefijos IPv4 de PeeringDB, 450 prefijos IPv6, entre 1 y 5 Tbps de tráfico de PeeringDB, más de 11 millones de combinaciones de configuración clásica, 20 TB de ancho de banda sin costo en clásico, implementación de bare metal VPC en 10 minutos o menos y aprovisionamiento rápido de 30 a 40 minutos para servidores clásicos.
El caso negativo es que el control puede convertirse en una carga. Si la infraestructura clásica se mantiene principalmente porque las cargas de trabajo más antiguas son difíciles de mover, IBM debe proteger el margen mientras arrastra soporte heredado, comportamiento antiguo de API, renovación de hardware, reputación de direcciones, complejidad del centro de datos y expectativas del cliente. Si los proveedores de bare metal más baratos presionan las cuentas de productos básicos y los hiperescaladores absorben cargas de trabajo de alto nivel en servicios gestionados, IBM debe seguir demostrando por qué su capa de control de servidores pertenece a una relación premium de nube híbrida.
Los puntos a vigilar son concretos. Primero, observe si IBM continúa mejorando tanto el bare metal VPC como el bare metal clásico, en lugar de dejar que uno muera de hambre silenciosamente al otro. Segundo, observe si los controles de Direct Link, VRF y red privada se vuelven más fáciles para los clientes sin perder transparencia. Tercero, observe los cambios en el enrutamiento público y PeeringDB en torno a AS36351, porque muestran si la red sigue siendo amplia y actual. Cuarto, observe los precios de IPv4 y la política de direcciones en toda la industria, porque la escasez de direcciones públicas puede fortalecer el caso de los proveedores con asignación disciplinada y ancho de banda incluido. Quinto, observe los informes anuales de IBM en busca de cambios en el énfasis de infraestructura, nube híbrida y Red Hat, porque el valor de SoftLayer está cada vez más vinculado a lo bien que IBM empaqueta el control físico con la estrategia de software.
SoftLayer no es la cara de la IBM moderna. Ese es el punto. Es la parte de IBM Cloud que todavía responde a un comprador obstinado con una necesidad obstinada: deme la conveniencia de la nube, pero no haga desaparecer el servidor.