Drew Ruggles's picture

I need a sensibility/reality check on an idea I'm hatching... feel free to comment good, bad or ugly.

I am a Race Director for a series of local bicycle races. We have a registration system (RegApp) that was written by one of our talented nerds (and very fast -- at least on a bike). It utilizes Google Web Toolkit so we just need to set up our LAN at the race site, and point a browser to web server for the app. All good. It works very well with multiple data entry points simultaneously hitting the database of racers information.

The issue is we don't get all the information that USA Cycling has for each racer -- pretty much all we get is their license # (unique ID), name, gender, race age (date of person on 31-Dec of current year), and category of racer (Pro, 1, 2, 3, 4, 5). Eligibility can be determined by gender, race age and category.

The other info not provided to us is the racer's email address, and emergency contact name and phone number. We would like to get that information to allow us to complete an Rider Release form, which is a legal document that says they won't sue us if they are injured during the participation in the event.

What I'd like to do is set up our system on either TKL LAMP or TKL Google App Engine (doesn't really matter which one -- the programmer would make that distinction) on an Amazon cloud server with a Dynamic DNS running and TKLBAM. After seeing Jeremy state it many times, it seems like we could either "shut-down" -- not sure if you really ever "shut-down" the cloud -- or put the Amazon instance in a maintenance mode, make a full TKLBAM backup, then bring down the TKLBAM restore to a laptop running some type of VM software (hopefully compatible with the Amazon environment).

On-site, we would need to utilize a cellular internet connection, and anyone going to online registration at that point would be directed to the laptop server (via DDNS). This would significantly reduce our dependence on mobile WiFi hotspot, and put the processing power and data where we need it -- on-site.

After the races are completed for the evening, we would reverse the process in order to get the web server back up on Amazon, and ready to take registrations for the next week's race.

Does this make any sense from a process and/or technical perspective or is the notion of a "portable server" a little too nuts?



Jeremy Davis's picture

I think it sounds like a very reasonable idea. Once you run a TKLBAM backup of your server (the AWS instance) and you have confirmed that the backup works 100% and contains all your data, you could even 'destroy' it and launch a new one when you're ready (if you wanted).

My only thought is that if you are going to rely on the cell network rather than a wifi LAN then there's probably no advantage to running the server locally. The bottleneck will be the upload bandwidth of the portable server to the internet, which will be significantly less than what AWS would give you. However if you connect to the server via LAN then it should be significantly faster than via internet (even AWS)

Drew Ruggles's picture

Agreed, Jeremy. Bandwidth is somewhat of an issue when the server is moved on-site. The Registration Staff would be on the LAN to the server, so it should be screaming fast, even for those Staff using smartphones / tablets as an interface. Where it starts to fall down -- as you indicated -- would be if someone is outside the range of the WiFi LAN (where most people would park their cars for those racers that didn't bike to the race) and at this point, they would need to rely on their cell mobile network connection to go out to the Internet, and then through our cell mobile HotSpot to gain access to the server.

It would probably work, as most of the folks hitting the website would be on mobiles, and the mobile interface will be very minimal in character -- I don't even like simple animations or transitions. Though, if we don't like the performance, we can just tell people to do what they've always done, and go up to the Registration tent, at which point, the Staff will take over on their LAN connection to the server.

Good to hear I'm not completely bonkers.


Drew Ruggles's picture

Thanks for the comments, Ray. It's more than just a database transaction, as the GWT app would serve up web page forms in both Desktop and Mobile environments, but you're probably correct that the overhead would be very low -- I like a very minimalist approach (Jeremy will probably have to get off the floor after reading that comment) as least as far as interface is concerned. I don't even like transition animations on mobile interfaces (what do they really do other than take more time to draw what I really want to get at?).

We are in the middle of the mobile development, and the restructuring of the app to be able to support some different deployment scenarios.

Now if anyone wants to branch off on to where I can get up to speed, fast, on Webkit CSS...


Chris Musty's picture

I have an oldish laptop that I have installed Proxmox on and I have a Telstra 4G device (which mostly operates from Next G or 3G if signal is bad). I only use the 4G device to download security updates or to backup the VPS' I am running at the time. It works fantasticly!

The big issue I have in Australia that prevents me from utilising AWS is latency. I cant often use AWS' relational DB or even their scaled down version (whats it called again?) because its just too slow. I also have clients that refuse to operate in the cloud so cheap onsite servers are the only way.

My laptop server is just perfect as its designed for transport, can run upto 16 images at a time (limited only by RAM) and has a built in UPS! I simply unfold it at the clients site for demonstration and the local network speed (even if just 100Mb/s) is instant.

I am even going to test running windows 7 or XP inside proxmox so I can just use the laptop and still have a full client server simulation. Perfect for software and database development on remote locations.

Chris Musty


Specialised Technologies

Add new comment