Tag Archives: linux

On the Cloud

Unless you’re a geek from another planet, you’ve been hearing the buzz about cloud computing for the past year. Amazon has been one of the major thought leaders in this space with their EC2. Combined with their other web services, Amazon provides about the most complete cloud implementation. There is only one problem…. price.

A small EC2 instance would run about $73 a month. Yes, you can go cheaper if you turn it off, but how many people actively turn off their websites? It can get cheaper if you reserve capacity, but the $325 up front cost is a bit too steep for me.

I’ve been looking at cloud solutions for a development playground for a while. After taking a look around, I quickly discovered that quality hosting of Java applications is pretty difficult to find, especially given my requirements. I want a host that is running Java 6, Tomcat 6, MySQL 5 and allows me to do what I want with the instance. Shared hosting is obviously not the solution, so I looked at “Virtural Private Servers (VPS)” as an option.

Even VPS has been a pricey option. GoDaddy wants around $45/month for a virtual Linux server with 512MB of RAM. I tried one for a bit, but it wasn’t cost effective for a playground environment. I had about given up hope until I stumbled upon Mosso.

Mosso is Rackspace’s new entry into the cloud computing space. They are trying to get a foothold against Amazon in a pretty simple way, trash them on price. For an equivalent size cloud server, Mosso costs about the same as Amazon. But unlike Amazon, Mosso scales down to smaller instances. For about $22/month, you can get a Linux cloud server with 512MB of RAM that you can do what you want with.

I signed up for one of Mosso’s cloud server accounts last week to use for Java. 512MB of RAM is plenty for what i want to do. You can pick what Linux distro and version you want to use, and I was pleasantly surprised to see they had the latest and greatest (Ubuntu 8.10/Fedora Core 10). They are obviously targeting this at alpha-geeks.

One big difference with Amazon is that Mosso does not offer Windows. They provide you with a very naked (read secure) base Linux install to start with. You have to be competent with Linux (ssh, bash, shell commands) to even have a chance with Mosso. I’m pretty comfortable with Linux, but there are still some things I had to consult some friends on. In the end, I setup exactly what I wanted: Ubuntu 8.10, JDK 1.6.0_13, Tomcat 6.0.18 and MySQL 5. I’m using the instance to run some Java sample applications I’m working on and will use it as the backend for a Facebook application I’m going to play with.

The only downside I’ve found with Mosso is that it is pretty immature compared to Amazon, especially in the area of documentation. You can see the Rackspace guys are working on it, but there are still a lot of holes. I was pretty frustrated setting up iptables for a firewall because the documentation says “look at this sample” but there was no sample attached. Fortunately, Google and a friend saved me. The documentation for setting up email has the same holes.

Once I got past the documentation issues, Mosso has proven to be a winner. This is going to put a lot of pricing pressure on Amazon and the others in this space. You’d have to be an idiot to pay GoDaddy twice as much for the same thing. I’m willing to bet you’ll see about everyone hit $20/month for a usable cloud server before too long. Amazon will definitely have to drop their price.

On a side note, here is a good sample of an iptables rules file you can use with Ubuntu on a Mosso cloud server. Just be sure to change 10001 to whatever port you want to use for SSH:

*filter

# Allow loopback adapter
-A INPUT -i lo -p all -j ACCEPT
-A INPUT -i ! lo -d 127.0.0.0/8 -j REJECT

#  Accepts all established inbound connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

#  Allows all outbound traffic
-A OUTPUT -j ACCEPT

# Allow SSH (very important - set to right port)
-A INPUT -p tcp -m tcp --dport 10001 -j ACCEPT 

# Allow 80 and 443 (web traffic)
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT 

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -p all -j DROP
-A FORWARD -p all -j DROP

COMMIT

Compiler Wierdness

I was playing around with the Spring/ExtJS Template on my Ubuntu box and ran into a strange problem. On the Vista laptop, if I compile with IntelliJ or from the command line with Ant, the application works perfectly fine when I deploy it to Tomcat. On the Ubuntu box, the WAR file generated by IntelliJ worked fine, but the WAR file output of the Ant script puked and died.

It took about an hour of hair pulling to figure out what the problem is. In the original build.xml file, the compile task looked like this:

Notice I didn’t specify and of the compiler, source or debug options. On Sun’s JDK 1.6.0_12 for Windows, debug appears to be the default. The Spring annotation needs the debug information for mapping parameter names in views.

On Linux, the same JDK (Sun 1.6.0_12) behaves differently. It does not include the debug information by default. In order to make my Ant build file work, I changed the compile attributes to this:

Explicitly defining debug=”true” resolved the issue. This is the first time I’ve bumped in to a basic behavioral difference for Java across operating systems. The lesson learned is play it safe and always specify compiler values.