JohnBs personal blog

After my foray into Aptana Cloud a few blog posts back I was contacted by Spike Washburn (formerly in charge of CF engineering team back in Macromedia days) telling me about his companies offering for Java applications in the cloud and the most exciting part that Adobe ColdFusion is an available option (+1 over Aptana Cloud!). (I’d love to know how it’s being licensed as previous discussions with Adobe have been pretty short when it comes to EC2 licensing).

I’ve been playing with Stax.net (currently private beta) for just over a week now and whilst it is still beta does provide significant promise. It’s a little different to Aptana Cloud in that Aptana Cloud is all about the ‘application’ there’s no concept of ‘servers’ – the only resources you can ramp up/down is RAM and disk, whilst applications can burst up to 95% of the CPUs on the server. Aptana also provide a number of ‘value added’ services, private/staging servers, subversion, team working and various sync tools built right into Aptana Studio as well as notification emails when a sync take place.

Stax.net takes a slightly different approach. The service is built on Amazon EC2 but it is also beautifully abstracted away from it. At no point are you dealing with Amazon instances or any of the other endless Amazon offerings. The downloaded SDK provides a simple command line interface to create a new application using your chosen flavour of Java application, ranging from a simple J2EE web, jrubyonrails, google web toolkit, flex to ColdFusion. Creating a ColdFusion app downloads a specially packaged version of the CF J2EE war file that Stax have built with Adobe. You are then able to run this local instance directly using the tools in the SDK, place your code into the ‘webapp’ directory in the new application structure and hit your app via the built in webserver. You’re able to create a mySQL database in their online console and there are a number of options for connecting your app to your database – I edited the neo-datasource.xml file by hand (Later Spike hooked me up with a skeleton app that included the CF administrator but I think the preferred way will be to use the adminapi?).

I used mangoblog as my test app – I’m all about taking an existing app and deploying it to the cloud. Having to make significant changes to my app to get it to run in the cloud (ahem, Windows Azure) isn’t something I want to have do. I then deployed my app to the cloud using the command line.

Hitting the URL provided for my application, I was presented with the mangoblog setup which I completed quickly and sure enough I had mangoblog up and running.

http://mangoblog2.jbeynon.staxapps.net/

In the application console you have (or will have) options to change the ‘server zone’ where your app runs, basically from shared application pools, private app pools to a dedicated server for your app as well changing the cluster size from 1 to 5 servers.

I figured I’d try some of the funky buttons in the application configuration tab;

so I hit the 2 servers button which then deploys the application to two separate servers. Once redeployed it’s at this point where you come across an Amazon EC2(ism). Now these are points I’ve already highlighted to Stax and I’m absolutely sure they’ll be able to do something about it – but at the moment there’s a certain ‘type’ of application that is suited to running on Stax.

Remember I ran the mangoblog config, told it about my datasource, set some properties and it’s then gone ahead and built the Db schema in the database *BUT* it’s also writes a config file to disk. So now, I hit the URL again and it’s prompting me to setup mangoblog again…obviously because it’s now redeployed the original application to the 2 servers which didn’t have the config file in the ‘configured’ state. This is pretty easy to overcome, simply config the app before you deploy it to Stax but this does then force some fairly key application architecture decisions on you because it means that applications you deploy to Stax can’t write to disk, i.e.. file uploads thorough a CMS, attachments to blog posts, custom avatars for a forum etc or if you do, you have them to route them to an external store – Amazon S3?

At Monochrome towers we were discussing this over lunch and comparing it to the types of apps we build – whilst some of our complex Flex applications powered by CF in the background would be ideally suited to Stax hosting some of our more traditional ColdFusion ‘Social Networking’/CMS sites wouldn’t because of the storage feature. It got us thinking about how to architect an Amazon EC2 infrastructure that could provide totally flexible application hosting (with scale up/scale down) as well as persistent storage and I think I came up with a solution and this will be the subject of an upcoming blog posting…the downside is you’d have to get deep down and dirty with Amazon EC2 yourself!