We like to think our choices are unique, but honestly we go with the flow more than we’d like to acknowledge.
When I began doing websites, they we all statics. A bunch of jpegs, swfs and html files. Putting a site live was simple, the server requirements were minimal. My first hosting provider seemed like a real find: a US$7,95 / month plan that included a reasonable disk space, bandwidth and 20 domain names. At first I was a bit overwhelmed by the Control Panel. It was a c-panel and after a couple of days I was getting around along with it fine. To me it seemed as straight forward as it should be: want an email address? Click on “new email”, fill in it’s name, a password and your done. I couldn’t imagine the maze of config files, program, dependencies and permissions that apparent simplicity hid so well. Life was good.
With time the limitations became apparent. The websites became more dynamic, I needed more flexibility: a database, php and maybe a few one click installs (blogs, wikis and so forth). I kept running into DreamHost. The features were unbelievable and I signed up. I hosted quite a few clients with them, and I was pretty satisfied. In fact, if it’s features are enough for your, the bang for the buck DreamHost provides are incredible. All was good. Then I started to get into django. Dreamhost could host django apps through fcgi. I was happy. But it’s performance was mediocre at best and every once in a while the app would hang. After sometime, it was clear it wasn’t good enough for django apps. Time to move along.
Then I came across TextDrive. It looked perfect: afordable and built for developers. The user base was knowledgeable and extensive. Ssh to get anything done. It was scary at first. Great. But it’s shortcomings became apparent pretty soon. The lighttp setup wasn’t stable enough and no root access became a bummer. Besides, since a lot of their costumers were developers, every now and then someone would make the server crash. Combined with long fchecks and the uptime wasn’t too good. Looking back, it wasn’t an especific TextDrive issue. As other alternatives to php and perl became more main stream (python, ruby), the deployment solutions weren’t very established. It was easy to code apps that leaked memory. It was too restricting not having much control over servers and installed software. For the developers a bit more to the edge of web dev, a vanilla shared server wasn’t enough. At any rate it was time to move along once again.