Original URL: https://www.theregister.com/2011/04/22/war_on_the_cloud_part_2/
Floating website, hidden 'get' bills
Damon is 4 cents short of a free and cloudy solution
Posted in SaaS, 22nd April 2011 08:00 GMT
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:
1) Can I deploy a WAR file that I've built myself into the cloud (rather than using the "magic" Eclipse front-end) without upending my current build system or tying myself to Amazon?
2) Storage: I will deal with this later since I'm keeping things simple and stateless for now.
3) Billing: how did I use a few cents when supposedly in the "free tier"? Shades of "The Cuckoo's Egg"?
4) Auto-cutoff to avoid vast bills under DDoS or if I write an infinite loop. Either of these could threaten my solvency ...
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.
Speedy setup
After a couple of days I hadn't managed to set up commercial WAR hosting at all, and yet had spent $50+ and considerable time with Google and email and chat.
Manually getting my new minimal WAR file into AWS was easy: "Launch New Environment" in the AWS Elastic Beanstalk view online, choose a host name in the elasticbeanstalk.com domain, upload the WAR right from the webpage (browse and select from your local filesystem) and a couple of other clicks and you're away.
(I initially selected 64-bit t1.micro env, but 32-bit would do fine and in fact be a little more space-efficient.)
From there the site was running in under five minutes, with fairly clear status reporting in the AWS Management Console in my browser.
Using the fixed URL I could easily provide a DNS CNAME alias from my preferred domain name.
A slight irritation is that each tweak away from the default settings (eg, heap min and max sizes, min and max instances for auto-scaling, etc) requires intervention on the AWS page and then a few minutes' wait.
Killing my app off entirely and creating a new 32-bit environment took only a few minutes more, as did deploying a new version, again all via the AWS Web interface.
Accessing the AWS-hosted page yields something like:
Hello world again @ 1302901056368! (Client IP address X.X.X.X)
showing the un-proxied IPv4 address of my laptop, as desired.
The AWS management console seems robust and reliable, and handles the inevitable complexity quite well (it is capable of hosting multiple versions of multiple applications in multiple locations, etc, etc), and is a similar effort to push out new versions to my hand-rolled solution.
(AWS seems to be running the Oracle JVM from its acceptance of the -Xconcgc flag for concurrent garbage collection.)
What happens next
I will continue to develop a test deployment in AWS, notwithstanding bill risk.
For this I will need to tweak my application to avoid treating CPU as an all-you-can-eat "free" resource, and to take a slightly different approach to caching (and especially pre-caching of content before the first likely user request) so that I can afford to lose everything when an instance goes away. I'll keep AWS load balancing turned off to avoid breaking current wired-in assumptions in my code that one DNS host name fronts one JVM instance.
But I'll also continue to look out for cost-capped alternatives to AWS, cheaper and easier to manage than my current dedicated servers, at least until AWS creates a money-limiting emergency stop mechanism. And before that point it doesn't make much sense to do the refactoring needed to take advantage of AWS facilities such as CloudFront that I already have working – albeit less elegant – solutions for. ®
References
1) Find "Launching New Environments" in the AWS Elastic Beanstalk here.
2) "Configuring Containers" explains how to change JVM parameters such as heap size and where to add my favourite -Xconcgc flag.