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.'"

Comments

The real question

[Anonymous Coward]

How long until Google cancels it?

Re:The real question

[Anonymous Coward]

Probably long before you csncsl your trolling. Sadly. Why troll, man? Nothing better to do?

Re:The real question

[EdIII]

How long until Google cancels it?

Not exactly trolling. Google has never done very well in the support and consistency department. Having to deal with the YouTube API has given me some insights into just what a PITA it is to deal with Google on an ongoing basis.

Google has never really been shy about pulling the plug on a project either. Which is what almost everything seems to be to them. At some point you have to let a project die, so I can't really blame them for being conservative with resources, but it does not help the people that started to rely on it.

All that being said though, I think it is a pretty good assumption this will be a paid offering, and as such will not have the plug pulled. Certainly, not before migration plans could be made.

Re:The real question

[eric_herm]

Especially with product like deltacloud ( http://deltacloud.apache.org/ ), and the fact that there seems to have no specific API or products , ie, that's just centos and ubuntu servers. You can deploy your code everywhere, it doesn't use specific google stuff ( unless you want to, but that was already the case before ).

I have yet to see how far this will go. They will surely have people because that's Google, but I wonder if they do not simply aim to attack Amazon directly at the important point, the purse. AWS give them recuring money, and permit them to negociate good deal regarding to traffic, Amazon reuse android to compete againt google play ( by directly asking to publishers ).

Re:The real question

[Snaller]

If you rent all the cores for a day that is more than 2$ million - if somebody pays for that, they are going to keep them running ;)

Re:The real question

[DragonWriter]

All that being said though, I think it is a pretty good assumption this will be a paid offering

Given that they announced a pricing structure, its more than just an assumption.

and as such will not have the plug pulled.

That it is a paid-only offering, that it is not a blue-sky project like Wave but something that fits a well-known, established commercial market, are factors that suggest it isn't likely to get the plug pulled quickly (as is the apparently pretty serious pre-open-launch private partner work that went on with it.)

Re:The real question

[Anonymous Coward]

And yet, here you are

Encryption detail?

[prestwich]

It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?

Re:Encryption detail?

[davester666]

No keys, they use ROT-52 for extra security while still enabling excellent throughput.

Re:Encryption detail?

[Anonymous Coward]

Little known fact: ROT-52 encrypted data is susceptible to both chosen plaintext attacks and decryption with the weaker ROT-26 standard.

Re:Encryption detail?

[Anonymous Coward]

That's why you should use several iterations of it. ROT-52 may be simple, but 16ROT-52 takes 16 times as long to decrypt.

Re:Encryption detail?

[cbiltcliffe]

But it's also completely forward compatible with the rock-sold ROT-910 standard.

Re:Encryption detail?

[Animats]

It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?

That is exactly the right question. If the encrypted data is worked on in the "cloud", the encryption keys have to be accessible to Google's servers. It's possible to have a remote backup service where the service doesn't have the keys. (iDrive claims to be such a service.) But if the data is processed in the "cloud", the keys are in there somewhere.

Re:Encryption detail?

[thrillseeker]

Ah yes, the old military-grade ROT-13 - damn good stuff, that.

Re:Encryption detail?

[PTBarnum]

I haven't seen any technical details yet, but I'd guess that the advantages of encryption would be (1) fewer people at Google will have access to the keys than to the data (2) an outside attacker who gets access to the raw data also needs to attack the key store (3) if by malice or mistake a disk is not properly wiped before being removed from the data center, it will be harder to get data off of it.

It's hard to see this as being worse than no encryption; even if it is easier to get the key than to get the encrypted data, you still need both to do anything with the data.

Re:Encryption detail?

[dolmant_php]

I attended the tech details IO session (https://developers.google.com/events/io/sessions/gooio2012/313/ - as of this writing, the video isn't up yet), and they said the encryption keys don't leave the server where the data resides.

Re:Encryption detail?

[gl4ss]

well.. so? they're on the server the data resides on all the same. wouldn't it be nicer if they weren't on that server, since if they're on the same server what's the fucking point??

Re:Encryption detail?

[John Bokma]

It might be very well the case that in a lot of situations that's way more secure than having their customers storing the key somewhere "safe".

Re:Encryption detail?

[History's Coming To]

That's why they don't use it, they shave Brin's head, tattoo the data into his scalp, and then when they need to retrieve it they shave him again and read it off. This way not even Brin can read it, because he'd need a mirror and it would all be reversed.

Re:Encryption detail?

[MikeHalcrow]

I designed and implemented the disk encryption component of Google Compute Engine. (Trivia: I also created eCryptfs, which backs the home directory encryption in Ubuntu and provides local cache encryption in Chrome OS). PTBarnum outlined some good motivators for why cloud providers should encrypt all data-at-rest, even though they (necessarily) manage the key material. Additionally, it turns out that some customers' regulatory requirements can be met by encrypting all data as it crosses the guest-host VM boundary on its way to storage.

Re:Encryption detail?

[MikeHalcrow]

It's interesting them doing at-rest-encryption - now I wonder where the keys are stored and who has access to them?

The Google Compute Engine FAQ sheds some light on these details: https://developers.google.com/compute/docs/faq#disks

Can I retrieve ephemeral disk data if I have lost it?

No. All data written to ephemeral disk is encrypted with a key that is unique to the VM instance. By design, once a virtual machine terminates, all data on the ephemeral disk is lost.

Re:Encryption detail?

[joebeda3]

I'm the TL for Google Compute Engine and was the speaker at that talk. The answer is a little more subtle than that. We have two types of mountable disk -- ephemeral disk which stays on the physical machine and never leaves the machine and persistent disk that outlives an instance is written over the network.

For ephemeral disk, we generate the encryption key on the host machine and it only ever stays in memory. We are careful to control the code paths that see the key material.

For the persistent disk, by necessity, we need to manage the key as part of our overall virtual machine management infrastructure. We utilize some strongly audited and auditable systems to wrap the encryption keys and really lock down the users that have access to the unwrapping service. The name of the game here is to restrict the scope as much as possible.

BTW -- the video for the talk isn't up yet but I just shared the slides here: https://plus.google.com/110707185519531431463/posts/EfDCBjuPiPf.

Re:Encryption detail?

[uncqual]

(iDrive claims to be such a service.)

I tend to take claims iDrive makes with a grain of salt given their approach to "security" on the client machine. If, on a Windows iDrive installation, one looks at (for a typical installation) C:\Program Files\IDrive\UserName.ini, one finds a line of the form:

Encryption password=Vjku_Ku_Oa_Rcuuyqtf_CCCDDDEEE

Of course, not to worry, the password is well encrypted with a sophisticated algorithm. Yes. ROT-2 for alpha characters. Really.

So, this user's actual encryption password is: This_Is_My_Password_AAABBBCCC

I understand that some people want the convenience of not having to enter their encryption password (or, even, a password vault password) when using the service or at system boot or user logon, but there seems to be no way to 'opt out' of this convenience.

I assume the engineers at iDrive used ROT-2 as a joke instead of putting the encryption password in clear text. I'm not a humorless guy, but there's a few areas that I don't like joking about -- and security is one of them. Unfortunately, this unfunny joke decreases security because it slightly increases the chances that some users won't realize that their encryption password is sitting in (almost) cleartext on their local disk and they won't protect it well (most users, of course, would have no idea this file even exists).

Since iDrive seems to think that security is something to be "funny" and "cute" about, I question their general judgement on the topic. (Of course, it's possible that they are incompetent and don't do security reviews -- I suppose that's worse).

Re:Encryption detail?

[justforgetme]

Still a no go, the thing with cloud solutions and encryption is that: You are ok with the Infrastructure owner knowing what gets into your machines (usually the http traffic) but you don't want them to know what state the machines compute/store. If the encryption is handled by the Infrastructure owner and not you it is as good as nonexistent.

This is a typical showoff move to get the idiots yeling: "Teh googl claud incrypts u d8a withaut prosissin penaltee"
Shame on you Google, first actors/models for the commercials and then outright lies about infrastructure?

Re:Encryption detail?

[justforgetme]

Wouldn't it just be better to allow the VMs to handle the persistent store keys themselves?
Like key passing at launch etc? That way only the owner of the VM and the VM itself would have access to
the persistent storage keys.

Re:Encryption detail?

[Anonymous Coward]

YAWN.
The last time I found this funny was probably somewhere in the mid-nineties.

Re:Encryption detail?

[Anonymous Coward]

(iDrive claims to be such a service.)

I tend to take claims iDrive makes with a grain of salt given their approach to "security" on the client machine. If, on a Windows iDrive installation, one looks at (for a typical installation) C:\Program Files\IDrive\UserName.ini, one finds a line of the form:

 
Encryption password=,,,,,,,,,,,,,

Of course, not to worry, the password is well encrypted with a sophisticated algorithm. Yes. ROT-2 for alpha characters. Really.

So, this user's actual encryption password is: **********

That's so weird. I just see commas when you posted the contents of your .ini file, and then performing a ROT-2 on it makes it all asterisks. How neat that it protects your data! Try it again with your bank password, friend.

Re:Encryption detail?

[Anonymous Coward]

It's up to you to make sure your system is using encrypted inputs and outputs, there is no way for Google to do that for you. This service is equivalent of encrypting your filesystem, and is a lot easier to manage if you can live with the fact that the key is managed by Google as well.

Google LAN

[roman_mir]

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.

Re:Google LAN

[Anonymous Coward]

Google's been buying dark fibers since at least 2005. So, they likely do have the capacity to do this in a lot of areas.

Re:Google LAN

[symbolset]

Google owns vast amounts of fiber, and peering points too. They saw this as an essential strategy early on to avoid getting locked out of the Internet and to save on costs, as their data transport needs are immense. They could probably stand up an Othernet the size of the Internet if they needed to.

Re:Google LAN

[ibsteve2u]

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).

Prodigious thinking...maybe Google could call it something like Prodigy ?

Me, I see what's happening - the privatization of the internet - as "the glass house" dragging itself back into the world as zombies. Really bloodthirsty zombies.

Re:Google LAN

[Trepidity]

That's why web neutrality is a nonsense concept from my perspective - if companies can build their own infrastructure

The problem is that it's really only a handful of Google-sized companies who can do so. The worry with net neutrality is that the traditional ability of smaller players to participate will be eroded, if you can no longer buy access to the internet as a leaf node via an ISP, and then have your traffic treated equally once you're on the network.

Re:Google LAN

[PTBarnum]

I don't quite get the "single network from a programming point of view" part. No matter whether over a private or public network, there are likely significant latency differences between networking in a single data center, in a single city, or across the world. Surely you need to be aware of the difference when you are building large-scale applications?

Re:Google LAN

[Anonymous Coward]

I'm betting that single network from a programming point of view = everything is on a single subnet.

This means A) you don't have to deal with a router inbetween your nodes, and because of that B) nothing is modifying your traffic in between, because there is no need to. No internal NAT or other silly stuff, just send data to destination, destination gets it.

Also since Layer 2 is accessible to you, you can use broadcast and multicast protocols which can be used for services to autodiscover or failover.

Presence of a router between A and B is usually, but not always indicative of lower latency. Particularly when bridging VPNs are involved.

Re:Google LAN

[s73v3r]

if companies can build their own infrastructure, they can compete with each other and offer their own content at better speeds

The point behind net neutrality is that is a pretty big "if". And very few companies are the size of Google.

Should some random podcaster be expected to build their own infrastructure in order to get their content out?

Why encryption?

[Anonymous Coward]

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?

Re:Why encryption?

[am 2k]

I assume the buildings are secure, right?

On what grounds do you assume that? Jurassic Park-style 20m tall high voltage barriers around them and a ground-to-air missile defense systems?

Even then, I guess that some humans are allowed to enter the buildings without deathly harm. As soon as the human element is involved, security cannot be guaranteed.

Re:Why encryption?

[Jeremi]

On what grounds do you assume that? Jurassic Park-style 20m tall high voltage barriers around them and a ground-to-air missile defense systems?

Unlikely, that sounds more like a Microsoft thing. I imagine the Googleplex is defended mostly by machine-gun turrets, moving platforms, and an all-seeing but emotionally unstable AI.

Re:Why encryption?

[Noughmad]

I imagine the Googleplex is defended mostly by machine-gun turrets, moving platforms, and an all-seeing but emotionally unstable AI.

No, that would be Valve HQ. Google just shows you random YouTube comments.

Yes, they do own massive fiber

[sirwired]

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.

Uh

[drinkypoo]

Doesn't Amazon run on its own cloud services? Wouldn't that make the first point (FTFS) irrelevant by way of comparison?

Re:Uh

[ibsteve2u]

Yeah, Amazon does...and they'll let you download the "howto" for their cloud as free ebooks, too.

Re:Uh

[ThatsMyNick]

Er, did you just link to their cloud user guide and even state that it is free. Did you expect them to sell documentation and make money out of it?
 
Or did mods (myself included), miss a joke?

Re:Uh

[ibsteve2u]

lolll...if you haven't run into a vendor who expected you to buy their product and the documentation for it yet, you're lucky. I've been having to pay for documentation from the likes of Oracle/DEC/HP/Microsoft/etc. etc. etc. etc since...well, since some of them were founded.

My favorite example would be buying the documentation for a Tandy 1000 TX to find out why it wouldn't go into protected mode only to discover that the mobo showed an undocumented chip codenamed "Midnight Blue" on the schematics.

how about I/O performance

[Trepidity]

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?

Re:how about I/O performance

[Anonymous Coward]

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?

Do you mean the IO performance of their "Persistent Disk"? It would be interesting to know as well (are there numbers publicly available), but again, it would be performance with the data encryption, compared to non-encrypting EBS.

Re:how about I/O performance

[MikeHalcrow]

but again, it would be performance with the data encryption, compared to non-encrypting EBS.

This is what RightScale, an early Google Compute Engine customer, had to say regarding encryption and performance: http://blog.rightscale.com/2012/06/28/rightscale-joins-google-compute-engine-for-launch-day/

One very aggressive innovation that Google Compute Engine brings to cloud computing is encryption of data at rest, both for local ephemeral drives as well as for network attached drives. In the case of the network attached disks the encryption happens on the host before it is put on the network, so it’s also encrypted in transit. The encryption is on a per-project basis (Google’s term for an account). This is a big deal for security conscious organizations, especially those having regulatory or other mandates to encrypt all data at rest. On other clouds one solution is to run a loop-back crypto driver, but that eats into the VM’s performance. I’ve been benchmarking the Google Compute Engine disk performance (more on that in a future post) and the encryption doesn’t seem to have a noticeable impact on performance. Pretty awesome.

De-duped?

[Anonymous Coward]

Is Google de-duping?

http://en.wikipedia.org/wiki/Data_deduplication

if yes, then encryption is joke.

Re:De-duped?

[allo]

what has a virtual machine to do with de-duplication? right, nothing at all.

I sure hope businesses and people are smarter/

[santax]

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.

Re:I sure hope businesses and people are smarter/

[santax]

*to *mind, why don't I ever proofread my shit. Sjeee.

Re:I sure hope businesses and people are smarter/

[dkf]

When you use an US-based company to trust your data too, you are a fool.

More to the point, they don't have any non-US zones, nor do they mention any plans at all to change this. OK, such a rollout is not trivial since it can't just be done by freeing up server space; they probably have to alter their corporate structure as well so as to limit the amount to which the non-US operations arms can be pressured by the US government via the parent. If you've got a legal requirement to keep your data out of the US, GCE is not for you. Amazon have had this addressed for years.

Not cost competative

[Anonymous Coward]

Looks like they took Amazon's prices and said "me too!"

I can't ever take this cloud stuff seriously. The cost of bandwidth and the cost of compute time is far far far more expensive than it needs to be. Prices should be going down instead, everyone just copies Amazon's prices. I'd say there was widespread collusion if it wasn't for the fact that no serious company would use it.

Whoa... did I say no serious company?

Let's look at the numbers:

The cost of 100Mbit Unmetered (33TB of data) is 200$/mo, the cost of 33TB at Amazon: 3346.14/mo
The cost of a 8 core system is 2000$,once. the cost of 8 CU's at Amazon is 0.64/hr, or 460.80$/mo
The cost of a 42U cabinet and 15A power, 600$/mo

So cost to have a 42U cabinet with one 8-core machine is at most 800$/mo, while EC2 will cost you a minimum of 460.80$ if there is ZERO data usage, or a maximum of 3806.94/mo

But you have an entire 42U cabinet with 15A, so let's put 4 8 core systems in there.
Initial investment is now 8000$
Maximum cost at a colo, still 800$.
Cost at Amazon with zero data: 1843.20
Cost at 33TB: 5189.34$/mo

Amazon's cost efficiency is only seen when no data is included, let's use the "heavy usage reserved instance" instead: 130$/mo (on 1 year) per 8 core system.
4 of those = 520$/mo , just squeeks under the cost of colocating 4 machines. But still the data cost is absurd. Plus we haven't looked at EBS IOPS and ELB cost.

Using AWS's own calculator, it would cost you 4291.94$/mo to get 800$ worth of services.

So yeah, if you use CPU-only, EC2 is cheaper than buying hardware that may sit idle. But running a web service or any data-transfer heavy process pretty much a losing proposition. Netflix had to be losing money by the boatloads.

Re:Not cost competative

[icebraining]

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.

Re:Not cost competative

[foniksonik]

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.

Re:Not cost competative

[DragonWriter]

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.

Who Holds the Keys?

[fast turtle]

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.

Who is the troll?

[nurb432]

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.

Re:Who is the troll?

[icebike]

Actually, its not a valid concern.

Google shuts down projects that have no clear path to making money, like Wave, Buzz and Others.

As far as I know none of these had any monitization mechanism other than pushing ads in your face.

Compute has a price schedule published right up front, and its about the twice the cost of the electricity to power a comparable computer, but with zero capital investment. Their data storage prices and bandwidth prices are also published, and are reasonable. You really couldn't afford to even put your legacy machines into production at these prices.

Clearly they expect this project to cover its own costs, and make use of excess capacity in their data centers.

Google can build a processor in house cheaper than Dell or any white-box company. With a gazillion of them on hand, they can provision them fast, swap them in when there is trouble, and they do it day in and day out. So chances are they are simply reselling the in house expertise they already have. None of this is going away any time soon, and they always need to maintain excess capacity for their own needs, so why not market that.

With a clear path to making money on this project baked in at the start, the only thing that would kill it is lack of customers. Hell I'm thinking of renting a couple cores just for playing around with.

Re:Who is the troll?

[xswl0931]

With Google's current pricing they will likely lose money until the achieve enough regular income to cover the costs of acquiring hardware, powering them, and supporting them. I don't know how many customers it'll take before Google breaks even and starts making a profit, but it's probably not a small number. So even though Google has a plan to monetize this, there's no guarantee they'll make a profit (otherwise Google App Engine would be expanding), and no guarantee they'll keep dumping money in an unprofitable side business. Given their track record, I may try them out for some capacity while keeping most of it in EC2 or Azure.

Re:Who is the troll?

[icebike]

there's no guarantee they'll make a profit (otherwise Google App Engine would be expanding),

Wait, they just introduced this last week, and you already know that its NOT expanding? Clairvoyance?

The pricing is not all that dissimilar than EC2. Its less, but not orders of magnitude less.
This is not the sort of thing that requires a huge customer base up front. They have the luxury of throwing a few hundred virtual cores at this, or maybe a million. They have the hardware sitting around. Sunk costs already spent. If it turns out to be as self managing as most of Google's system, it will require a few administrative employees to collect the money, provision the virtual machines, and a few techs to deal with problems. But I suspect they have been running this in-house for years.

Re:Who is the troll?

[eric_herm]

I tend to think that there is more support costs associated with hosting that with websites services. The user target is not the same, and people who pay will feel they need to be supported ( ie, when . Not to mention that there is much larger attack surface ith their vm than with gmail ( gmail being mostly run on the client, with know interaction and limited set of input, vs a vm where anything could happen ). There is also likely more pressure on google ( someone using google compute for spamming or warez, etc ).

So I guess they plan to support everything, but there will surely be some hidden costs they didn't planned sooner or later. And since they already reuse their internal expertise, they already got the benefit of scale, so they should IMHO not think "ok, we have no profit now, but with more users, we will be ok".

Re:Who is the troll?

[Anonymous Coward]

The list you link to is by no means complete. What about their subscription offering for publishers "OnePass". That lasted barely a year. No serious company can expect to role out and promote a product in such a short time frame.

As for Google track record for building cloud tools for developers -- have you already forgotten about App Engine's surprise price increases by as much as factor 10?

http://www.informationweek.com/news/cloud-computing/platform/231600672

When was the last time you saw Amazon *increase* their prices.

Re:Who is the troll?

[icebike]

The user target is not the same,

Exactly.

The targeted users of this service actually have a clue. Unlike web hosting service users.
You get a bare bones Linux Virtual Machine with a remote console. The clueless will
soon disappear.

Encryption

[nurb432]

Notice its encrypted by default. Not a real concern, other than downtime.

Re:Encryption

[icebraining]

That would only be useful if they couldn't get to the key as well, which (apparently) isn't the case here - it sits on the same machine.

Uptime

[tyler_larson]

As long as google doesn't completely fall apart for one week every year, they're pretty much got amazon cornered.

Re:Uptime

[Curunir_wolf]

As long as google doesn't completely fall apart for one week every year, they're pretty much got amazon cornered.

Not so sure about that. Now that Google has made massive changes to their policies, I think at this point Amazon clearly has them beat.

Re:Uptime

[Anonymous Coward]

So what you mean is that Amazon caters to the gun nuts better than Google does. I doubt there are a significant number of people who are bothered enough by it to let it influence their choice on something like this. Strangely if I click on your Google link, then click on the "shopping" tab I do get a selection of guns listed (although this is in the UK, so it is the UK Google shopping results, I don't know how to get Google to show me the US results these days).

Encryption in the cloud is worthless

[gweihir]

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.

Hope it avoids becoming spambot haven like Amazon

[smagruder]

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.

And the difference is

[WOOFYGOOFY]

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.

"Ephemeral" means "short-lived"... apk

[Anonymous Coward]

"ephemeral disk which stays on the physical machine and never leaves the machine" - by joebeda3 (2674569) on Sunday July 01, @06:43PM (#40512751)

You SURE about that? I know that you're the "Team Lead" (assuming TL = team lead) & possibly you helped to design this...

HOWEVER - the word 'ephemeral' means "short lived", & what you're describing ISN'T...

I.E.-> I drew that much from the end of that quote of your words (in "never leaves the machine")...

So I must ask for clarification now:

Did you mean

---

A.) "Nothing from it leaves the end-user's system"

OR

B.) That it NEVER leaves (& ceases existence)?

---

If the latter?? Then it defies the term you used to describe it!

* The reason I note this is because of "ephemeral ports" (short-lived) ones -> http://en.wikipedia.org/wiki/Ephemeral

---

PERTINENT QUOTE/EXCERPT:

"In computer networking technology, an ephemeral port is a TCP, UDP or SCTP port which is dynamically assigned to a client application for a short period of time (the duration of time the application is running). This is in contrast to the "well known" ports which are typically statically assigned to a specific application or service."

---

Ordinarily, I'm not a "grammar/spelling" nazi or otherwise a pedant, but that has me a WEE bit confused as to your meaning is all!

APK

P.S.=> Additionally, because of the meaning of the word "ephemeral" itself as well -> http://en.wikipedia.org/wiki/Ephemeral:

---

PERTINENT QUOTE/EXCERPT:

"Ephemeral things (from Greek ÎÏήμÎÏÎÏ â" ephemeros, literally "lasting only one day"[1]) are transitory, existing only briefly"

---

In ANY event? Thanks for clarification here, & good luck on your project... apk

Re:"Ephemeral" means "short-lived"... apk

[Anonymous Coward]

He means that it's gone when the VM is shutdown.

Re:"Ephemeral" means "short-lived"... apk

[Anonymous Coward]

You'd be best served looking at the quote of his words again then: "stays on the physical machine" & "never leaves the machine"?

"He means that it's gone when the VM is shutdown." - by Anonymous Coward on Monday July 02, @02:15PM (#40519259)

Those phrases are not "jiving" with that which you stated... (& ordinarily, I'd be inclined to agree with YOUR statement quoted above (see his vs. it, in my 'p.s.' below))...

That's SPECIFICALLY what had ME all like "WTF?"

* Thus, because of the above? Well - I think I'll wait out his reply & let him speak for himself... since it's BEST, imo @ least, to listen to "the horses' mouth", for explanations.

APK

P.S.=> Again, the quote for your reference:

"ephemeral disk which stays on the physical machine and never leaves the machine" - by joebeda3 (2674569) on Sunday July 01, @06:43PM (#40512751)

... apk

They need smaller and cheaper instances

[juanjux]

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.