The Server Foundation
CAUTION: There are some posts we’re writing which talk about the lofty goals of the iVolunteer project, how we’re hoping to change the game with regards to how people volunteer, and how the amazing Boulder community is coming together to make it all happen. There are other posts which appeal to a more… uh… geeky crowd. This post is squarely in the latter camp.
Think the comic on the right is funny? This post is for you.
As we’ve mentioned previously, one of the goals of iVolunteer project is to work with other great Boulderites in the tech community and have an opportunity to get our hands dirty with some cool new technology while doing so. Amazon Web Services (AWS) falls into the “cool new technology” category. Anyone with a credit card can have access to all the building blocks of a full service datacenter on demand.
The two big components of AWS are the Elastic Compute Cloud (EC2) and Simple Storage Services (S3). EC2 provides machine instances and supporting services to make them useful, while S3 provides a robust storage platform for your data. Together (optionally with a host of other AWS services) they provide the foundation to run robust scalable applications.
So how cool is AWS? During early development of iVolunteer, we had a bug which generated a number of database transaction logs that filled up our EBS volume. The database wedged and cleaning it up safely would have been problematic. However, we just fired up a larger EBS volume, connected it to our instance and moved the data from the old volume to the new. MySQL could then start cleanly and we cleaned up the logs safely. That done, we moved the data back to the old EBS volume and deleted the larger one. Start to finish it was about 30 mins, done without opening any trouble tickets or calling anyone and cost about 10¢. Try doing that in traditional hosting environments or even your own datacenter!
We are running on a single small instance while in development. By design, however, the application can be fully broken out and scaled both horizontally and vertically as required.
We started with a base Ubuntu instance from Eric Hammond, configured an EBS volume to hold dynamic data and an elastic IP address to use for DNS. We then layered on the following apps:
- mySQL for database (can be anything really, just went with a standard)
- glassfish for the java app server (again any Java EE 5 container works)
- apache2 for web services (for the application, httpd just needs to serve static html pages)
That’s all that’s required to run our application. To get to v1.0 we went with industry standards for the most part. As we get closer to release we can revisit the choices and decide if there are better options to meet our needs.
As an aside, the java part of our application is split into 2 components. the first is responsible for ETL of data from our sources, which writes into our database. The second is responsible for the REST services consumed by the website and iPhone applications. They can run in the same application server container, but its not necessary.
Vertical scaling can be achieved by breaking things into web service, REST service, and database layers initially and caching layers later on. Horizontal scaling is easy using load balancing within the web and REST layers with the database taking a little more work (its read only outside of the ETL process and infrequent saves of user profile data).
If you’re still reading, you really need to come to Tuesday night’s meetup at RedFish. If you know this much about random technology, you probably need to get out and socialize more! We’ve got just the group for you. Leave a comment and Dave will even buy you a beer.
Tags: AWS, Development, Java, REST, Server


January 21st, 2009 at 10:38 pm
Nice – great example of the value of AWS, Dave!
I'm not sure of what you mean by breaking stuff into web service AND REST service… my understanding is that REST is an architecture style that can be used to *build* web services…?
January 21st, 2009 at 11:49 pm
It is confusing as written… probably should be "breaking things into httpd service, REST service, and database layers." The web application is static html/js/css which needs to be served to the browser where its executed. I need to write a post on sproutcore… make sense?
January 21st, 2009 at 6:11 pm
In that comic, I'd be the sandwich maker.