Slashdot Mirror
Insights Into Google Compute Engine
snydeq writes "The Compute Engine announcement at Google I/O made it clear that Google intends to take Amazon EC2 head on. Michael Crandell, who has been testing out Compute Engine for some time now, divulges deeper insights into the nascent IaaS, which, although enticing, will have a long road ahead of it in eclipsing Amazon EC2. 'Even in this early stage, three major factors about Google Cloud stood out for Crandell. First was the way Google leveraged the use of its own private network to make its cloud resources uniformly accessible across the globe. ... Another key difference was boot times, which are both fast and consistent in Google's cloud. ... Third is encryption. Google offers at-rest encryption for all storage, whether it's local or attached over a network. 'Everything's automatically encrypted,' says Crandell, 'and it's encrypted outside the processing of the VM so there's no degradation of performance to get that feature.'"
How long until Google cancels it?
It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?
I found this to be an interesting piece of info
Even in this early stage, three major factors about Google Cloud stood out for Crandell. First was the way Google leveraged the use of its own private network to make its cloud resources uniformly accessible across the globe.
"When you create a Google Compute Engine account and use their resources," he said, "they provide a private network, a LAN of sorts that spans different regions. For example, if you set up an architecture to replicate a database from region A to region B, in the Google cloud, you don't need to traverse the public Internet to do it. You're using their private network."
How precisely that network is implemented (as its own private fiber or simply a very efficiently-routed VPN) is not disclosed by Google. But the key thing is that the whole structure is seen as a single network from a programming point of view. "This makes it easier if you're building cross-regional architectures," Crandall says. It's expected that Google will eventually expand Compute Engine to territories outside the United States.
- I really wonder if Google built (or bought) larges swaths of private infrastructure that is otherwise outside of the Internet, does anybody know?
Here is why I am wondering about it - Google as an ISP would then avoid outside costs to move its data, it's all internal costs, this turns Google into its own 'Internet' of sorts, Google only Internet.
That's why web neutrality is a nonsense concept from my perspective - if companies can build their own infrastructure, they can compete with each other and offer their own content at better speeds, but then Google could be an ISP that uses both, Google 'Internet' and external backend, but then on its own 'Internet', the content available from Google could be delivered at a higher priority and faster (and cheaper, because its internal costs, that can be managed easier).
By the way, there was a question in the story, asking why didn't Google provide this earlier. Well, maybe it tech wasn't ready or the business model wasn't there or maybe it's something to do with the government that wants to listen in on everything.
BTW., this is why such information should be made available, the speculation about the reasons for things like that could be worse than whatever the truth is.
You can't handle the truth.
Isn't that only usefull when somebody has physical access to the device, in other words somebody stealing physical storage?
I assume the buildings are secure, right? So what's the use?
Google, in a very forward-thinking move, outright purchased massive quantities of laid fiber at rock-bottom prices after the telecom crash that followed the dot-com crash. There was quite a glut of capacity that nobody needed at the time and had no use for. They picked up years and years worth of bandwidth expansion without having to go through all the trouble and expense of actually laying that fiber.
Doesn't Amazon run on its own cloud services? Wouldn't that make the first point (FTFS) irrelevant by way of comparison?
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Speaking of "Google I/O", how is the I/O performance on Google's offering? Is it any better than the, err, "not great" performance of Amazon's EBS?
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
When you use an US-based company to trust your data too, you are a fool. That data will become property of the US and they don't even have to tell you they copied it for reasons of terrorism-fighting (or on a much larger scale, economic espionage!). No one in their right might should ever use any system in the USA or belonging to USA companies to put sensitive or mission critical data on. It's the equivalent of riding the damn trojan horse into your own city and thanking them for the great gift.
what has a virtual machine to do with de-duplication? right, nothing at all.
One comment that immediately jumped out at me was the use of External Encryption to lighten the load on the VM's. If that's the case, what method are the using and who holds the keys? If it isn't the customer who's paying for that cloud, then it's useless for building any kind of service on as the data can easily be snooped on by Google. In other words, kill the project now because it will never be profitable.
Mod me up/Mod me down: I wont frown as I've no crown
Google has a clear track record of yanking the rug out from under people who adopt their non-core products.
Unfortunately it's a valid concern.
---- Booth was a patriot ----
Notice its encrypted by default. Not a real concern, other than downtime.
---- Booth was a patriot ----
As long as google doesn't completely fall apart for one week every year, they're pretty much got amazon cornered.
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
But if your service only needs a 4 core for 95% of the time, but it gets huge spikes those other 5%, you'd be wasting a ton of money keeping an 8-core twiddling its thumbs, while on EC2 you can scale just during those spikes, particularly if they're regular.
That's the whole point of "X-as-a-service" - getting resources on demand.
Of course if you can, putting the baseload on real server and using IaaS to handle spikes is probably the cheapest option, but it's far from easy unless your application is really simple.
Dilbert RSS feed
Big users rarely rarely pay the published rates. When a service wants the business they will customize the contract.
The big advantage of the Cloud is that it is a service, hence not capitalized and not subject to the accounting rules for capital expenses.
You are forgetting to include costs on both sides for an enterprise professional services agreement. Also you did not include the SLA details. This typically makes all the difference in pricing; Amazon, Google or Rackspace.
A fool throws a stone into a well and a thousand sages can not remove it.
The basis of your cost comparison appears to be comparing the cost of a server farm (and associated support infrastructure like internet connections, etc.) that is fully utilized 100% of the time vs. buying the same flat capacity from a cloud service whose main selling point is the ability to scale with demand.
Which, surprisingly enough, shows the fixed 100% utilized system (which is, of course, what the cloud provider has to have to sell the service in the first place) is less expensive than the cloud service.
The thing is, most real users don't have a bandwidth, CPU, or other resource loads such that a system set up to handle their peak need would be fully utilized 100% of the time.
And these people are truly unethical claiming anything different. Encrypting something before you put it into the cloud is another story. But the only use for encryption at rest in the Google cloud would be is somebody were to steal disks from their data-centers. Somehow I do not see that happening.
What they really intend is IMO to run a smoke-screen with regard to the fact that the cloud-provider is the real, major security risk and that no technological measures can help here, unless you do your own encryption before putting anything in the cloud and then only for cloud storage. Nothing at all can be done to secure cloud computing against the cloud provider. And Google is known to cooperate with the various authorities in the countries they do business in.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
My sites got hit so much from spambots originating from Amazon's cloud that I've had to block anything coming from it.
I hope Google does a better job at dealing with spambots originating from their servers.
Steve Magruder, Metro Foodist
I trust Google not to design in features that make it hard for me to leave, lie to me about how many CPU cycles or I/O I "spent" and just basically rip me off as much as they possibly can
http://blog.carlmercier.com/2012/01/05/ec2-is-basically-one-big-ripoff/
This is where founders matter. My idea of Google is geeks for the greater good of geekdom to the benefit of the long term good of society as a whole
Amazon fonder, CEO and billionaire many times over Jeff Bezeos "feared pirate Bezeos"
http://www.pcmag.com/article2/0,2817,2395122,00.asp
fought tooth and nail against Washington State establishing a state income tax so as to maximize his chest o' gold..
Go Google, the closest thing we have to a company who gives a shit about something other than more nose candy and ho's for the board and CEO.
It maybe cost effective considering the CPU/memory to cost ratio, but the smaller option they're offering with 3.75 "google compute units" is 104$/months if you have an usage of 100% (like the typical web server). An Amazon small instance for example, which is more than enough for the load of the majority of web servers is 58$/month, or 27.77$/month if you get a reserved instance (I have one for a webserver with about 2000 visits/day). A lot of people is even running webservers on microinstances.