Review: Google Compute Engine
snydeq writes "InfoWorld's Peter Wayner takes an in-depth look at Google Compute Engine, the search giant's response to Amazon Web Services and Rackspace. 'If you want to build your own collection of Linux boxes, Google Compute Engine offers a nice, generic way to buy servers at what — depending on the size of compute instance you need — can be a great price. The most attractive feature will probably be the proximity to the other parts of the Google infrastructure,' Wayner writes, adding that Google Compute Engine is just one part of the Google APIs portal, a grand collection of 46 services. 'I suspect many developers will be most interested in using Google Compute Engine when they want to poll these Google databases fairly often. While I don't think you're guaranteed to be in the same zone as the service you want, you're still closer than when traveling across the generic Web.'"
You know, for when they shut it down?
What we truly need is a comparison chart of some kind, to show us what Google's offering is different from the others
Muchas Gracias, Señor Edward Snowden !
n/t
...speaking for myself, and I don't know how many others reading might feel the same way, but $175 per machine per month (or however it's calculated, I only skimmed TFA) seems a little steep.
Right this very minute I can fire up eight cores with combined RAM of something like 14.5GB - notwithstanding the fact that we're talking six machines (four laptops (two dual core - one Atom, the other AMD E350, and two P4/2.0 and 1.6GHz), two desktops (one P4/2.66, the other an AMD Athlon64/2.4GHz), it's very scalable depending on what I'm doing and how fast I want it.
OK the Pentiums are *old* but they're still functional in a practical sense. I have older machines tasked for different things (a Thinkpad 760C running as a print server, for example) but I tend not to count or include them in my total computing power - they would suck up more in overhead than they would produce. Long gone are the days when a Pentium 120 made any sort of significant show in one of my clusters!
About my only limitation is the number of available power sockets. Cue the arguments for cloud utility with the cost of domestic electricity supply. The key word here is domestic - I have complete control on how much power is used. My AMD laptop at full draw drinks 3.5kWh per week if I leave it on crunching 24/7. That's equivalent to £1.78 per month - or around 1/100 the cost of a single core on a cloud node.
Operation Guillotine is in effect.
Corporate speak and technobabble buzzphrases pass as 'in depth' on Slashdot now? Wow.
I can't belive Azure wasn't even mentioned. By some estimates it now holds more objects than Amazon (since iCloud and iTunes are hosted there).
Comparisons to Amazon EC2: 9
Comparisons to MS Azure: 0
Microsoft is more evil than Google ever was
If you actually try to find some info by googling, chances are you're shown only pages of spam sites like fixya, livestrong, about, and other bullshit-seo sites.
Time is ripe for somebody else to step up in search business.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
This one may work.
I was checking out the storage pricing, for example. Its 0.12/GB instead of 0.125 of amazon. If google does not do the "API fiasco", it will work. But as we all know, google and API is like chalk and cheese. Amazon is the king when it comes to accessibility.
But I am glad, because this means more competition. So finally I can start using cloud storage, in conjunction with cloud server for hosting my blog etc., Heck, I can set up a machine in US, and get US specific content using VPN. No more looking for ssh services
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
Google will fail utterly and completely at this.
Why?
Customer service. They have a horrible, HORRIBLE customer service record. They just simply are unable to do customer service.... and this product needs it.
Rackspace uses local hard drives on each machine - while Google use NAS network attached storage. So Rackspace your hard-drive accesses (database accesses) are going through a SATA controller or such - and with Google your accesses are going through a network controller which is much slower. Makes a big difference especially for database driven apps such as all websites are these days. Are Google's hard drives accessed locally over a SATA interface or over a Network NAS interface? I would think that local storage is always better? See here for stats: http://blog.cfelde.com/2011/05/performance-rackspace-cloud-vs-amazon-web-services/ >>> "And this is where the first big difference shows. From my understanding, Rackspace uses RAID 10 with locally located hard drives... EBS on the other hand is network attached storage. So the first test is raw write speed. Using the dd command as shown below, running it three times in a row on each server gave the following results: Rackspace having an average write speed of 290 MB/s and Amazon only 81 MB/s. "
Amazon AWS also offers 'ephemeral' storage, which is a local disk. However, it gets deleted when the instance goes down. Also, might need to check the speeds on the newer EBS "optimized" instances (same rack or something w/ less latency).
I worry about price comparisons with RackSpace as well, as they used LXC for virtualization last time I checked, this allows for far more over-allocation of resources than Amazon's AWS and could lead to less *predictable* performance (and predictability can be valuable).
This is because AWS uses Xen underneath (and that doesn't allow for over-allocation of resources like RAM)
Google Compute Engine isn't a "response to AWS and Rackspace".
Google Compute Engine is a the IaaS offering in Google's cloud services, which is a direct competitor (and arguably "response") to Amazon's EC2 (not AWS as a whole) and RackSpace's Cloud Servers offerings.
The closest Google has to an competitor to AWS as a whole (which is the umbrella under which Amazon offers EC2, SQS, SNS, S3, Elastic Beanstalk, etc.) is the Google Cloud Platform (which is the umbrella under which Google offers Compute Engine, App Engine, Cloud Storage, BigQuery, and some other services.)
Rackspace's list of services is a bit different, and while Google has offerings which compete with most of them on some level, there's no one Google umbrella (other than just plain "Google") that takes in the offerings that compete with Rackspace.
I'm pretty sure that the "local disk" (lifespan scoped to the instance) for each machine level on Compute Engine is, indeed, local disk; the optional "persistent disk" is probably NAS.
Most applications are not ideal for Compute Engine and similar services which charge a premium for enabling dynamic server provisioning where you can rapidly change the number of servers available and are charged by the hour.
I'd be surprised if that's true on either Amazon EC2 or Google Compute Engine, which don't have fixed (either overall or per-instance) bandwidth caps, though its conceivably possible that the either the local network resources available to an instance or the total network resources available to the Amazon or Google server farm involved could become saturated. But, in any case, applications that aren't concerned about CPU scaling aren't really the motivating use case for these services. So assuming this statement is true with respect to sites hosted on EC2 or Compute Engine, all it means is that, if you are just looking for web hosting, you probably want to use a web hosting service, not EC2 or Compute Engine.
Neither EC2 nor Compute Engine is necessarily ideal for this. That's not the point of these services. There for scenarios where you need to spin-up/spin-down processing capacity in respect to demand, which is typical in apps that don't merely host content for consumption but do some heavy duty processing on data that they receive. You might also host the web servers providing the UI on the same service, but if all you are doing is boring hosting of web content without heavy processing, you probably want a service that is optimized for that kind of workload (or, at least, not one that is optimized for a very different kind of workload.)
You seem to complaining that a jackhammer makes a bad screwdriver. While this is true, the purpose of a jackhammer isn't driving screws, so its pretty much irrelevant to what a jackhammer is for.