Floating website, hidden 'get' bills

WAR on the Cloud, Part 2 In my last piece, I took the first steps in moving part of my own homegrown website's "cloud" into Amazon's commodity AWS cloud, using the pretty front-end in Eclipse.

That left me with some hope (it all worked quite well technically) and a few worries (I couldn't see how to avoid unlimited "ambush bills").

This time I tie up some of the loose ends from the previous foray and look at possible alternative providers with different risk profiles.

I'm sticking to a trivial WAR (Web ARchive) application for this stage; the real app can come later once the basic mechanics of deployment are sorted.

Outstanding issues from before:

Amazon or and bust

One big difference between the AWS cloud and more conventional hosting is that the latter usually has fixed or at least capped bills, while AWS does not. Small errors, or annoying 4chan, could be ruinous.

By way of comparison I attempted to set up a slightly less "cloudy" alternative to AWS hosting, ie, more conventional JSP/"WAR" hosting or similar.

I tried my existing hosting provider in the US, but their "cloud" solution is not ready yet and "Our [current] shared platform does not support .war files."

I tried my existing hosting provider in AsiaPac, and after an initial quick response to my enquiry about outline pricing and/or a test instance, it has gone very quiet.

I located a new US hosting company to try one of their WAR-hosting packages with suitable persistent storage (~100GB) and heap size (>512MB) and new enough Tomcat and JDK, and a fixed IP address, and at ~GBP35pcm probably comparable to AWS in the normal course of events. But while their sales folk were responsive and quick, their techies appeared not even to have started setting up my service 48 hours later when I ran out of time, even though they billed up-front. I still have some sorting out to do with my corporate card ...

Compared to this, as you'll see in a moment, manually deploying my hand-crafted WAR to AWS was again the work of minutes.

However, the point remains that less glamorous fixed-cost solutions are around, for probably less than half the price of my current dedicated hosting, and easier for me and the hosting company to manage when all is said and done. And at worst it may be necessary to up sticks and move quickly if an "upgrade" is suggested in a menacing way as traffic/load grows ...

Ambush bills

I sent AWS a couple of ordinary low-key "billing" support enquiries, firstly about the mysterious 3c charge (now ballooned to a vast 4c), and secondly about how to activate an automatic expenditure limit.

AWS responded quickly and politely and indeed dealt with my two enquiries in one response, seemingly efficient and organised.

AWS said that I ran up my few cents in charges on "gets" (loading a snapshot), reduced-redundancy storage (RDS is not part of the "free" tier offer it seems) and for data transfer in various possible ways. Slightly baffling to me but then what do I know about technology? I'm sure that if I spent a day reading their FAQs I would understand the detail, but at this stage I'll be content with the support person being able to diagnose the reasons.

More seriously: "Unfortunately, it's not currently possible to set a limit on your monthly AWS charges. However, I've passed your correspondence to the appropriate team for consideration. Feedback like yours is very important in helping us continue to improve our website and services."

Great, but for(;;){} or 4chan in the interim and my balance-sheet is toast!

This is almost certainly enough to prevent me going live on AWS as-is, but the technology is slick enough that continuing to test seems worthwhile.

I started a (tiny) WAR

I crafted myself a minimal-ish WAR file: (download it here) with much the same index.jsp as in the previous piece, but also printing the client's IP address so that I can detect any (non-transparent) proxying that might be happening and that might interfere with the behaviour of my application.

The new pertinent line of "code" from the JSP file is:

Hello world again @ <%= java.lang.System.currentTimeMillis() %>! (Client IP address <%= request.getRemoteAddr() %>)

and when run from (for example) inside Eclipse on a local Tomcat, yielded:

Hello world again @ 1302891262615! (Client IP address 0:0:0:0:0:0:0:1%0)

with an IPv6 loopback address evident.