Paying more for good Java hosting

A recent article on OnJava.com asked why Java hosting is so expensive.

After I decided a few years ago to focus on making Java sites and move away from php/perl. Every time I would place an order for java hosting - while still a nascent freelancer and a frugal hobbyist - I did ask the same question about why the price was still higher than the basic packages offered.

I struggled with some hosts initially, and others I was strapped into using (by my client), but my recommended host and a few of my hobby sites are now safely on one good java host.

There's no way a post like this can avoid being somewhat of an ad, so I will mention that this host is Kattare. So far their features are excellent, their support (imho) is terrific and I'm happy with every aspect except the price.

In the comments to the OnJava.com link above, there were very good remarks saying the price is probably due to supply and demand. This makes sense. Java is prevalent in big enterprise companies, but these are not the same companies looking for hosting for $20 a month like most of us are. The number of freelance developers using Java for their small projects (small = $1000-$2000? you tell me) is probably the minority and that's where the high pricing structure comes into play.

But there one sole reason why I am able to say I'm fully satisfied with my host and I'm willing to disregard the high cost:

Some hosting companies that offer java have no fucking clue how to support it!

Although I'm tempted to name the hosts, here are two case studies over the past few years summarizing my experiences with two industry-leading hosts and the java sites I hosted with them.

1. Being first sometimes gives you a scary feeling

While converting a static site to a dynamic java site a few years ago, I asked my host if they supported Java and what app servers they provided. The response I received was this:

We offer PHP and Perl, why would you want to build a site using Java?

Uh ... three reasons: a) because I want to, b) because I should be able to and c) can you just answer my first question!

I was then told that yes, for a $50 setup fee, they would install Tomcat. Here are some of the many things that went horribly wrong:

• They tied the start/stop scripts into that horrible Ensim hosting manager, and it never picked up any common/lib, environment variables or anything in the classpath properly. Lost 2 weeks of my life debugging that one.
• As the host's clientele increased, eventually my java process - all the measily 128Mb or RAM I was given - is often exhausted and the box routinely freezes up
• I was told that if I wanted to have multiple apps (like a /webapps) directory, that would be $25 change fee. So now I'm relegated to one App and it's right at the docroot of my static filesystem directory. sigh.
• Using struts, my URLs used *.do extensions. Because my host couldn't figure it out I remarkably figured out how to modify the site-specific apache config for this domain myself (avoiding permissions issues), and the *.do to the Tomcat proxy configuration.
  
• To add onto the last point, every time I added or deleted a host in my reseller plan, it robotically re-createdthe custom Tomcat proxy configurations and removed my *.do mapping! Sometimes sites would stop working at random times because of virtual host configurations.

The common thread between all these bullet points is that I was always using my own research and not the help of customer service - which I'm essentially paying for. Nothing is more frustrating then talking to a customer service agent - in any industry - that doesn't understand the product they're supporting. I would get really interesting lines like "It seems like your Java packages are taking up too much memory". What? And then there was "Why is the java process taking up so much memory?". I didn't pay this host for them to be asking the questions.

The site with these problems is still live but hanging by a thread. It goes down about 3-4 times a month. I'm about a week away from re-deploying a re-engineered version of the site on Kattare and hope to never have these problems again.

Moral of the story: If you get the impression that you're the first or one of the first clients to host a java site on that host, run. Run far away and find a host with experience.

2. Big Daddy, Little Options

Ok, from the title, you can probably figure out from that title what host I'm talking about. But a client of mine bought into all their bells and whistles and I am building a java site for them to host on *cough*daddy.com.

Every host handles deployment differently, so I asked my client to contact the host's support contact to find out how to deploy java applications as war files. Here's the response they got - and this was written by them, not translated by my client:

Put your jar file into the WEB-INF directory in your docroot.

Hehe. Snicker. Lol. Guffaw. Insert your own chuckling mechanism here.

I told my non-technical client that this statement was akin to someone saying:

If you want to learn to play baseball, go buy a football and kick it in a goal.

He then received another reply saying:

Put your *.war file in your docroot and Tomcat will unpack it once-a-day when the server does a nightly restart. Clients are not allowed to stop/start the server. Keep in mind the server is in Arizona on Pacific Daylight Time.

For the price he's paying, this java hosting service is very limiting. Once a day? No stop/start? C'mon. The server sounds like it's in China, not Arizona.

Moral of the story: A host can offer every feature in the web world - including java hosting - but if it's all half-assed service, the money you saved is now costing you in delivery and features.

Summary

I currently pay $29 or so a month for the level of service I choose with Kattare. Thanks to a referral program, each month that number seems to be going down.

For the great service that a knowledgeable host provides, I am more than willing to pay a premium for this service then have to waste my valuable e-time debugging classic issues created by poor configuration and lack of knowledge from hosts that only wish they knew how to host java applications.