Well, "Cloud Computing" ain't anything new. The concept goes back to when computers first came out and people shared or leased time/usage on those huge mainframe dinosaurs. It's just that with present day systems the concept can be used on a much larger scale with great efficiency.
So I switched my company from colocating our servers and other equipment (similar to dedicated servers except we own the servers) to Amazon AWS Cloud Services. So far so good. Plenty of OS varieties to choose from. Plenty of configuration flexibility. We can basically build a virtual server that lives in the "cloud" and configure the "hardware" and software anyway we want. And we can get new servers up and running in just minutes. Only problem I see so far is the data storage. There are 3 options:
1. S3 (like a large HD you can creae in space and use for storage)
2. EBS (virtual volumes you can create and attach to the server as a block device for storage) EBS is like a RAID volume. So data is safe. "Disk faailure" won't mess you up. You can make em as big as you want. Problem is, EBS volumes are accessed via some other place, like network attached storage. So data xfr is slow to and from EBS volumes.
3. Runtime storage. This is the best if you want to run a DB. It is the the size of the raw server images that Amazon provides. So it only comes in 3 sizes... Micro, Macro and large. micro is like 600MB, Macro is like 200GB and LArge is like 1.2 TB. It is like a HD attached to your server locally, not over the network. The runtime storage or HD is like RAM. Problem is, if your virtual server crashes or goes down the storage disappears, just like RAM. The solution is to take snap-shots of your server and volumes then use those snap shots to recover from a server crash. Snapshots can be stored in S3 or EBS as seperate volumes.
So far, loving the Amazon AWS Cloud Services.



Bookmarks