Two of the biggest advantages were:

Price for hardware. As a base price, their bare-metal gear was significantly cheaper than equivalent-specced AWS gear (if it was even possible to get something like that). We managed to snag quite a few 'interesting' configurations of things at various times that you just couldn't get at all in AWS. Things like PCI SSDs, very large RAM configs, or High-Frequency low-core count CPUs.

Free international/regional transfer. We took significant advantage of this to move data around. We'd replicate TBs of data around.

At various times management and dev teams would complain and say that we should move everything to AWS (or whatever cloud provider they'd just met with at a conference).

We consistently showed higher performance and lower cost by significant margins. On cost alone, we were paying a small fraction of what it'd cost on AWS, even after taking into consideration ways to reduce cost on AWS such as scaling, spot instances and reserved-instances.

I think the biggest issue is that far too many people assume that the AWS Savings stories are universally applicable, and that it's safe to assume AWS is going to be the cheap option.

I'm sure there are folks for whom AWS is the cheap option, but it wasn't at my last job, and it's not for my current one (even though they are using it).

A cynic might argue that is why their pricing structure is so complicated in the first place.

We had a couple thousand bare metal servers, and barely used any of their API stuff.

As with any facility, there were occasional issues with electrical transfer switches, core router failures, fiber cuts, etc. Stuff happens, but we got pretty good communication, and things got resolved in a reasonable amount of time. Service got noticeably worse after IBM, but we were already planning to move to our acquirers hosting, because that's what happens when you're acquired. Oh, and their load balancers had garbage uptime.

Bandwidth prices used to be pretty reasonable, but they've adopted AWS style obscene pricing. At least they still let you use the private network for free (including to other datacenters).

I've always imagined it as a big tower shoved under someone's desk. The side panel of the case is off because otherwise it overheats. On the screen there's a single maximized window of DrRacket. A post it note warns you not to quit or reboot the system.

edit: It's possible that you could take out an entire TLD and make it impossible to resolve domains on that TLD once all the cached records expire. But that kind of targeted attack would not be possible with a BGP error, unless it was a very specifically crafted BGP error happening over a very long period of time (weeks-months-years depending on the record TTLs).

I guess I'm just calling out the people who are making fun of them for having their status page dependent on the same hardware it's monitoring when it's not clear that's the case just because they are both down?

I would suppose if it's a different TLD domain, then it would be more likely to conclude that.

I'm not going to make fun of them for their status page being down, but it certainly doesn't reflect well on the brand/products.

For us as well. It was so nice to have things work one day and the next and the next, although I guess they wouldn't have worked today.

Favorite firefighting moment was when wdc lost half the fiber in ~ 2014, and we had to move all of our traffic out, so that there was capacity. Our guy asked why we had to move? and your guy said something like 'Because if you guys move, we only need one customer to move.' :D

Apparently it was enough information for dsmcr to properly id the service though; not enough for nixgeek though, I think.

The odd thing is, for half the price I could get SL service w/10TB from a reseller, while at list price I only got 1-2TB bandwidth, and sales absolutely would not budge on that. I wonder why.

MS and Google do provide those features though.

Over the past few years we have experienced quite a few network-related outages. Not usually to this extent, more generally a failure of some piece of network gear that takes out either backend or frontend traffic from a particular data center. We seriously priced out a migration to another provider recently, but in the end what held us back was cross-AZ transfer costs on AWS. We found it would raise our operating costs significantly, so the matter was dropped.

We were much happier with the service and support we received prior to the IBM acquisition.

Currently on them because we have an OpenVPN based infrastructure that is very challenging to migrate.

Lastly the majority of our customers are in the midwest or Texas, and the proximity of their Dallas DC was a huge performance win for us.

In small and mid size organizations the CSP gave better pricing, or they help with your sales etc

In large organizations - IBM/Oracle bundle their existing products currently being paid for any way, or account managers have great relationships with decision makers , the company already has signed up big multi year deals.

This is not just IBM, it applies to GCP/Azure/AWS as well.

I also really like CouchDB which IBM Cloudant is based on.

Is that enough for me to use IBM cloud? no. not really.