3

Let's say we have a web-app and there's an automated/under-the-hood process which updates the DB. At the moment, they all ran in the same server.

We'd like to separate the batch-process from the apache activity and the DB:

  • server 1: webserver - floating/surges of CPU load and BW consumption
  • server 2: dbserver - floating I/O from webserver and steady/heavy I/O from batch-process
  • server 3: batch-process - steady/low CPU load and steady/heavy BW

One solution would be to set up 3 VPS (say at Slicehost/Rackspace for example).

Or should we go Cloud? Say Amazon EC2: setting up 3 EC2 instances is really overkill, isn't it? And if I port all the 3 "servers" into 1 EC2 instance, will we gain as much reliability as a 3 VPS solution? (consider 1 EC2 = 1 VPS 1.6GB 1/1.2 GHz Opteron/Xeon)

What are the differences/advantages of each solution (1EC2 or 3VPS)?

womble
  • 96,255
  • 29
  • 175
  • 230
Trident Splash
  • 445
  • 1
  • 6
  • 13

2 Answers2

2

This is my personal opinion - so someone else feel free to disagree or correct my points if I am misguided.

"The Cloud" is just re-branded VPS. Any EC2 instance at Amazon is going to be just as stable and provide just as much processing power as a VPS (depending on the specs). The benefit Amazon's platform provides is that their EC2 instances are easy to create, copy and launch. If your systems are designed to take advantage of those features, then Amazon would be a good way to go. If you are planning on loading all tasks onto one system you won't see any benefit to moving to "Amazon's cloud".

Also, I would say that both solutions offer the same amount of reliability. If any one of those servers go down, then the whole system would be down. However, the act of splitting into separate servers will give you a performance advantage, but it does not provide any additional reliability - the opposite; it adds points of failure into the system.

If reliability is your goal, I would look into setting up multiple web and/or db servers with failover. If speed is your goal, I would split into 3 VPSes (or dedicated servers). If you have the time or goals for scalability and reliability, then designing your system for deployment with Amazon EC2 (with Elastic Load Balancing) would also work well.

Dave Drager
  • 8,375
  • 29
  • 45
  • 2
    "Cloud is just rebanded VPS" is right on - the exception being Googles AppEngine. Problem is that its much more restrictive on how you do things and as a result not sure there are many serious sites on it yet? – Ryan Sep 09 '09 at 14:12
  • Agreed - just started working on a small side project using AppEngine, it is limited in terms of what you can do but has tight web<->db integration, so it should be interesting to see where it can go. – Dave Drager Sep 09 '09 at 14:22
2

You are not really making use of the "Cloud" concept (dynamically scalable) in your proposed architecture - you are just running multiple VPSs.

So my answer would be; if you go this way I don't think you've got any advantage using Amazon EC2 over VPS/dedicated server. In fact there are probably more disadvantages (e.g. harder to do persistent storage, and yes I know you should plan for disk/server failure in a standard VPS)

Expanding on the answer - you would probably end up with one of those 3 servers running full tilt and being the bottleneck while another one was hardly doing anything.

A more 'cloud like' architecture would be to have

Web server instance using Elastic Load Balancing.

When it gets busy (some metric like CPU load/queue/page load time etc) you have a monitoring process that spins up another web server instance and adds it to the farm. Repeat as necessary. When things quieten down web server instances can be removed from the farm.

Database Server

If you can use Amazons SimpleDB service then its all taken care of for you. If you need a more tradional db then this is probably the hardest part of the system to architect in a way that is easily scalable. I am going to conveniently skip over this here!

A 'job processing' instance

Say your batch jobs are stored in some sort of Queue (like say... Simple Queue Service - SQS). A batch processing server picks jobs off this queue and processes them. If the queue grows beyond a certain size you spin up some more 'batch processing' instances.

You could get very fancy with this and have some of your jobs running on a web server instance when the load is light and move on to dedicated instances when heavy - or just about any mixture you could imagine. But to really use the 'Cloud' concept you should have an architecture that supports dynamically adding X number of servers to your pool.

The poster child of this approach is probably Animoto which is a service that takes your photos, mixes it with some music and spits out a video. A CPU intensive job that is just perfect for a pool of EC2 instances. Check out the graph, going from 50 to 3500 servers in a matter of days - thats the power of 'cloud' computing.

Ryan
  • 428
  • 1
  • 8
  • 17