I run goread (http://goread.io) on App Engine. Doing the math by hand, I'll get a 25% reduction in costs. This comes from cost reduction of instance hours and datastore writes, and free SSL and datastore small ops. I didn't get the advertised 30% because my largest single cost is datastore storage, which didn't drop. I'm happy with how this all went.
I saw another comment asking about app engine pricing. It is priced based on many different usages: instance hours (where instances are automatically added and removed by app engine itself), writes, reads, and storage to their NoSQL datastore (far and away its best feature, which no other provider in the world offers). They charged small amounts for other things, too. I was paying $9/month for SSL and other small one-offs. This new pricing basically eliminated all the other one-offs, making them free. It reduced the number of kinds of things that are billed. Before the datastore had 3 pricing tiers depending on the operation. They made the cheapest free and the other two the same price (reducing the price of the more expensive). Overall things got much simpler and cheaper.
The Google Storage pricing of $0.026/GB (or $0.020/GB for reduced durability) made my jaw drop.
I spend over $6k/month on Amazon S3, and this pricing from Google has me flabbergasted. Our architecture just uses S3 as a pluggable commodity, so a few hours of coding is going to result in a new $4000/month in savings from this announcement. Wow!
Your prices are off by an order of magnitude (correct prices are $0.026/GB and $0.020/GB), and the latter is "Durable Reduced Availability" [1] not "Reduced Durability". It is availability, not durability, that is reduced.
In our case, the vast majority of the data is not ever served up and is removed via lifecycle rules. However, just the fact that we have the data serves a number of our customer's use cases.
That's a part that also stuck out to me. With that kind of price, "online" storage is approaching what was previously only available in Amazon Glacier "cold storage" pricing. When Glacier launched, it was about a 10x difference between online object stores ($0.10/GB) and Glacier ($0.01/GB). Since last year it's been down to a 7-8x difference, and now it's down all the way to a 2x difference. Imo, that makes the number of use-cases where it's worth dealing with Glacier's retrieval model smaller than previously (effectively only those where you have a truly huge amount of data, such that the remaining $0.01/GB price differential adds up to meaningful money).
Full disclosure: I work for a competitor to both GCE and AWS.
tl;dr: Until the fundamental issue of trust is addressed, customers will applaud the price drops only because they look forward to AWS responding in kind, not because they plan to actually deploy on GCE.
In my experience, GCE has not been a factor in the public cloud market to date. They seem to have a fundamental misunderstanding in that they (apparently) believe their problem in the market is price when it's actually something much more basic: trust. After the abrupt deaths of services like Google Reader and Wave and surprises like the GAE repricing nightmare, customers simply don't trust that Google won't wake up one morning and decide that self-driving cars are actually a lot more interesting than running infrastructure-as-a-service -- and announce the death (or repricing) of GCE. AWS, by contrast, generates no such doubts: one can say what one will about Amazon (and there are certainly many reasons why I believe the future is not AWS's alone), but AWS services do not have a trust issue. (Or, to recast it in the aphorism once said of previous giants like IBM and Microsoft, no one gets fired for deploying on AWS.)
It will be interesting to watch the GCE announcement unfold, but previous Google announcements have lacked a critical ingredient: IaaS customers. (Amazingly, journalists don't seem to notice or demand this; smaller companies can't get away with this, but the aura of Google seems to give them a free pass.) If Google wants to really compete in this space, they should pull across a marquis commercial AWS IaaS customer -- at any cost. In doing this, they would probably learn both how profound the trust issue is -- and at the same time learn any remaining technical hurdles that they need to clear to really compete with AWS. There are several high profile AWS customers to pick from, but the obvious customer to start with is Netflix: they care about GCE's putative differentiators of price and performance -- and Amazon is a mortal threat to Netflix as a competitor, which should give some boardroom-level urgency to the discussion. Until Google gets Netflix (or an equivalent) on GCE, I don't think that the price drops will move the needle because they don't address the fundamental issue of trust. (Indeed, one could make the argument that they exacerbate it: if GCE is a money loser for Google, the feared slaying of GCE may actually be more likely, not less.)
Finally, if GCE can't get a marquis AWS IaaS customer, how about just a marquis Google customer? Knowing that new Google services are being deployed exclusively on GCE (by executive fiat if needed) may itself go a long way to make Google much more competitive in the space by knowing that GCE at least has the trust of Google, even if no one else...
First GAE was one price. We attended Google I/O session and learned about the virtues of fully using BigTable, so we wrote our application to be tightly integrated into GAE (stupid mistake).
Then GAE got a 10X (1000% percent) price increase. Effectively removing the service if you based your business on the initial pricing structure.
Now, google is talking about Moore's law and how the service should be cheaper.
Why do I trust google less? Because I don't get a feeling Google has any long-term strategy here. It seems like they're winging it every 6-12 months. In contrast Amazon and AWS have been steadily marching in one direction.
I want to like GCE/GAE, I still run services from it, it's good for some use cases. But in back of my mind, I know google can pull the rug at any moment, depending on the popular flavor of the month.
So what am I saying? Use it at your own risk. It's good for somethings but there are other solutions and there are businesses where cloud services is their main or only business. You know those guys will steadily innovate and build up their services.
I was such a big early fan of GAE, but I do remember so many people feeling burned by the pricing change and the terrible customer service. SSL was for me an important missing feature and I got a friend to walk up to one of the GAE guys at SXSW to ask him directly about SSL or SNI, but according to him it wasn't even on their public roadmap in March 2010. I see that Google product guy has long since moved on to Dropbox, but here's hoping Google is getting serious about throwing real weight behind some of these services and they provide great customer service from now on. Reminds me of this Googler's rant about Google's platforms versus Amazon's:
Another example of Google building whatever they want today instead of building what customers need right now. Same thing happens on Googles other product lines, so it's no shock.
Yeah, I don't see why would anyone wanted to lock in with them. With AWS and others, it's not that hard to switch if you planned for it. There are open PaaS solutions (or at least one), why not use those? If the provider screws you, deploy your own (or pay someone else do it).
I would not touch this with a 10-foot pole. A few weeks ago Larry Page was asked about "putting the user first" at TGIF. His solution to this problem is to go mobile only and dedicate 80% of the company's resources to mobile (at the expense of everything else)
Do you think Google is going to care about things like this with there new strategy? If you're business depends on any cloud provider do yourself a favor and go with AWS, you'll end up in a much better position then if you went with Google.
Like he's going to admit that after violating his nondisclosure agreement discussing Q&A at TGIF and disparaging GCE in public. Of all the things to discuss outside of work, the meeting that starts with a "everything you see, hear, and taste here is confidential as shit, man," slide...
Speaking from (direct personal) experience, someone that malicious needs to be identified quickly and removed, because that's without question not the only thing he's doing due to his disgruntled attitude. Nothing against him, just clearly Google has wronged him in some way and the responsibilities of his legal agreements are no longer important. That means it's time to move on before he harms the company.
Whenever I've spoken about my employment at Google -- even though I was fired inappropriately -- I'm careful not to divulge information that I promised to protect as it's important for my own integrity. And that's even when I have a pretty legitimate gripe with Google. Now that I'm with Apple, a company that ostensibly takes secrecy to an entirely different level than Google, I don't even discuss Apple in public. Ever. I know better.
I'd talk to Global Security about this if I were you since a case could be made that he tried to throw your LDAP under the bus.
Anyone can append a disclaimer to an anonymous comment claiming all sort of stuff.
Also one would expect Google employees to be smart his/her comment conveys the opposite: there is no inherent conflict between being mostly about mobile while providing developers with a backend on which to build their wares which are also becoming increasingly mobile.
There is a large amount of malice targeted at Google and much of it manifests in HN comments, as this threat would suggest.
I give it a little bit of stock because if someone came on HN and claimed "Larry and Sergey lit a pile of Bibles on fire and professed their love for Satan in front of the company," I'd be comfortable within the confines of my nondisclosure agreement saying that never happened even though TGIF is a confidential meeting. It'd have to be that ridiculous for me, but I'm sure the threshold for others is lower.
If "joebar" here completely made up the question and answer I bet one of the numerous lurking Googlers would have called him on it by now, even though it's a confidential meeting because (a) not everybody cares about nondisclosure to the same extent you and I do and (b) it's not like you're divulging corporate secrets, you're just saying that's a made up story. Pretty simple. "That story isn't true." Done. Legal gray area, but Google is pretty lax on social media until you fuck up.
I should clarify that it's probably a safe bet that the Q&A happened (and, honestly, sounds like Larry) but I disagree with the commenter's analysis.
> A few weeks ago Larry Page was asked about "putting the user first" at TGIF. His solution to this problem is to go mobile only and dedicate 80% of the company's resources to mobile (at the expense of everything else)
> Do you think Google is going to care about things like this with there new strategy?
Granting, for the sake of argument, that the story you relate is true, um, yes? One of the big things in Google's cloud platform push has been to build infrastructure that on which applications can be built for Google end-user platforms -- Android and Chrome. If Google was adopting a mobile-as-central-end-user-focus strategy, then backend services that support mobile development like Cloud Platform (and tools that rely on it like Cloud Endpoints) would seem to be rather important.
Probably not - Google is a big company and there are bound to be a number of employees not pleased with current direction at any time. It could be entirely personal reasons such as wanting to move to the GCE team but being denied because of a push towards mobile - maybe now he's forced to develop for Android and he likes iOS (if what he says is true, who knows?).
No need to go out of your way to provide rationales, this person is most likely misrepresenting himself.
Google employees are usually smart, this person isn't. I mean even at face value his logic is unsound: all mobile services are cloud supported, there is no conflict between being mostly about mobile and providing developers with a backend on which to build their wares, which in any case are also increasingly mobile.
> Google employees are usually smart, this person isn't.
I don't mean to sound crass, but if Google employees are so smart why is Google so collectively bad at doing anything right for an end user experience? Adwords does awesome, Google X has a mind of its own, but the rest of Google? The only thing somewhat decent that comes to mind is Calendar, Gmail, and the latest versions of Android.
Mind you, I'm a huge Google fan, but it (as an org) makes some pretty terrible decisions collectively.
It's not an individual that is making these decisions, it's a complicated set of groups, technologies, and directions.
Does that mean having bad user experiences is justified? No. But it's incredibly complicated to tie together such large projects (at a complexity most people won't fathom) and do it well.
I would look at it the other way and be amazed how good some of the things work.
Also, it's perfectly acceptable to enter new markets through acquisitions and apply Google's innovations there. That is a form of innovation in my opinion.
Oh come now, surely you can't be this ignorant of the way any company (of almost ANY size) works? Take Microsoft as an example: For the last decade, they've been the prototypical example of a dysfunctional company flailing around, and yet you'd have to be a complete fool to think that that suggests anything about how talented their engineers are (all the ones I've met have been exceedingly so). Ignoring all the layers between the intelligence of rank-and-file employee and the output of a corporation with ~50,000 employees and tying the two together is honestly just stupid. You even alluded to this with "(as an org)".
You're also hopping the goalposts around a bunch between revenue, success, and some subjective measure of "quality", but Android has over a billion activations, Chrome has three-quarters of a billion active users, GMail has 600+ million active users...again, one would have to be a complete fool (or a recent immigrant from Mars) to think that "only GoogleX and AdWords have had success".
By the way, in case you're planning to move the goalposts again to focus on only revenue, if you can't understand the concept of a product having monetary value without directly being a source of revenue, then I'm honestly just in awe of how little you understand how any of the industry works.
Ah, yes. Don't you love that we live in a day and age where you make a donation to a political movement and people who disagree with it call for your job? (A mainstream political movement, for that matter. Mainstream enough that they won.) Next step, I expect, will be the Spanish Inquisition. :P
... Sorry, everybody. I'd missed that one yesterday. :( We now return you to your regularly scheduled Google-skepticism
Disclaimer: I work on the Cloud SQL team, but everything here is a completely my own
FWIW, the Google products that are subject to the deprecation policy [1] will give a year's heads-up before they are shut down.
We aren't doing our job well enough if you can't easily transition off Cloud Platform (at least for the components that have obvious competitors... something like BigQuery is necessarily less simple). You should stick with us because you believe in the product, not some sort of lock-in, so you should find it easy to leave within that year.
As for whether that deprecation is likely, it would require a sea change. In the Wired article that came out yesterday [2], the quote is '“We will spend the majority of our development efforts on this New World,” wrote Hölzle.' And this is true, Google really is throwing Technical Infrastructure behind Cloud Platform. That's not to say Cloud Platform going away can't or won't happen, but I feel confident in my job sticking around.
The problem though is that if there is even a chance a service will be shut down (with a year's notice or otherwise) then on a financial basis alone, the cost savings up to that point will be drowned out by the switching cost.
I agree entirely with @bcantrill's comment. I look at Google's PaaS services with the very real concern that they may be switched off or changed at any time.
The reality of this is not just that it will have a financial cost but may well deal a mortal blow to the business. Unless Google makes a long term implicit (big customer) or explicit (rock solid 5-year SLA) commitment to these services they're just too risky to build a complex business on (unless it's a business which is enabled by the marginal cost savings).
Sorry but I have to disagree with this and the above. There is a fundamental difference in the Google Cloud platform which caters to (paying!) customers and has (paid!) support vs. a playground free service for end users like Google Reader.
The "meh" of GCE so far has really just been that it is behind the times vs. AWS kicking out new features monthly and is years late to the game.
When they keep adding features to their ecosystem (and driving down prices like the crazy cheap $0.02/GB cost of storage vs $0.68/GB for S3) usage will keep increasing.
I haven't had or heard of a single customer not choosing GCE because they are worried it is just going away, it is just lack of an ecosystem and knowledge/awareness from the end-user that these Google services are something worth looking at.
Well, here you go. I would never choose GCE, because I'd be worried about it going away, or Google increasing the price by some absurd amount with little warning and no feedback period, making my initial assumptions untenable, and leaving me to do a massive rewrite due to lockin on their proprietary features. Google did this with Maps (before backing off, perhaps due to backlash), and has done this with GAE in the past. Trust is a fragile thing, and hard to rebuild.
> I think the point is though that if there is even a chance that a service will be shut down in a year then even on a financial basis, the cost savings up to that point will be drowned out by the switching cost.
There is always a chance that a service will be shut down in a year no matter who the provider is.
Amazon has deprecated & disabled old API versions, SOAP & security issues and the like. I think they removed some of the old SimpleDB eventually consistent Query calls & made strongly consistent Select. Some of the regional API implementation around S3 and the original "us-standard" region were changed. But yeah, AWS has never turned off a service or major feature that I canrecall.
When was the last time Google Cloud Platform EOL'd a service? I mean, if you are asking about AWS and not Amazon, you should ask about Google Cloud Platform, and not Google.
Just so you know there is no such thing as "rock solid" with respect to legal contracts. There is always wiggle or weasel room. Better predictor is past behavior (which is what everyone is discusssing).
Not only that but a company like google has the finances to take any kind of legal action hit if they do decide to go against the contract even w/o a leg to stand on. And a band of users and a class action won't stop the process. [1]
Even Apple has in the past killed products (clones, xserve, newton for example). I remember specifically that a close friend told me that "they will never kill xserve" he was a big rep in sales and had tons of business in that area. Yet they killed it. Oh yeah mobileme also. I know I'm forgetting many other things.
While it's not unusual that companies kill products or services and there is never an explicit guarantee there are definitely companies that are more likely to do so if the product doesn't meet certain goals or fit in.
[1] Re-read this part. In other words promise one thing, do another thing, then simply clean up the resulting mess.
b) I think you should be able to migrate off the platform within that timeframe, and you shouldn't join our platform if you don't think we're making it easy enough for you to leave again (I deeply believe in initiatives like Google Takeout)
I didn't make any comment, nor will I, on whether I perceive that time frame to be long enough. I think it's smarter to stick to the facts when it's my own job I'm talking about. I would like to continue engaging with the Hacker News community (which, you'll see from my history, began many years prior to my joining Google) and offering context and information. But I can't do that if I don't stick to facts, lest my opinions be bent around to imply something I didn't mean that could put the job (that I enjoy very much) in jeopardy.
Someone at Google is making a big mistake here then. Enterprise can take a year to migrate off their current coffee machine. Migrating off their infrastructure provider is not something they are going to accept having to do within a years timeframe. Some of the QA testing these guys do can take over a year.
The reason Google's whole cloud division doesn't take off in the same way as pretty much everything else Google releases is because it feels like you guys have no idea what you're doing. Which is incredible considering you obviously know what you're doing - you keep Google running! Would you give your Search team 1 year notice to migrate all of their servers off their current hardware and datacenters to AWS or DigitalOcean? Obviously not, they would probably fire the lot of you and run it themselves. Why do you think other enterprises would think any differently?
I think it is pretty clear that keeping Google running has not helped Google to understand most enterprise customers. I think part of the problem is that Google IS a company that could decide to (and spend all the money and time) to migrate from one cloud platform to another if they decided they needed to. The margins are so big, the market share so dominant, the workforce so resilient and compliant, that they could actually turn on a dime. But most companies are nothing like Google, and their infrastructure products have not caught on in large part because of this mindset problem.
The Windows Server lifecycle comparison is interesting, but makes me curious about what Azure does, as a more apples-to-apples comparison. Is there some kind of guarantee of what notice you'd get before major changes or deprecation to services? I can't find one explicitly in some quick searching.
Azure in it's entirety doesn't (1 year notice of changes coming), but Microsoft has a separate "private cloud" IaaS offering, which has a similar lifecycle to server. This is definitely not my area of expertise, but the word I've heard is this is pretty attractive to the big businesses that are most worried about that.
For example, I know a major hospital/research center who has said that they will 100% never let anything onto the public Internet, but are about to clear use of a Microsoft private cloud.
>For example, I know a major hospital/research center who has said that they will 100% never let anything onto the public Internet, but are about to clear use of a Microsoft private cloud.
until they run a private fiber [which don't also have NSA's splitters attached] directly to the MS datacenter, they are being sold a snow in Antarctic [ie. mutually exclusive dichotomy between "100% never let anything onto the public Internet" and "use of a Microsoft private cloud"].
We are happy to talk about the actual location of your data for privacy purposes: http://www.windowsazure.com/en-us/support/trust-center/priva... I don't know how often this is actually done, but it's not out of the question that a large customer might prefer to run their own fiber to our datacenter(s).
As a Microsoft cloud services user, I know what metropolitan areas our services are hosted out of, and I believe that we can request a physical tour of one or more of those datacenters can be arranged. If you are a large customer, you can also arrange for dedicated connectivity to the Microsoft network via a peering connection.
Re the NSA splitter issue, that's just a reality of life. If you've run a large email, backup or similar system for a length of time, you've inevitably come across requests from law enforcement or litigating attorneys for data. So don't assume that nobody is accessing your stuff because it's in a room in your building.
Google understands on some level how B2B works ... for a while, they only made money through B2B channels, especially via sales of the Google Search Appliance.
I think that the people directing the App Engine lack a clear vision. They should know that price isn't what's stopping GAE. It certainly makes a statement about Google's vision for the App Engine if they have all of their good product people working on something else.
>Google understands on some level how B2B works ... for a while, they only made money through B2B channels, especially via sales of the Google Search Appliance.
during last 14 years i've worked in 3 BigCo's and 1 mid-size. The corporate portal search in all of them i can describe only using long sequences of Russian unprintable words. Google not being able to penetrate these companies when these companies have during last decade bought so much of other enterprise software, incl. a lot of junk, is a very indicative in my view.
>I think that the people directing the App Engine lack a clear vision
another possibility would be that they calculated how much it would cost Google to implement the AWS's level of features/support/quality, and thus how much they would need to charge to break even, and probably they just balked at it as it is hard to beat Amazon in margin/pricing business. I mean, all these anecdotal "horror" stories about overworked Amazon engineers vs. Google guys enjoying the life/work balance :)
We are building on Google App Engine. We have enough trust in Google that we aren't worried about App Engine disappearing. I think this trust deficit is mostly in the eyes of Google's competitors.
For my part, I was more worried about not being able to execute 3rd party modules that aren't supported on App Engine ... but even that apprehension disappeared with today's announcement of managed VMs.
App Engine is a no brainer for me now. The amount I save on not needing an ops team for a long long time overcomes any slight misgivings that Google might abolish App Engine in a few years. I don't think App Engine is going anywhere, BTW. You look at the number of languages they are adding, the number of people they are hiring ... to compare that to Google Reader is a bit ridiculous.
I've been working on AppScale (https://github.com/AppScale/appscale), the open source implementation of GAE, which implements the datastore API, along with most of the other GAE APIs. Your app is portable to any other hosting environment if the need ever comes.
Have you found the configuration in appengine where you can limit the number of instances? It is highly annoying to us that Google is happy to run unlimited instances (all of which benefit them financially) but provide no way for customers (we are on their Enterprise plan) to limit that. Heck they can't even show us what the various charges are and point to a third party chrome extension.
You can configure the metrics that cause a new instance to be launched. I forget where that particular setting is ... somewhere in the console I'm sure.
We aren't live yet, so I haven't needed to think about that stuff yet. However, I've talked to people that have applications live on App Engine, and that hasn't come up in conversations ... so there must be some solution ... if not the exact one you want.
There is no solution in the admin settings, nor according to their enterprise support. It is plain old tough luck.
The vast majority of our traffic is from devices that retry later if anything goes wrong. It is analytics information and hence there is no human affected by it.
Despite having identical settings and code across a number of appengine apps, we see variance in the number of instances they decide to run (eg they will start 4 at once even though only 1 is needed for the load).
At one point they were starting hundreds of instances due to some of our aggressive inter-app traffic (thundering herd problem). Things would have worked fine if we could limit the number of instances, but tough luck there. It required considerable engineering and tuning to make the problem go away that would have trivially been solved (in the short/medium term) by limiting instance numbers.
Hmm, you must be talking about something else, but there's a "min/max instances" slider in the console. I have set it to 1 for many of my apps, and they never go over 1 (or at least I don't get billed for it).
Do you have a link or some info about the languages they are adding? We're very curious over here--would love to know if they plan to add support for something we already have.
I don't have any links ... but Dart support is coming (already have Python, Java, Go, and PHP).
Also, with managed VMs you can basically run anything you want and still get Google to manage things for you. Manage VMs give you a sort of script you can define that apt-get installs the packages you need. You can also use Docker if you like to make your own VM images.
Haven't used it yet, but it looks good based on the demos. They showed a demo with Node.js today.
That is good news about Dart support, so I hope you are correct about that!
While no longer necessary because of managed VMs, it would be very good to have Ruby support also. I tried JRuby and Sinatra on AppEngine many years ago but the long loading request times were a killer. Plain Ruby and Sinatra would be good.
Anyone remember how Google toyed with the pricing on its Maps API?
In October 2011, Google upped its Maps API pricing to $4+ for 1,000 map loads [1]. Developers rebelled and switched over to OpenStreet Map [2]. Eight months later, Google dropped the price to $0.50 for 1,000 map loads [3].
I thought I recognized your name; you're the dtrace guy!
I know a group of engineers who work on a very high performance (500k ops/second) distributed system running on hundreds of nodes that have an unofficial church of dtrace. It's the debugging tool of choice for when weird shit happens.
That's very rewarding to hear! Fortunately, we in computing seem to have a limitless supply of weird shit -- I still use DTrace every day, and I continue to be surprised (astounded, even!) by the weirdness. By the way, those in the unofficial church of DTrace may also be interested in mdb[1][2], our postmortem debugger -- and the other half of the dynamic duo for weird shit debugging.[3]
do we really need to see a post like this for every submission on a Google service? It seems pretty obvious GCE is fundamentally different than something like Reader/Wave, both consumer products (not platforms), given away for free, and very far from Google's main focus (cloud computing)
they are obviously putting incredible resources into GCE - comparing that to some of their consumer app experiments is just ridiculous
it's not very obvious when you look at the amount of service specific code, training, and learning for developers and opps that goes into committing to one of these iaas providers
google appears to create products via the shit and giggles method, with concomitant level of (non)commitment. it's an incredibly fair question to ask if this doesn't move the needle by becoming a $1B+ business inside a year or two, is Larry going to more wood fewer arrows it out of existence? And what would that do to any company with a couple person-decades of work poured into gce apis and services and internal training
also, if larry where smarter he could directly address this, eg: "Come hell or high water I promise google will support this business for a decade"
This is very much our view. Google products are fine for home and non-critical use, but it's far too risky to rely on them when building something that one expects to have a long lifespan. Unless there's clear money in it for Google's advertising revenue, the chance of it being pulled is too high.
The trust issues go beyond what you mentioned. I have seen met people who's Google accounts have been summarily suspended without recourse for reasons unknown. No, these were not scammers trying to game the system. In all cases it was newcomers to the AdSense world who put up sites with Google ads. A few days later they got hit with full suspensions, no recourse, no customer service of any kind. These are honest people with honest brick-and-mortar businesses who definitely have not time to go on an ad clicking spree or anything like that.
The fact that Google does business as one might imagine an immature 13 year old might is troubling enough that I avoid them like the plague. The only service I use is analytics. Everything else is as though it didn't exist, docs, gmail, cloud services, etc. I don't trust them and I make it very clear to clients and associates that they should steer clear.
As you say, what I do like about Google announcing price cuts is that they are usually followed by AWS making adjustments.
If Google start behaving as adult responsible business people they have a shot at earning my and others' business. Until then I view them as teenagers more interested in popping zits in front of a mirror than adults conducting business in an environment of mutual respect.
Trust is one of those things that takes a thousand times more effort to earn back than it does to nurture and to keep.
In at least one customer I deal with Google services are not considered an option and Google is almost a bad word after a large (tens of thousands) user Google Apps roll-out was aborted - ostensibly due to a "So what? We're Google, that's how it is." attitude regarding what were perceived as minor problems.
Obviously, this is not exactly the same as a service being killed, but I think it speaks to same sort of distrust - a feeling that your needs as a customer are at Google's leisure.
Are you talking about Amazon Auctions or Askville?
If you had used any of those services, would you ask the same questions about AWS? The notion that any company would shut down a service handling billions of queries per day is patently absurd. Just because Google shut down some duds that you used doesn't make them any more likely to shut down their cloud offerings.
I agree, that trust is the real stumbling block for any cloud service today. When I read, that MS is just searching the eMail accounts of its customers, with some thin explanation, than the question arises, what will be with other (sensitive) data I store in any cloud service. Can anyone be trusted, or will I find today or tomorrow some obscure statement in the terms, that is a loophole to just inspect my information at will.
How can Google, MS or the other players know, that the customers don't infringe on their patents? Don't they have the right to inspect? (trust is good, prove is better ...) Or does just a lazy sysadmin sell my data in this moment to the competition?
I also wonder, if the price drops now are a reaction to a big trust-drop (also because of Snowden) by the users ...
I think, cloud based services are a good idea, but until such issues are addressed, I would really recommend to think twice, which data can go cloud.
The observation that Netflix's infrastructure relies on oe of their biggest competitors isn't one that had occurred to me before. Altogether a really interesting take on the situation.
In your opinion, which cloud providers are the most trustworthy? I see you comment about AWS being trustworthy, how do you feel about Azure, Rackspace Cloud, etc?
@bcantrill is the SVP of Engineering at Joyent. I don't want to put words in his mouth, but I'm guessing he would say that Joyent is trustworthy. He would then tell you to use DTrace.
Ha! So, I guess my disclaimers have been made for me. ;)
In terms of trust, I would tell you that trust needs to be earned -- and that it can only be earned one day at a time and that it can be frivolously spent away with a single bad decision. (Trust me that Joyent has learned this the very, very hard way.) So I would say that you should force anyone to earn your trust. That infrastructure is such a trust business is part of why I so fervently believe in open source as a business strategy[1]; companies can change (or be bought) and earned trust violated by a new regime -- but open source can always be forked and its communities liberated from such abrogations.[2]
So while I would (of course!) tell you that Joyent is worthy of your trust (and ask for the opportunity to earn it), I would at the same time say that the open source projects we lead (SmartOS, node.js and -- yes -- DTrace) are the components in which you can have absolute faith.
Really appreciate the open source software, but I recently had some trust issues with Joyent the service. Cloud servers switched from tiered transfer rates (with a generous free tier) to on-demand pricing, with only a month of notice. It wasn't possible to monitor one's own bandwidth usage before the switch, so we were caught off guard by our bill jumping by nearly 30%. It would have been more trustworthy to grandfather in servers started under the old pricing plan.
I hear you -- and trust me, this kind of stuff is awful because even when you're actually trying hard to not screw anyone, you still accidentally screw someone. In terms of this in particular: we did really try to roll this out without abrupt notice or unpleasant surprises, so I'm sorry to hear that we missed the mark with you. If it was more than just annoyance, feel free to reach out to me directly (my first name -- spelled correctly -- at joyent.com) and I'll try to right the ship.
Again, my apologies -- and to my point, trust is very hard to earn, and very easy (too easy) to piss away. :(
> one can say what one will about Amazon (and there are certainly many reasons why I believe the future is not AWS's alone), but AWS services do not have a trust issue.
... so far. Trust is fragile, it only takes one incident to completely take it away. Just because AWS hasn't faced such an incident so far doesn't mean they never will. And when they do, they will be at the same level of trust as Google. It can happen overnight.
Similarly, there is really no guarantee that Amazon won't decide to shut down AWS at some point in the future for some reason. The two companies are really on an equal footing on these two points.
Which is why I think the reasoning "GCE is not seeing traction because people don't trust Google" is flawed. There are several possible reasons why GCE is not growing fast and Google is slowly addressing them one by one.
Don't discount them, and don't think for a second that their competitors are magically immune to the flaws you are currently seeing in Google's offer.
Your "trust is fragile" thing is kind of the point. Of course Amazon can lose it, but they haven't yet. Any vendor might screw up. Google has, Amazon hasn't.
Moving from Amazon to Google (Play Movies & TV, YouTube [especially given the perennially rumored subscription service]) doesn't really move the needle very much for Netflix in terms of depending on a competitor. I doubt Google would get much traction with Netflix if they made that argument for migrating to GCE.
Every time someone hijacks a Google announcement thread doom crying about potential shutdown it gets under my skin, especially in this case when these “arguments” are so intellectually bankrupt.
If you are suggesting that GCE or the whole Google Could Platform endeavour is in anyway similar to any of the appendage service or features Google shelved over the years, then that calls into question the adequacy of your critical faculties or any vested interest you may have in undermining their efforts, and leading with a disclaimer doesn't take that option off the table.
There is also the argument that when Google deprecates something you are more likely to hear about it which creates the false impression that they depreciate more stuff or more important stuff than others.
The difference is that nobody ran their businesses on Google Reader. They won't just shut the service that thousands of people rely on to make a living, especially the one that's cash positive.
> They seem to have a fundamental misunderstanding in that they (apparently) believe their problem in the market is price when it's actually something much more basic: trust.
Trust is not the issue. Google wants to sell "management" while AWS (et al) are selling raw resources. To use Google Cloud you have to change or build your system for it, using new APIs, configuration systems, other managed services and even programming languages. Todays announcement was: you can have raw VM control with our management too! I don't see it being any easier now (even MORE options!) but I think they're on the right track. They need to make it simpler rather than cheaper.
For anyone planning to use google cloud storage as an s3/cloudfront alternative to host public content, pay close attention to request pricing. Retrieving an object through its HTTP url is considered a class B XML request type by Google Cloud Storage. That is 1.3x - 2.5x times more expensive than cloudfront and s3 respectively.
I don't understand why people expose files they expect to receive significant traffic on public buckets, instead of using a caching reverse proxy from somewhere with cheaper data transfer rates.
That's another point of failure. One of the use cases of cloud storage is serving static assets. "a developer could store and host media and other static assets for a web game in Google Cloud Storage". https://developers.google.com/storage/docs/faq#services
Due to their request pricing, serving static assets is significantly costlier than cloudfront since storage costs tend to be minimal
How does that help when your content is in Cloud Storage? Is there an app which serves content out of Cloud Storage and runs on app engine? (I haven't worked with app engine)
You can set caching headers on Cloud Storage also. But that doesn't help when
1. you have a large number of requests with cold cache
2. want the flexibility to keep cache time small. Unlike cloudfront there is no purge method in GCS. GCS doesn't guarantee to serve new versions until the old one's cache time has expired.
Its an interesting choice of battlegrounds. I find the infrastructure vs infrastructure wars fascinating by how Google and Amazon invested in them for their own businesses and are now productizing the 'remainders' and getting less and less for it.
> Google and Amazon invested in them for their own businesses and are now productizing the 'remainders'
This is a myth. Both companies created their infrastructure businesses as separate entities by leveraging their datacenter expertise, but they were not 'remainders'.
This is definitely accurate from an Amazon standpoint. AWS was created as a separate product/business. At present Amazon is undertaking an internal push to leverage the AWS business to replace some of their long standing (and aging) "private" infrastructure.
Very interesting, this doesn't match my experience, can you say more about how you reason to the claim that Google created a separate 'infrastructure business entity' ?
I am an ex-AWS employee. I can verify that AWS was founded as a new line of business using new servers purchased for AWS. The idea that AWS was started using Amazon's spare capacity is widely repeated but false. Amazon is definitely leveraging their expertise and not their physical machines. Source: I've seen the original pitch deck for Amazon S3.
Isn't it just common sense? The provisioning / capacity planning for a DC has to be done based on peak usage. The usage patterns of the core business and the hosted customers are almost certainly going to be the same -- there's going to be a trough in the night-time, and a peak in the evening. At the time when people want to buy resources, you'll have no spare resources to sell.
The only way the business model of selling spare resources could work is if you found customers with a different usage pattern to fill the trough. That's hard.
Yes, you can find some customers with time-insensitive batch processing that could be done during the night time. But Google and Amazon already do massive amounts of batch processing, and still won't have a flat utilization level over the day.
Or alternatively you could try to flatten out the diurnal variations by making sure there's no geographic affinity between users and the DCs. But that's suboptimal given intercontinental network latencies.
I get Amazon, and I've seen copies of the purported Bezos 'everyting must be a platform' missive, but when I joined the Google platforms group in 2006 and talked with Urs Hoezle about why all this infrastructure for search, we had a lot of interesting and far ranging discussions but he never said "Oh and we're going to rent this stuff out for money too!" Until the original AppEngine project, and that got a lot of push back and discussion inside Google about 'outside stuff' breaking out of the sandbox and into the Google infrastructure, providing outside access was generally viewed (in Urs' organization at least) as dangerous at best for very little value.
The Great Recession hit, Google stopped building infrastructure for a time and focused on utilization, which lead to some awesome improvements in cgroups and i/o scheduling and such, and only after that and some early successes of both AppEngine and other projects which were kind of like it but much less well publicized, did the idea start to be considered as something Google might actually productize.
I could completely see them building infrastructure at this stage which is purely for rent, they have the recipe for building data centers pretty well baked. But I have never heard it put that they started out with that in mind.
Thinking at Google has changed since you left. The more recent IaaS products from Google (from GCE onwards) have relatively little to do with earlier cloud initiatives like AppEngine, other than learning from their experience.
I hope so! :-) this is a pretty fast moving space and its been 4 years. My original question was around jedberg's understanding was that Google "...created their infrastructure businesses as separate entities..." which was different than my experience. I saw it as Google sort of backing into the business rather than creating a new business entity for it (like for example Enterprise was a separate business entity).
>Google and Amazon invested in them for their own businesses and are now productizing the 'remainders' and getting less and less for it.
Are the prices dropping faster than moore's law? The costs are dropping approximately with moore's law.
Edit: the interesting bit here is just how you lower your prices. In the VPS market, it is traditional to keep charging your customers the same, and to just give them more ram/cpu/disk/network. This is way easier on the bottom line, as your revenue doesn't fall (by much. Most people won't bother changing to a smaller plan, some will.) - in the "cloud" the tradition is a bit more consumer-friendly; the tradition is to just cut the price and hope the consumer will buy more.
Yes, the cost progression of storage is expressed by Kryder's law, and is actually faster than moore's law. (well, in terms of storage space, not storage speed.)
Of course, both are observations and not true laws; things will get interesting if/when the capital and power required per unit compute (or per unit ram or storage) stops dropping.
But, my point is that in the past, the costs involved in providing compute infrastructure has fallen dramatically over time, and most people expect this to continue, at least for a while.
> Yes, the cost progression of storage is expressed by Kryder's law, and is actually faster than moore's law. (well, in terms of storage space, not storage speed.)
In theory, not necessarily in practice. The Thai floods caused a multi-year pause in Kryder's law we're still recovering from. (I'm not sure how robust Kryder's law is - there's a lot less data and analysis of it than Moore's, since that's the famous one.)
I've been wanting to build a quick side project for a couple weeks, so decided to give it a try today and put it up in App Engine instead of heroku.
Put simply, App Engine has a higher learning curve. I remember using heroku for the first time a couple years ago, and it was smooth and seamless. Can't say the same about App Engine. Installation isn't a blink, docs are scattered around, and even a simple Flask app isn't straightforward.
I understand they might offer more features, better prices, so side-projects are unlikely their target audience, but nevertheless if they want developers love, it should "just work".
Long-time Appengine developer here. I'm glad that GCE is here now, because a lot of the criticism of GAE came down to people expecting infrastructure (and infrastructure prices) instead of a platform. A massively and seamlessly scalable platform.
Which brings me to my point: yes, GAE does have a steeper learning curve, but almost all of that is due to scalability constraints. If you think you will ever need to scale past one server, it's well worth the initial pain.
Or put another way, you get to choose between a small development learning curve at the start for a pretty scary sysadmin learning curve when you need to scale your app.
That's not quite a fair comparison. The $35.38 Google price takes advantage of their sustained usage discount, if the instance is running the entire month.
The EC2 price is the full rack rate. You can do better with a spot instance, or by paying up front for a 1-year or 3-year reserved instance.
It's still a stunning price drop from Google. And from my tests, the Google instances give a lot more performance than the supposedly equivalent EC2 instances.
For my projects, Google instances boot faster, have lower network latency, higher network throughput to storage, and more IOPS than EC2 "provisioned IOPS" volumes.
It's really amazing. I can snapshot a 1 TB volume in the US and start a new instance with it in Europe in less than 10 minutes.
There are quite a few cases where you can't or don't want to deal with your instance disappearing at any moment by design (spot) nor with an annual subscription though
I don't like having to commit to an entire year, but reserving that m3.medium brings the price down considerably.
Hopefully AWS will take a look at Google's automatic cuts and think long and hard about it. We're using AWS, but reservations are a constant point of friction for us.
DO is a completely different service. It's Apples to Oranges. You don't go with GC or AWS just for a bare-bones VM, you use them if you already use (or want to use) their greater portfolio of services.
If you are just using EC2 or GC for VM hosting, you are doing it wrong and are throwing away a lot of money.
Sure it's cheaper, but DO doesn't provide consistent performance or security. Look at their past security problems with users able to read others disks or performance benchmarks for proof.
Does anyone here have experience using Google's compute engine? In particular, I'm curious to know what the reliability is like, and how performant the storage is.
(I'm a Google employee, so take what I say with a grain of salt.)
I just took ownership of the godoc.org documentation service, and am running it on Compute Engine. It's been a great experience so far.
I've noticed a few benefits that Compute Engine has over EC2 (the other virtual machine service that I have used). The "gcutil" command line tool is more intuitive, Google's Cloud Console is more responsive than the AWS console, the general performance is better (especially disk and startup time), Compute supports live migration of running VMs (avoid downtime), and finally Compute bills by the minute, not the hour, so you can spin up a bunch of high-spec VMs for a quick test without running up big charges (I got a little burned by this with EC2, in the past).
Note that this is a year-old article. It also doesn't address reliability; it focuses on common performance benchmarks. The article links to a GitHub repo with some performance benchmarks you can run yourself.
My startup is probably going to use Google storage at this point. We are hosting video that only gets accessed a couple times, but needs to be available for 1 year, so the reduced storage cost is going to be big for us.
Google is about 2 years too late. Many startups switched to AWS in droves and never looked back. The failure is that Google would have to give away GAE, GCE and friends in order for folks to switch because the work to change stack tooling would be very costly.
Does Google Drive support symlinks (symbolic links) on OS X like Dropbox does? If so, I will immediately stop using Dropbox and switch to Google Drive, because it's now five times cheaper than Dropbox.
If and when AWS responds will be quite interesting. GCE launched with lockstep product offering and pricing with AWS. This is the first real movement away from that lockstep position. On one hand it is competitive, on the other hand does it speak to other underlying issues: maybe GCE uptake has not been as expected and needs to do something drastic to compete with AWS?
April 1st also happens to be the start of Q2. I think it's kind of nifty that Google is unwilling to let a non-vacation holiday only celebrated by a handful of countries (http://en.wikipedia.org/wiki/April_Fools'_Day) disrupt its product planning.
(It's also shrewd business, if its competitors have "Start of Q2" stuff they'd like to announce that they put off until April 2nd).
From the Google announcement, regarding AppEngine: "We've lowered pricing for instance-hours by 37.5%, dedicated memcache by 50% and Datastore writes by 33%. In addition, many services, including SNI SSL and PageSpeed are now offered to all applications at no extra cost."
Is this partially an attempt to throw a wrench in the gears of the Box IPO? If there's going to be a price war anyway, better to start it now and prevent a competitor from amassing a big war chest.
I don't understand how much Box is a (potential) competitor in this market, so could be way off base.
I don't see how Box could possibly compete on pricing with Google storage, considering the high volume of hardware purchases Google is doing and high volume discounts it's getting.
They only reduced the prices for compute engine, bigquery, appengine, and cloud storage which are developer oriented cloud services and therefore unrelated to box. If google beefed up google drive, then it could be an attempt to throw a wrench in the gears of box.
I personally think google has more incentive to do the latter. Millions of people and thousands of companies already use gmail. It'd be pretty easy to convince people to take those files they already send/receive using gmail and push them to google drive. Convincing hardcore AWS users to move to google app engine might be a bit tougher.
Both AWS free and GCE require a credit card before doing anything at all, so that's not a barrier.
As for the actual price... GCE's cost of .013c / hour is so tiny that I don't see how you can say it's a "huge deal".
You can spin up a GCE for 5 hours a day for a week to experiment and it'll cost you less than 50 cents. It's not quite free, but it basically is. As long as you're just playing around, always-on shouldn't matter so you can spin the server up to play, down when you're done, and thus pay almost nothing.
this is where, Google should keep focusing than going after and pursuing things which other people can do better. I meant I am a die-hard Apple fanboi, But If they launch a search engine, I am definitely not gonna switch at once.
Google is essentially a web-services company a SaaS at its best. Stay focused on these services, and keeping bringing awesome things like this.
PS: I'd love if they would drop Google apps pricing too ($5/user). Please Larry/Brin? and let's put a final nail into office coffin.
Has there been any talk of getting some of the holes in google's cloud offering filled? I would switch to google in a heart beat but I am using route53, SQS, cloudfront, glacier and VPC. That is a lot to be giving up. I also didn't see anything about any sort of health/service checking/alerting support, but I probably just missed it.
I saw another comment asking about app engine pricing. It is priced based on many different usages: instance hours (where instances are automatically added and removed by app engine itself), writes, reads, and storage to their NoSQL datastore (far and away its best feature, which no other provider in the world offers). They charged small amounts for other things, too. I was paying $9/month for SSL and other small one-offs. This new pricing basically eliminated all the other one-offs, making them free. It reduced the number of kinds of things that are billed. Before the datastore had 3 pricing tiers depending on the operation. They made the cheapest free and the other two the same price (reducing the price of the more expensive). Overall things got much simpler and cheaper.