Code Trials

After a year of working with various cloud vendors and configurations it has become clear that for many of our existing clients we will not be pursuing the One Site Per Cloud strategy. This works very well for tiny clients and large clients. But for all of the guys in between it is difficult to manage the peaks and so we're moving towards a model that uses around 8GB RAM and serves from 8-16 clients. This smooths out the traffic flows and is a little more manageable.

For our larger clients we continue to dedicate individual cloud servers to them and have see this model work very well.

I've been working on the Digital Cheetah Cloud Platform for about six months now and we're currently in the Alpha test phase. Shortly we'll begin the Beta phase that will last through May. In many traditional web site set-ups, you minimize cost by adding as many virtual sites per server as you can - sometimes 1000's of sites physically reside on a single server. Digital Cheetah typically has 10-40 sites per server. However, although this is cost-effective, it is a long way from optimal in a more virtualized world.

Thanks to competition, it is possible to get a full Cloud Server (cloud) or Virtual Machine (VM) for around $11 per month. This allows you to consider using one cloud for each site. This means we'll have 1000's of clouds eventually, but as long as our Cloud Platform can support them there are many benefits to this approach:

• Flexibility
  • You can resize the cloud according to the site's requirements.
  • You can choose specific versions of a stack per site without worrying if it clashes with other sites on the same stack.
  • You can choose a physical location close to the site.
  • You can try new software for a single site and have limited deployment until you are ready for full deployment.
• Fault Tolerance
  • Each cloud is likely to be on a different physical server so if the server dies and there is no automatic rollover, only one site goes down, instead of many.
  • It is easy to move sites around.
• Billing
  • It is easy to know precisely what a site costs you because they each have their own cloud.
  • If you group sites into logical networks or verticals (and possibly individual billing units), it becomes easy to see the cost of each vertical.
• Individual Time Zones
  • Each cloud can have the precise time zone tailored to the site.
  • By having multiple clouds in a network with different time zones it lowers the load across the network because instead of batch jobs all firing at midnight (say), midnight is now spread across multiple time zones
  • Maintenance starts during the night for each client.  Today when we fire-up a "nightly" job it could actually be running at 9pm in California when the site is still quite busy.
  • Maintenance jobs process concurrently during the night. When you have a 100 sites on a server any nightly jobs can take hours because each site is worked on sequentially. When they are distributed across multiple clouds they all finish sooner.

If you can manage the clouds automatically then it is easily the best approach for the client, and is a huge benefit of Cloud Computing.

I've been busy working on the Digital Cheetah Cloud Platform for a few months now and although my early work was focusing on Amazon EC2, it has become clear that there are lots of choices. I now have various cloud projects running at:

• Rackspace Cloud
• Amazon EC2
• Linode Cloud
• GigeNet Cloud
• CoreNAP

I'm primarily working with very small cloud instances (256-512 MB) and although each vendor has various benefits, based on: performance, reliability, price and simplicity I currently plan on using Rackspace for most of our cloud servers.  Things could change over the next 12 months, in fact I'm sure they will, but today Rackspace are the clear choice for what we are looking for.

Fifteen years ago I built my first web development platform or framework called SAGE that was used by garden.com to go public. Nine years ago I built a new platform called The Universal Web Engine (UWE) that we have used at Digital Cheetah since its inception. About three years ago I mapped out a new system that was going to replace the UWE. I actually began to implement it in 2008, but was forced to shelve it's development due to the economy. This month I began looking at starting this new platform in earnest.

My plan was to use Python as the primary development language and I was going to take all of the ideas from the last fifteen years and develop the "perfect" system for the creation of 1000's of custom websites. Luckily before I had really started I rediscovered Django.

Django, named after the legendary guitarist Django Reinhardt, appears to be the perfect place to start to develop a new framework. It doesn't do everything the way I had planned, but it does so much more and is flexible enough to allow me to augment it with at least a few of my own ideas.

To the many happy developers and designers already using Django this is probably no big surprise. But for someone who has been used to developing his own frameworks from scratch this is a huge departure. I for one am really excited that I can start building at a much higher level.

I believe using Cloud Computing and Django I will truly be able to deliver a platform that will allow Digital Cheetah to continue to provide world class custom solutions for the next ten years and beyond. And just maybe we'll be able to build a new website for ourselves too, instead of the eight year old one we currently have!

So it is clear that I have been impressed by Amazon Web Services and Cloud Computing in general. I remain convinced that virtualization will eventually be the new order of things.

However, I have experienced a few bumps in the road. Firstly, Amazon Support. So far I have been unable to get them to respond to my enquirers. My guess is that unless you pay for support you'll be primarily stuck with forums and the help docs. This is fine if you know about it up front, and I expect to factor in fees for Silver or Gold support.

Secondly, the Amazon Relational Database Service (RDS) appears to be a lot slower than setting up your own MySQL instance. In my benchmarks, using the standard MySQL Benchmark Suite, RDS runs at about 6 times slower. I tried my tests with MySQL running on the same instance and also a different instance and in both cases RDS was about 6 times slower. This doesn't mean that RDS is unusable and might be perfect for you. But at this point it feels like more tuning is required.

Finally, the whole issue of security. One of the problems with offering such an all encompassing and compelling service is that you basically hold a big flag up to all would be hackers out there. I'm sure that Amazon are better than most companies at providing security for their web services. However, by being so big and so good the threat of being hacked goes up proportionally too. This is the one area I have to get my head around before I recommend we move our enterprise to Amazon. In the meantime I am looking at other companies that use Eucalyptus to provide a private cloud with similar features to Amazon, but with a little more control and anonymity.