Cloud servers for your Perl app - Amazon's EC2 vs Mosso

Specifications

To begin with, both companies provide several options in terms of resources for your virtual machine. Amazon has small, large and extra large virtual machines with high-cpu versions of each. Mosso, on the other hand, offers 7 choices mostly based around RAM requirements.

Both companies provide information regarding what you get on each level of service. The information that is not very clear on either service, however, is how much CPU you get with each offering. I've done some research into this and it boils down to:

• EC2's 'small' instance is approximately 1/2 of a 1 core CPU running at 2 Ghz
• Mosso's '1024M' instance gives you 1/2 of a 1 core CPU running 2.4 Ghz

The difference here is that Mosso is only 6 cents per hour, or $44 per month, whereas EC2 is 10 cents per hour, or $72 per month. That seems like a no-brainer until you realize that Mosso only provides one gigabyte of ram at that level, whereas Amazon provides 1.7 gigabytes. Amazon also gives you much more disk space at that level. So it seems Amazon is the winner here, right? Not exactly. There are some things you need to know.

Amazon describes the IO bandwidth on their small instance using the somewhat vague term 'moderate'. What this means is that for your average web server you are probably fine, but if you intend to run a database on it, you are in for some trouble.

This brings into play one of the oddities of EC2. There are issues where, apparently in certain situations, applications are unable to properly determine amount of free RAM on your VM. This problem definitely affects MySQL and is likely to affect other databases as well. If you run into this problem, if you use a complex join (or even a simple join with a lot of records) or your database simply requires more ram than is available, you suddenly wind up dealing with a lot of disk IO.

On a physical machine this would not be much of an issue, but this is where EC2's 'moderate' IO performance becomes an extreme problem as queries that take a few seconds on a 'normal' server balloon out to 12+ minutes on your small EC2 instance. Switching to a large instance solves this problem by increasing IO performance, but at 4x the cost.

This seems to be related to how EC2 handles IO allocation and how machines are deployed in the cluster. Amazon's EBS block storage is not local (IE on the same box) to the instance (though it's performance can be fooling) so they allocate IO amounts based on what you pay. Mosso doesn't have this same IO limiting.

I have had personal experience with the MySQL / IO problem on EC2 and it is a very hard problem to track down if you don't know the above. I have not yet had any issues on Mosso, though I have only been using them for a short time.

Back to CPU, at Mosso, you get 1 full 2.4Ghz Core per 2G ram in your chosen service level. This is a linear upgrade and the cost is linear as well, so it's clear what you are getting. When you reach 16GB ram, you have run of one of the Mosso cloud machines, 8 cores at 2.4Ghz, though the cloud is still flexible enough to move your VM to a new machine in the case of hardware failure. As I understand it, both EC2 and Mosso will result in a few minutes of outage in the case of a hardware failure on the physical machine your VM was running on.

APIs and services

As the more mature option, Amazon's EC2 has a solid API offering that many companies have built upon. There are offerings such as RightScale and it's less expensive competitor Scalr, which will automatically scale your application based on current traffic and system load. These offerings are interesting when you are running a sizable site that might need that service. Perl based applications seem to be somewhat neglected in these offerings, though I suspect that if you want it enough you can make it work.

Mosso has an API as well, but it is not yet publicly released. As such, those types of services are not available. Mosso does, however, provide something called cloud-sites which provides a similar solution. I've spoken with them about this offering and while interesting, it leaves Perl in the cold insofar as it does not allow root level access, so installing Perl modules can be a problem. It'd be interesting to see a local::lib deployment there, to see if something like a Catalyst app could be deployed upon it.

Of course, none of this matters if you aren't running an application that requires a large number of servers. The vast majority of web applications I've seen tend to run from one to a small handful of machines, in which case the auto-scaling cloud-site type services of both EC2 and Mosso are irrelevant.

Storage

One place where Amazon's offering shines is in additional storage. Amazon offers EBS (Elastic Block Service) which lets you create large blocks of filesystem-level storage which can be mounted onto any instance. When configured this way, you pay per Gigabyte allocated. This is very important to those sites which require a significant amount of storage. Mosso does not offer mountable additional storage.

Mosso provides cloud-files, but this is a solution akin to web-dav or S3 in that it requires integration into your app (via an API) to access. There is a Perl interface to Cloud-files, but unless you are starting a new app, or have the luxury of making significant changes to your app prior to deployment, this won't be of much use to you.

Since there is no filesystem-level option, if you have a particularly large database or you have other filesystem storage requirements your only option is to use a larger instance with more storage. This, I think, is a significant drawback to Mosso. Fortunately, the storage provided with each Mosso server is adequate for what you are likely to need for an 'average' web app.

Bandwidth

Both Amazon's EC2 and Mosso's cloud-servers require you to pay for the bandwidth you use. In both cases, their costs are reasonable. Amazon is a bit cheaper here at $0.17 per gigabyte, compared to Mosso's $0.22. Amazon's prices drop as your bandwidth usage increases, but with the first drop at 10 Terabytes, not a lot of people are likely to notice that difference.

Interestingly, for inbound traffic, Mosso beats out Amazon with a rate of $0.08 per gigabyte to Amazon's $0.10. This can make a difference if your service takes a lot of uploads or you do a lot of content aggregation. Generally speaking, however, unless your application has a somewhat inverted traffic pattern to most sites, this won't make a huge difference for you.

IP allocation

There is one difference between cloud servers and EC2 that can be extremely important. That is that Amazon enforces a strict 5-public-ip rule. This means that your company can only have 5 dedicated public IPs, regardless of how many servers you have. Note that I did not say application, this is a per-EC2-account rule. This can be a problem if your company hosts multiple sites, or if you have other public-IP requirements (such as SSL certificates for multiple sites for example.) Mosso does not have such a restriction. At Mosso, you have one public IP for every instance you have.

Mosso also provides reverse-DNS to your own domain, which can be very important for things such as email delivery. EC2 does not provide any method to edit reverse DNS. Among other things, this makes EC2 not feasible for anything requiring outbound email delivery. You can get around this by having a non-EC2 relay host for outbound email, but in many ways requiring an external host defeats the purpose of working within the cloud in the first place.

Other differences

One of the other interesting differences between EC2 and Mosso is the 'upgrade path.' With EC2, if you find that your machine needs more resources, you don't have a ton of options outside of 'create a new larger instance and migrate to it.' There are ways to make this an easier process than an initial deployment, but it requires some know-how of EC2.

Mosso, on the other hand, has a more direct upgrade path. If you require more memory or more CPU, with Mosso you can simply upgrade your instance. The process is automated and includes a verification step so you can make sure the upgraded machine works properly before permanently disabling your smaller instance. Ultimately, though, it only requires what amounts to a VM reboot, and once that is complete you simply have what you need. This can be very appealing when you are initially rolling out an application and simply need to give your server more power as you get more users.

Another place where EC2 and Mosso differ is in server installation. Mosso behaves much more like a real machine, at least in terms of initial deployment. If I didn't know better, you could tell me that the Mosso VM was a real machine and I'd probably have believed you. Amazon's EC2 instances are a slightly different beast, though enough people have delved into AMI (Amazon Machine Instance) creation that there are now literally hundreds of options tailored to the EC2 environment.

Mosso has the advantage in cloning an existing machine, however. With Mosso it is very easy to clone an existing server into a new vm and requires very little Mosso-specific know-how. EC2 offers creation of new machines from an AMI, but you have to have worked out how to create an AMI in order to use it. Not a huge hurdle, but Mosso makes it significantly easier and that is a win in my book.

All that said, when you are talking about hosting, it almost always comes back to...

Price

Amazon's EC2 and Mosso are competitive when you get to the larger machine types, though Mosso has a slight edge in terms of CPU power. Mosso's next-to-largest offering has the same amount of CPU power as the Amazon's top-end extra-large offering at $200 less per month.

Where Mosso is really interesting, though, is in the smaller machine types. You can get a very small Mosso machine in the $11 per month range, and a fairly capable one at $22. For those testing the waters or wanting a machine for development, that's a great deal giving you a solid machine at a low price. In addition, Mosso's quick upgrade solution makes growing your machine's resources very easy.

The summary

On the whole Amazon EC2 and Mosso are very close competitors. Amazon loses out on CPU power per dollar spent, but Mosso costs a bit more per gigabyte of RAM. Mosso loses out on 'extra storage' but wins on general IO speed. Mosso has the advantage on individual server upgrades with it's instant-upgrade features, but Amazon wins on large-scale deployment because of it's API and solid auto-scaling options.

So which do you choose? If your application is particularly memory bound, requires a huge amount of disk space, or if you are at the higher end in terms of clustering requirements, Amazon's EC2 is a good solution.

If that is not the case, however, EC2 just doesn't hold up, cent for cent, against Mosso's offerings. In my opinion, the combination of lower cost, better base CPU/RAM options and a smoother upgrade path make Mosso's cloud-servers the clear winner.

Mosso gives you the ability to start with the smallest instance feasible for your web-application and the ability to upgrade without disrupting or re-deploying your system. This makes it perfect for the prototype, test, deploy, upgrade site development cycle we are all familiar with.

For most applications and services, Mosso cloud servers stand out as a great hosting option. It is good for production hosting as well as prototyping and architecture testing. It's low cost and excellent web-based management interface make it an all around good choice. When it's API is released later this year, it will be hard to think of a reason not to use Mosso for any application, regardless of it's size or complexity.

What do you think? Have you used EC2 or Mosso cloud-servers? Got comments, or feel something I wrote isn't quite right? Sound off in the comments!