It’s been over a month since I opened my account with Mosso, Rackspace’s cloud hosting division. Overall, I’ve been very happy with my decision – but there are a few things you may want to be aware of if you’re considering switching.
These issues are not deal-breakers, and most restrictions can be easily worked around – but it took me some digging to find the answers, so I figured I’d post them here in case any of you are running into the same challenges.
These are not criticisms of Mosso – merely a head’s up on Mosso-specific configurations that may be confusing for folks in the process of switching. Workarounds for all of the challenges are posted here.
I’ll keep adding to this list – and I invite you to add your own in the comments. I’m still migrating sites, although I have the bulk of the heavy-duty ones moved already. (I was moving around 170 sites, so I took my time moving things so I could adequately troubleshoot and QA.)
No SSH
This isn’t news – I mentioned it my previous article, and they make no secret about not currently offering SSH (although it sounds like they’re working on possibly making it available.) They do offer SSHFs right now, and surprisingly, I have not run into any situations where not having ssh has been terribly prohibitive.
If you have large databases to import when migrating a site, the process is very easy. Export your current database, upload it to Mosso, and jump onto Live Chat from your admin panel. Just give the tech on duty the location of your sql dump, and your database credentials (the chat is SSL-encrypted), and they’ll import it for you. I’ve had to do this at least 10 times now, and each time, the tech has taken care of the import immediately with no wait time at all.
Quota on Mail Accounts
The default quota on email is 1GB per domain. While this is more than enough for many people, I have some IMAP accounts with tens of thousands of messages. Good news: all you have to do is hop onto support chat and they will increase your mailbox quota to whatever you wish.
Cron Jobs Require Output Email
If you don’t need any cron jobs, this one won’t affect you in the least – but if you do, this can be a bit of a pain. When you set up a cron job through the admin, they require an email as the destination for an output message, even if your cron doesn’t have any output upon success. No big deal if your cron runs daily or weekly, but I have a few that run every 5 minutes – you can imagine how quickly I’d fill up my mailbox at that rate.
The solution here is pretty simple – create a specific email account for cron job output, like <crondump AT yourdomain DOT com>. Then, in your webmail account, set up a filter that automagically deletes them, so you don’t eat up server space.
No Email Migration Scripts
In general, this isn’t a big deal. If you use IMAP, the easiest – although not particularly elegant – solution is to have your old server account and your Mosso account set up in the same email program, and copy the messages from old to new.
I’m not going to lie – for someone like me, with hundreds of thousands of messages to move, this is a bit of a pain in the ass – but you only have to do it when you first set things up, so it’s really not that bad. Set Thunderbird up to move the messages right before you go to bed, and all will be right with the world when you wake up in the morning.
If you’re using POP3, the email messages are stored on your computer, so there’s no need to really do anything special. I recommend having both POP3 accounts (old and new) set up for the 48 hours after you flip DNS, just in case some sender’s ISPs are a little slow to clear their DNS cache, but after the 48 hours propagation time is up, you should be able to safely delete the old POP3 account.
30-Second Script Timeout
This shouldn’t come up in most situations, but if you have a script that takes longer than 30 seconds to finish executing, the load-balancer will return a “No suitable notes available” error. If Mosso is having issues, you’ll also see this same error, but your own scripts can trigger it if they are taking too long to finish. The solution that Mosso suggests (even in annoyingly inappropriate applications) is to employ a “loading” bar that keeps the connection alive with the server, so the load-balancer doesn’t give up on the request. Obviously, this is not always going to be an adequate solution, but shorter script timeout limits are something to keep in mind when deciding if Mosso will be a good fit.
Generally speaking, your scripts probably shouldn’t be taking over 30 seconds to execute, unless they are specifically designed to do some seriously heavy-lifting – in which case they are probably home-grown scripts and could be modified with a loading bar or similar device to work around the limitation.
Unconfirmed: Issues with Facebook Applications That Use IFRAME
I don’t know whether or not this truly is an issue, since all of my Facebook applications are written in FBML, but one user on the Mosso forums has reported an issue retaining the Facebook API session on Mosso’s servers. I suggested appending the fb_session code to the IFRAME src, which he says he did, but I cannot confirm whether he did, or whether something else is wrong with his app. This is just something to keep in mind, and perhaps something to test during your trial month if this is important to you.
Tip: Dead-End Bandwidth-Eating Bots
While Mosso gives you a considerable amount of bandwidth, and their rates if you go over are reasonable, you may wish to consider setting up your .htaccess file to dead-end known bad bots and spiders. From an article on Javascript Kit:
The definition of a “bad bot” varies depending on who you ask, but most would agree they are the spiders that do a lot more harm than good on your site (ie: an email harvester). A site ripper on the other hand are offline browsing programs that a surfer may unleash on your site to crawl and download every one of its pages for offline viewing. In both cases, both your site’s bandwidth and resource usage are jacked up as a result, sometimes to the point of crashing your server. Bad bots typically ignore the wishes of your robots.txt file, so you’ll want to ban them using means such as .htaccess. The trick is to identify a bad bot.
Their handy article gives you a copy and paste solution to add to your .htaccess file that will return a 500 error to the known bots, spiders and site-rippers in the list.
Ready to Switch?
If you’re interested in giving Mosso a shot, they offer a 30 day risk-free trial (money back guarantee) – and if you use the promotional code REF-SNIPE, you’ll get a $25 rebate/refund on your first month’s bill. So basically, you get two months for free to give it a shot. If you’re still not sure or you have more questions, follow @mosso on twitter. They’re very responsive, and often quite funny.
Already Using Mosso?
Are you using Mosso already? What do you think about it so far? And what quirks have you encountered?
