How we built buildabrand. A sneak peak.

By Justin Champney on August 4, 2009 at 6:26 pm
Keywords Technology and tagged , , .

Welcome to buildabrand! Curious about how we put all this together? Then read on…

Firstly, let us introduce ourselves: we’re Justin Champney, Founder, CEO and Design Director and Dave Shanley, CTO and Chief Engineer. We want to talk a little about some of the technology behind our product and some of the vendors and products we use to make it all happen.

We love to learn and share. One of our founding principles as a company has always been: retain transparency in everything we do. While we can’t give everything away, here’s a list of some of the technologies we’ve used:

  • Java (Lots of it, nearly 26k lines at last count)
  • PHP (Not so much of it, but some none-the-less)
  • Apache Tomcat (Hosts our Java apps)
  • Apache HTTPD (Hosts our PHP apps and static content)
  • Apache Struts 2 (The web framework we use with our web apps)
  • Spring / Spring Security (The glue between our web apps and buildabrand’s core engine)
  • Hibernate (ORM for our engine)
  • MySQL Cluster (Database)
  • Terracotta (Clusters web nodes to share a JVM – very snazzy product)
  • PDFLib (Generates our high res output)
  • Amazon EC2 (Buildabrand lives in the cloud!)
  • Amazon S3 (Nice, fast, stable and secure data storage)
  • Re-Captcha (Provides us with robot/spam checking facilities)
  • RPXNow (Wonderful single-sign-on authentication provider)
  • UserVoice (Top notch user-generated feedback product)

We also use a massive array of libraries and utilities (some open source, some commercial).

The majority of the supporting framework for buildabrand is written in Java using Spring, Hibernate and Struts 2. We chose Java because of its awesome portability and power when it comes to heavy lifting. We could have gone with Django and Python, but integrating all of the external components into a single engine would have been very time-consuming.

We have chosen Amazon Web Services (AWS) as our hosting technology provider. Why? Well, because the Elastic Compute Cloud and S3 storage service are nothing short of amazing.

buildabrand needs the ability to scale our infrastructure horizontally (meaning add more servers/nodes) and not vertically (add more memory to servers). We intend our product to be available in a multitude of markets so we will need to deploy hardware to those regions (which is why horizontal scaling is better for us). Amazon has built an incredible service that shoots any cloud based competitor out of the water in terms of power, configurability and flexibility.

I had the pleasure of attending a seminar with Dr. Werner Vogels (CTO/Vice President of Amazon.com) at the Web 2.0 conference in San Francisco eariler this year. I heard him talk about how he structured a AWS department using a noded approach to product development and how it integrates with the rest of Amazon’s technology services. After Werner’s talk that I knew we had made the right choice with AWS.

During our closed beta we will be running a scaled down server architecture consisting of a single node (1 server configuration). When we launch our open beta later this year we will be ramping up the server architecture to something much more robust:

  • Two large load balanced web nodes, both clustered using Terracotta.
  • Three small, load balanced data & query nodes. All clustered using MySQL Cluster Edition.
  • A staging and continuous integration node to keep things moving.

Here is a little diagram of how it all works.

bb-tech

We are always open to questions, inquiries, and general tech chatter. If you have any questions, send us an email.

Print
RSS

7 Comments

  1. Kevin Mascarenhas
    Posted August 10, 2009 at 4:32 am | Permalink

    Hi Justin,

    I sat next to you at the Business Link “Start Up” course a month or so back. I have two months in which to develop my business proposition. I’m really keen to use your platform. I was hoping to be part of your closed loop beta testing group.

    I’m developing my ideas around a design consultancy for ecological and sustainable land management. In October, I leave for a study tour in central America.

    I look forward to hearing from you.
    Cheers
    Kevin Mascarenhas

  2. Dave
    Posted August 10, 2009 at 9:45 pm | Permalink

    Hi guys,

    first of all I wish a huge success because your ideas are brilliant and your service looks disruptive.

    I have few and very dumb questions on the architecure (I’m not an experienced engineer and I’m going to create a my first startup) :

    1)Why do you need two different storages : Amazon S3 and MYSQL ?

    2)Why did you discarded Ruby on Rails in favor of Java ?

    3) Load balancing : why do you need to implement your own load balancer , is not Amazon EC2 providing that ?

    I know this are really rookie questions, but you inveted to ask ;-) , I can’t miss such opportunity :D

    Looking forward to use your service.

    And thank you in case you will aswer my questions .

    Cheers
    Dave

  3. Justin Champney
    Posted August 10, 2009 at 10:08 pm | Permalink

    Hello Dave,

    Thanks ever so much for your comment and your feedback. Here are the answers to your questions:

    1. We store our client and product data & meta data using MySQL, however we store our raw assets and generated branding on S3. We use both because storing binary data in a database is a bad idea, it can get corrupted easily when restoring / backing up. S3 is lightning fast for serving binary content and infinitely scalable – we never need to worry about runing out of disk space!
    2. Rails is great for web sites. It is not so great for background processes or process intensive heavy lifting (one of the reasons why twitter migrated to Scala from Rails). It was a toss up between Python with Django and Java with Struts 2. We chose Java (there was no learning curve for us).
    3. You’re correct! AWS does provide the load balancer, we haven’t implemented our own. Sorry if that wasn’t clear.

    Hope that clears some questions up, feel free to ask any more!

  4. Dave
    Posted August 11, 2009 at 11:22 am | Permalink

    Thank you Justin,

    You could teach Web Oriented Architectures in University!
    Your answers where very clear and convincing.

    Do you have some resources (web) or books to suggest about solid web architecture strategy?
    Ok last question (alternatives) : if someone would decided to choose Python, would you also choose Google Apps engine?

    Your service will be a hit, and we know that well scale forever :-D

    Cheers

  5. Ben Francis
    Posted August 25, 2009 at 9:04 am | Permalink

    Hi Justin,

    Thanks for sharing this information, it’s interesting to see that you took similar decisions to a team I’m working on at the moment.

    I’m curious to know how you’re persisting the data in your MySQL cluster. As I understand it, EC2 instances don’t have non-volatile storage so you have to use one of Amazon’s data storage services as a back end. Are you using Elastic Block Storage to store the data from your MySQL cluster, and how does that work exactly?

    Thanks

    Ben

  6. Dave Shanley
    Posted August 25, 2009 at 10:06 am | Permalink

    Hi Ben,

    Yes, you’re right: we use EBS to persist data permanently. You’re also right when you state that EC2 instances don’t have non-volatile storage (once you shut down the instance, it’s all wiped clean). EBS works by creating a virtual drive, known as a volume. You decide how large you want the volume (minimum is 1GB, but can go into the tens of TB’s). Once you have created your volume, you can then attach it to any one of your instances with a few commands, or, using the AWS console, you can do it by just pointing and clicking. Once you have attached the volume to your instance, you will need to create a file system on it (if it’s brand new and has never been used).

    When you attach your EBS volume, you define a device type, like /dev/sdaf, so on your instance you can simply mount a new drive as if it were a new hard disk. Then, configure your database node (or whatever system you want to persist data to to use that mount point instead of writing to the local file system) and voila! you have non-volatile storage. When you are done with your instance, when you shut it down. Your EBS volume will simply be unmounted and wait to be used again. AWS have also given the ability to create snapshots of your volumes so backups are a breeze! If you configure your AMI to always use your new EBS volume, you will have a pretty robust setup. You can create as many volumes as you like and attach and detach them to any instance at any time (though you can only ever have one volume attached to one instance at a time).

    Hope that clears things up.

    Let me know if you have any other questions.

  7. Ben Francis
    Posted August 25, 2009 at 11:35 am | Permalink

    That’s very interesting, thanks Justin!

    One further question – does your setup allow your database cluster to automatically or “elastically” scale up and down (horizontally, if that makes any sense!) based on demand? it sounds as though increasing or decreasing the number of nodes in the cluster would require manually creating or removing a new server instance and an EBS volume for it to persist to, mounting the EBS volume on the instance, then somehow adding that node into the cluster.

    Another hosting solution our team looked at was Google App Engine. GAE provides this kind of database elasticity by default, and can host both Java and Python, but also has its own limitations and the data store isn’t a relational database. I’m guessing the lack of mass file storage on GAE would have been an issue for you too. For us, the problem was not being able to run Apache Jackrabbit using the data store and without Java threading support.

Post a Comment

Your email is never shared. Required fields are marked *

*
*