<div>On Wed, Nov 9, 2011 at 4:35 PM, Ronald Cotoni <span dir="ltr"><<a href="mailto:setient@gmail.com">setient@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Huh.  ec2 instances are not backed up unless you write scripts to back them up to SOMEWHERE.  They are not salable unless you actually make them scalable (mysql replication, load balancing).  It isn't the "cloud" like you think it is.  Also ec2 or ec2 clones are over priced for a single wiki.  <a href="http://www.lowendbox.com" target="_blank">www.lowendbox.com</a> for significantly cheaper VPS servers (that is really all ec2 is by itself).   Also, I don't charge for hosting sites.  At all.  You should really take a look at the hosting options out there and evaluate them first hand before deciding for or against ec2 or really any other option there.  <div>
<div></div><div class="h5"><br></div></div></blockquote><div><br></div><div><br></div><div>That <a href="http://www.lowendbox.com">www.lowendbox.com</a> site looks like it was made in 1994 with Crayons. As he's running a blog that aggregates locations for cheap VPS, his site is fairly useful even if I don't like the design, though. With Amazon, if you want to go on the cheap, run a micro instance. </div>
<div><br></div><div>Much of EC2 is backed up, The (stored version) of instance itself is held in S3 which is guaranteed against data loss. </div><div><br></div><div>For data persistance across instances, you can mount EBS under LVM and schedule LVM snapshots of the EBS instance off to S3 via cron, guaranteed against data loss.  If you want to scale, you run more than one instance and use the load balancer functionality built into EC2 with dedicated, reserved IPs. If you want to auto-scale, use the autoscaler. <a href="http://aws.amazon.com/autoscaling/">http://aws.amazon.com/autoscaling/</a></div>
<div><br></div><div>There's a fundamental theory underpinning the EC2 strategy - You expect, demand, and want failure to occur. No single box or storage area is worth anything and when failure occurs you just move to a different instance. With MySQL, the whole concept of there being a Master (SPOF) and a Slave (yay, another SPOF) limits your ability to scale at all. Of course, If you don't want to fight with MySQL replication you can use Dynamo or other NoSQL stores instead of Mysql. While this requires substantially more labor and changes to code, it </div>
<div><br></div><div>If you wanted to stick with MySQL, you could use Amazon RDS or migrate code to Amazon Simple DB. Both have high SLAs. </div><div><br></div><div>So, fine, you have to set some things up, but it is <i>exactly</i> the "cloud" like I think it is. It's no hardware, no racking of gear, no dealing with networking, nothing. It's purely a software argument at that point and if the OS gets fucked up, I issue a single command and poof! A brand new machine in exactly the same configuration I was in a moment ago. </div>
<div><br></div><div>Times have changed and the days of screwing around with hardware to run a small business or website are mostly over. </div><div><br></div><div>---</div><div>John</div><div>Twitter</div><div><br></div></div>
</div>