SoftLayer made the cloud a place you could touch

A cloud is a peculiar thing to buy. You pay for something whose appeal is partly that you do not have to see it. Somewhere, a computer does the work. Somewhere else, someone changes a disk. SoftLayer made a different offer: choose the machine, keep control of it, and let software handle the business of getting it ready.

That distinction helps explain why IBM bought the Dallas company in 2013. SoftLayer sold infrastructure as a service, or IaaS: the computers, storage and networking on which other people’s applications run. Its menu included virtual servers and entire physical servers reserved for one customer. The latter were called bare metal. The metal, naturally, came with a considerable amount of software.

The machine was allowed to matter

Cloud discussions often begin with abstraction. A developer asks for computing capacity; the provider supplies it; the physical arrangement becomes somebody else’s concern. There is a great deal to recommend that bargain. But an abstraction is useful only while the details it conceals remain unimportant.

A database can care about disk performance. An interactive game can care about memory and response times. A business running its own virtualisation software can care about access to the underlying server. SoftLayer left room for those preferences. A customer could select dedicated hardware, use virtual instances, or assemble a private environment rather than accept a single model of computing.

Its expertise sat at the intersection of hardware procurement, network engineering and software automation. Intel’s 2010 case study describes SoftLayer working with processor road maps and deploying Supermicro systems. Better density meant more work per rack; energy efficiency helped restrain power and cooling costs. The cloud might arrive on a credit-card bill, but the supplier still had to manage floor space.

For the customer, the attraction was control without ownership of the building. You could host an application, build a database cluster or run your own software environment while the provider supplied the physical infrastructure. That was especially useful when performance depended on a particular configuration. It also left the customer with decisions to make. A menu of hardware is helpful only if somebody knows what to order.

Three roads into the same building

SoftLayer’s architecture separated public networking, private networking and out-of-band management. Each served a different job. Public connections carried internet traffic. Private connections linked infrastructure. The management network provided a route for administration separate from application traffic.

Think of a restaurant with a front door, a delivery entrance and a service corridor. Making every person and every crate use the front door might look economical on a floor plan. During dinner, the saving becomes less impressive. Separating traffic is a design choice about what happens when the building gets busy.

The other crucial connection was between the customer interface and the automation underneath it. SoftLayer’s API documentation says the customer portal was built on the same API set supplied to customers. A task available through the interface could become part of a customer’s own programmatic workflow.

This is the most portable lesson in the company’s story. Build the interface your staff use on the capabilities you offer customers. It makes repeated work easier to automate and puts pressure on the product to be usable without a succession of favours from the operations team. The glamorous purchase is a server. The valuable purchase may be the absence of a queue.

Cash ran out before ambition did

SoftLayer began in 2005 with Lance Crosby and former colleagues. In a 2015 retrospective, Crosby described an early team struggling to turn its ideas into a workable product. Financial pressure forced a launch before the engineers considered the service finished. He also recalled expensive borrowing and money contributed by employees.

The lesson needs editing before anyone copies it. Shipping a bounded product can produce feedback and revenue; pressuring employees to risk personal savings is a different proposition. By Crosby’s account, concern about competing at greater scale later helped persuade him to seek a sale. Growth alone did not settle the question of independence.

GI Partners and management acquired SoftLayer’s equity in 2010. The subsequent merger with The Planet supplied another route to scale: combine businesses that already owned infrastructure and served customers. By the time of the IBM sale, GI Partners reported more than 21,000 customers in over 140 countries, with 13 data centers and more than 100,000 servers, firewalls and load balancers. Those are acquisition-era figures, not a description of today’s footprint.

IBM bought a bridge to its customers

IBM’s acquisition announcement paired SoftLayer’s speed and self-service approach with its own enterprise cloud portfolio. The fit was fairly legible. SoftLayer had experience with businesses built around the internet. IBM had established enterprise relationships and a wider range of software and services to bring to them.

The combination also offered a bridge between dedicated and shared infrastructure. A large organisation could have applications with quite different requirements: one suitable for virtual machines, another requiring dedicated equipment, another connected to systems it still operated itself. Selling one infrastructure model to all three would make the catalogue tidy and the customer’s life complicated.

In 2014, IBM named customers including Whirlpool, Macy’s and Daimler subsidiary moovel. Whirlpool wanted a scalable environment for ecommerce and substantial customer and product data. These examples matter because they explain the market beyond the phrase “enterprise cloud.” The buyer had an application to run and practical constraints around it.

IBM also announced a $1.2 billion global expansion investment in 2014. Acquisition and expansion are different expenditures: one bought an existing business, the other supported a broader footprint. Neither number tells a customer what next month’s server bill will be.

The price tag has several moving parts

SoftLayer’s business model was infrastructure rental. Hourly and monthly billing let customers obtain capacity without buying and installing every machine themselves. Today, IBM Cloud’s successor offerings still have those billing choices, but a single universal “SoftLayer price” would be misleading.

A useful quote begins with the configuration and location. Add software licensing, storage, public data transfer and any optional services. Then ask how long the resource will remain provisioned. An hourly rate can look small while a machine quietly waits all weekend for Monday’s work.

Networking makes the comparison particularly interesting. IBM’s Classic bandwidth documentation says transfers between Classic virtual or bare metal servers within the same account incur no charge when they use the Classic private network. Public outbound traffic follows allocations and regional overage pricing. The route the data takes can therefore change the economics.

Dedicated hardware can suit sustained, predictable work that makes good use of the machine. It is less attractive when demand is tiny, intermittent or difficult to forecast. A whole server gives you control over its capacity; it also gives you unused capacity to pay for. Benchmark the actual application and estimate its utilisation before admiring the hardware specifications.

Alternatives include AWS, Microsoft Azure, Google Cloud and specialist hosting providers. Compare them at the level of the application: required services, operating effort, networking and recovery design. SoftLayer’s historical distinction does not establish a universal performance or price advantage over those alternatives today.

A retired name with a working interface

The branding moved through Bluemix and into IBM Cloud. The technical inheritance is easier to follow than the names. IBM’s documentation distinguishes Classic infrastructure, which uses the SoftLayer API, from VPC infrastructure, which uses a different, modern REST-based API. Choosing between them is an architecture decision, not a spelling preference.

There is also contemporary evidence of maintenance: SoftLayer’s March 2026 API notes record removal of deprecated methods. Older integrations need attention as interfaces change. The surviving name does not mean every historical feature or script remains available forever.

“We were cloud before cloud was cool.”Lance Crosby, speaking to InfoWorld in 2013

SoftLayer’s enduring contribution was to treat physical infrastructure as something customers could operate through software. For a business facing a stubborn workload, that remains a useful idea. Decide which hardware details matter, automate the repeated work, and count the full cost of keeping the application running. The cloud still has cables. A good service makes them somebody else’s daily problem.