On Thu, Oct 7, 2010 at 2:52 PM, Atom Powers <atom.pow...@gmail.com> wrote:
> One of the COs in my company keeps asking "why don't we put it all in > the cloud"? I'm running out of good answers. > > Situation: > We have four locations (US-West, Singapore, Korea, Spain) and two > datacenters (US-West, Singapore). We have a database-driven > application (Content Management System) that is mission-critical to > all locations and all potential customers all over the world. > Currently that entire system (MySQL database and Apache web servers) > are all located in the US; performance in Asia and Spain is dismal. > > My boss, having no idea what "the cloud" actually is, wants to move > the entire system into "the cloud". After some investigation, we have > determine that some aspects of the system can be hosted on Amazon AWS > or similar. But we have big doubts about database performance, big > doubts. > > Question: > What are your experiences with cloud-based (or cloud-capable) content > management systems? > What options are there for putting a database-driven application in "the > cloud"? > Having recently done (part of) this analysis, I have some opinions. First, your main problem is that the manager doesn't know what "cloud" is. "Cloud" as you are discussing is infrastructure as as service (IaaS), as opposed to Software as a Service (SaaS), etc. IaaS is usually no more than outsourcing hardware resources. You are still responsible for *everything*, and yet you have less control. You have no control or visibility into the network, for example. A reasonably accessible overview of "cloud" and its flavors is in this guide from the Cloud Security Alliance, especially the first 20 pages or so. http://www.cloudsecurityalliance.org/csaguide.pdf Second, your problem is really performance of your application over high-latency links. Specifically, your US-based app is slow as perceived from Span and Asia. Moving to the cloud won't solve this problem. The servers still have to live somewhere. Granted, you could move the application to some other continent, but that doesn't require cloud. You could go into managed hosting (or the "cloud") in Europe or Asia, but then performance would likely still be bad for the US and whichever region didn't have the app locally. You will need to address the app's network performance no matter how or where you host it. Cloud isn't going to solve this. You might need to do more caching, or optimize page loading, for example. Re-writing the app to make a single database call (stored procedures perhaps) per page as opposed to making dozens of separate calls (from the client) per page will give you an amazing performance boost. Caching may help as well, but definitely look at how many DB calls it takes to fill a page, especially if this is an Ajax-y app where the DB calls are made from the client or an intermediate web sever. For example, if your web server front end was located in Spain to be near the client, but is 113ms from the DB server in the US, then the page load time will be the number of DB calls from the web server * the network latency. For 20 DB calls per page, this is over 2.25 seconds to load the page. (I see 76ms from east coast to .EU and 151ms from west coast to EU, average is 113ms.) Third, database applications can be I/O ntensive. An attached EBS volume (for AWS EC2) will likely perform more like a faster IDE drive than a RAID array. See ( http://af-design.com/blog/2009/02/27/amazon-ec2-disk-performance ). Don't forget that you also pay for each I/O that you read/write to the EBS. It's a $0.10 per million I/Os, but that might add up over time. If your app already wants high-speed SAN, or has a big fast RAID, then benchmark carefully. Fourth, depending on the size of the instance, it may be more or less expensive than your own hardware. Cloud vendors always show the price of their smallest instances but those are completely unsuitable for a database of any size. Look at this page for the pricing model: http://aws.amazon.com/ec2/pricing/ Now, what are your costs. Let's assume that you are running your own hardware, in your own datacenter, using UNIX. Typical DB server for us is 4 cores, 12 GB RAM and a few drives. HW RAID usually. Here's a possible config: http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/15351-15351-3328412-241644-241475-4091408.html#model-diff It's $2200 plus drives, so call it $3.5K max for the server. Depreciate that over 36 months and you get $97.22/month. That's $0.144/hour (4 week, 28 day month). Now look at the AWS pricing... There is no usable instance that beats that price. As long as your other operational costs aren't too high, you are cheaper.... That said, you will get quite a few operational features from running MySQL in the cloud, such as quick snapshots, ability to move your DB servers, etc. Short answer: Going to cloud is very unlikely to solve your problem :-)
_______________________________________________ Tech mailing list Tech@lopsa.org http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
