Wait, that’s not quite the story I want to tell.

The story I want to tell is that a long time ago, I decided to have my own website, and not long thereafter, I decided to do a podcast or two, mainly to see if I could. (It turned out that I could.)

Uh-oh.

The problem is that most html and css files are kilobytes in size, whereas media files are megabytes in size—three orders of magnitude larger. Most servers are really good at dealing with large numbers of small files, as opposed to small numbers of large files. Hence the need for a better way to host these large media files that wouldn’t overburden my webserver. The solution is use a CDN—a content delivery network—that is designed to handle such files.

I’ve tried different possibilities for this—for a while I used wordpress.com as a kind of impromptu CDN server, and even earlier, I just threw them into a subdomain because they were easy to manage via ftp. (Although there is no fun uploading an 80 MB mp3 file via ftp on a dial-up modem. Those were the days, my friends.)

The point of a CDN is that you can set it up to be really good at dealing with large files that are served up in small numbers (such as video and audio files) or to be really good at dealing with small files that are served up in large numbers. Additionally, because CDNs can serve files from various points around the world (your files are stored on redundant servers), using a CDN can really speed up your website for visitors all across the world. Ultimately, I settled on DreamHost’s DreamObjects cloud-based solution. Sadly, DreamHost actually did this really well, until it suddenly decided fuck over its customers go another route with this service (and suddenly deciding to not do things is not an uncommon occurrence with DreamHost), so I have been forced to look elsewhere.

I tried out a number of different services (all on my own time, with nary a billable hour in sight—thank you, DreamHost, for throwing my P&L far into the red) but finally settled on the granddaddy of them all: AWS, aka Amazon Web Services.

This was not an easy decision to come to. AWS is multilayered and complicated to navigate (they provide a lot of different services to large number of very different clients) and their interface is complicated until you get used to it, but all of that is also their strength—they have a large customer base, and it’s in their own best interest not to upset them by actually knowing what they are doing.

Anyway, this has been my life lately—transferring a lotta buncha files over to AWS servers. Like I said, learning the AWS interface has taken a bit of time, but the advantages of AWS far outweight the disadvantages. There have been some bumps here and there, and while I’m fairly certain that everything is finally good, I’m not entirely sure. I’ll be spending most of this weekend verifying that everything is as it should be. If you do find something missing, please let me know about it via my contact form. I will really appreciate it and I’m sure anyone else visiting my website will, as well.

How Not to Run a Business

We now come to something that I’ve been trying to write about for a long time, but because it makes me really sad to think about it, I’ve had difficulty finding a way into it. I am simply all over the place emotionally on this issue, and I still don’t have a really good handle on it, but here goes.

I used to host all my sites at DreamHost (there is a long story behind why this is no longer the case; this piece is a part of that story). I eventually switched to WebFaction for hosting (with much rejoicing), but I continued to use DreamHost’s cloud solution (called, natch, DreamObjects). I did so for three reasons:

1. It was a great place to securely store backup files. (It still is, actually.)
2. It made for a great CDN, meaning that I could use it to host media files (such as podcasts and videos) and keep the strain off my webserver.
3. Because it’s based on AWS architecture (hello, buckets!), I could use the command line tool s3cmd to upload files and manage their permissions.

Additionally, it could handle CNAME entries as aliases. That means that instead of a file address like this:

http://someweirdnonsensicalservernameXp43lkj8932oasd08a0983.dreamhost.com/my_podcast.mp3

I could simply have

http://cdn.kjodle.net/my_podcast.mp3

which is not just easier to remember, it’s also a lot more professional looking. (Also, it replaces my host’s domain name with my own.) Slick, huh? In fact, what was interesting was that I could assign multiple CNAME aliases to each bucket. So a single file in a single bucket could be found under multiple addresses, such as:

cdn.kjodle.net/my_podcast.mp3
archive.kjodle.net/my_podcast.mp3
media.kjodle.net/my_podcast.mp3

I’m not sure how this is useful at all. If anything, it muddies the waters quite a bit, and DreamHost really had no advice or information about why this would be an advantage. Perhaps that should have been a clue to me that DreamHost really had not thought this product through very thoroughly. Let’s call that warning sign #1.

Anyway, at some point they announced that they were changing the name of the objects server, which meant that if you were using this service as a CDN, you’d need to update all your links. Fortunately, because I had set up CNAME aliases for all my buckets, I was in the clear on this one. I patted myself on the back for my foresight and cleverness (something I had no right to do) and moved on. This was, of course, warning sign #2.

Flash forward to a year ago. DreamHost announces that they are ending CDN support. I forget what the timeline was, because for reasons I don’t undersatnd, DreamHost either does thing more or less immediately—within thirty days of announcing them (conveniently forgetting that most of us have families and jobs and responsibilities and lives, and can’t just drop everything to deal with one of their sudden mood swings) or sets a date for completion so far out in the future that their customers, and sometimes Dreamhost itself, forgets all about it, at least until Skippy the intern dusts off an ancient memo, sees that Order 66 has not yet be executed, and decides to push the Big Red Button, throwing DH customers and staff into utter turmoil.

Anyway, DreamHost put the kibosh on CDN support. I jumped on the support forum to inquire why, as the reason provided in their email was a bit vague. I was a little suprised to get a response (DreamHost does not handle criticism well), but pleased. The response was slathered with jargon jam, but if you read between the lines, the answer boils down to “not enough people bought this product, and the only way to make it profitable would be to raise prices higher than what the market would bear.” For the record, I am totally okay with this. It was a business decision, pure and simple, albeit, couched in technical terms. I completely understand that if you have an unprofitable product that is not a loss leader (i.e., you lose money on this, but it brings in so much other profitable business that you’re okay with that) the best option is to no longer sell that product. As a businessperson, I’ve made these types of decisions myself. They aren’t fun, but they are stress-relieving.

My next question was “will the aliases that we assign to a bucket still work?” If you read the rest of that thread, you can see that the answer was an unequivocal “yes”—DreamHost would grandfather support for them. You wouldn’t be able to create new ones but your old ones would continue to work. Again, that was fine by me, as I had already created all the CNAME aliases I’d needed to create.

All was good for a while, but this is merely the intermission.

Fast forward to 2018. DreamHost has news for us.

The TL;DR is that DreamHost is shutting down the west coast that had hosted DreamObjects and starting up an east coast cluster. More importantly, DreamHost will not be able to transfer your data for you—that’s all on you, the user.

This is frustrating for two reasons.

First, DreamHost never provided a reason for this move. In my experience, you can do pretty much whatever you want to customers as long as you provide a fairly good reason for your actions. DreamHost, of course, remained silent on this issue. But really, any of the following reasons could have made people happy:

1. The west coast cluster has been invaded by squirrels.
2. The west coast cluster has been invaded by squirrels, and they all have lasers! Lasers, I tell you! It is carnage over here!
3. The west coast cluster has burnt to the ground and the only reason you can still access your files is because Skippy the intern has then all backed up on 1.4″ floppy disks in his parents’ garage. But the garage is full, so it’s time to move on.
4. We have no idea what we’re doing because we’re all just squirrels.

Second, if you, as a business, are going to disrupt service to your customers in some way, you really should make it as painless as possible. The obvious message they should have put out was

Hey, we’re going to shut down our west coast cluster and start a new east coast cluster. We’re going to do our best to transfer your data over for you, but it might be bumpy—there might be times when your data isn’t available and we can’t guarantee that all of it will make it over intact. This is a great time to make sure all your data is backed up.

When the transfer is complete, we’ll let you know, and also provide a tutorial showing you how to verify all your data made it over.

Instead, DreamHost said, in a nutshell, “You’re fucked, mate.”

Third, I did manage to transfer all my data over. It took a couple of hours, which is quite reasonable, considering the amount of data I was transferring over. But a few weeks after transferring my data, I checked to find a file I had misplaced and thought I had possibly uploaded to one of my buckets. It wasn’t there—and neither was anything else. It was all gone. 

Good thing I had downloaded all those buckets to my local machine before I made that transfer.

TL;DR

DreamHost used to be a great company if you wanted to host a simple website. It still is, as a matter of fact. I use both them and GoDaddy for hosting my company’s website and employee portal, and the DH site blows the GD site away in terms of sheer performance.

But DreamHost really sucks at doing anything else. They get excited about it, promote the hell out of it, get you to sign up for it, fail to support it properly, and then lose interest and drop it. The other thing they seem to do well—DreamPress, which is managed WordPress hosting—is not something I’m interested in.

If you want a simple site, DreamHost is not a bad option. But if you want a real CDN server, go with a real CDN server. Don’t get sucked into anything else that DreamHost offers, because my experience has been that they lose interest and you, the customer, get screwed.

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.