Playing devil's advocate, what happens when the trust doesn't become restored?

The company loses ad revenue?

Developers flee in mass droves to...Yahoo and Microsoft?

Look what happened when people "lost trust" in Facebook. Shares are down 4% relative to a year ago. Is the company permanently crippled? Are people revolting and moving to alternate forms of social media? Fewer of the people immediately connected to your local graph are probably using Facebook. But that local loss of users gets completely offset by the new users they grow internationally.

Ultimately, these companies are beholden to their boards and shareholders.

Unless Inbox users clicked enough ads to make a dent in revenue, the organization has every reason to deprioritze competing products, and continue down the path of creating free A/B tests, and then merging the winner into a hybrid/better product.

Take a look at Fuchsia.

Or Dart and Flutter.

Or Hangouts and Talk.

An easy heuristic here might be, "Lose trust in the few in order to benefit the many." It sounds really sad, but it is the reality numerous companies live by.

Just 51% of US individuals aged 13 to 17 say they use Facebook – a dramatic plunge from the 71% who said they used the social network in Pew’s previous study in 2015, when it was the dominant online platform.

In this year’s study reported Facebook use was, according to Pew, “notably lower” than the percentage of teens who said they used YouTube (85%), Instagram (72%) or Snapchat (69%). In the previous study, just 52% of teens said they used Instagram, while 41% said they used Snapchat.

https://www.theguardian.com/technology/2018/jun/01/facebook-...

Being a social media user is age-independent, whereas one's teens is something they grow out of.

So, not only existing teens grow out of being teens (and eventually Snapchat users), but new teens won't necessarily grow into it to replace them.

Unlike older people, who value utility and what they already know more, new teens are just entering the social media field (and thus are more open to whatever might come next), and they are all about what's cool (so when a service loses it's cool it abandoned MySpace-like fast).

"More than 1 in 4 American users have deleted Facebook, Pew survey finds"

https://www.washingtonpost.com/technology/2018/09/05/more-th...

And is there really a generation of new users ready to take their place? I'm not sure:

https://www.independent.co.uk/life-style/gadgets-and-tech/ne...

No tech company of this size dies overnight. And they might be diversified enough to be fine for a very long time (WhatsApp, Instagram) but these are very real problems for facebook.

The idea that because things are some way now they will be forever thusly hasn't panned out historically.

Once dominant IT companies are now dust. The same thing can happen to any company, including FB and Google is they piss enough people off.

And that's incremental. Today's annoyances matter.

Once all-mighty 99% of the Desktop Microsoft now has the more lucrative 5% of the desktop eaten by Apple, and is irrelevant on mobile and web services (search, mail). If they had gathered goodwill back then (like they strive to do now) things would have been different.

I'm not refuting (because I don't really know) but questioning this statement.

Technological progress is a confounder, apart from that I think people and organizations behave as they always have. Okay, enslaving and murdering people has become harder - in the "modern" parts of the world at least. The "system" still favors not paying too much attention to the human side, and to do whatever you can get away with regardless of cost to society, I think.

This discussion (and thus the quip about "things being the same forever") is not about human nature, though. It's about consumer choices, and whether Google is really secure long term.

Not too far fetched given that DJT is presidente.

Some companies have to care what developers think. (Few, to be frank; developers overestimate their importance.) Many companies have to care what "influencers" think.

But not all, and Google is not part of that "most". Google doesn't have to give a shit because everyone uses Google. They are literally market-saturated at this point. They have no competition and the only material threat in the medium run is a powerful country with a salty antitrust division.

And on your other point, the idea that a company like Google should care about the rounding error of people who care about some B2C thing like Reader shutting down (while many totally-fine alternatives exist) being so personally put out that that colors their analysis of B2B offerings is more than a little silly. If you decide on GCP based frustrations over Google Reader or Google Inbox, you probably aren't clear-headed enough to be making decisions for your company and it's probably a good thing that you are a rounding error besides.

(I use some Google services; I don't use GCP for a variety of reasons completely unrelated to babyraging over a B2C shutdown.)

There was one guy who actually seriously suggested Google offering. Idea got dropped as EVERY other person in discussion said NO. Azure it will be. Over life of that project I am guessing google lost something like 1-2mil USD minimum. Obviously chump change by their standard but still.

Main reasoning for me was always the absolutely atrocious customer support, no fucking way in hell I will ever give 1c to them if I can avoid it.

This is the key. Google has my "business," but I'm also sick of it. The moment there's a really valid competitor - and these days, I'm starting to look at protonmail - I'm gone. The same stickiness that kept me with them will keep me gone.

I really don't think I'm alone in that.

Google fairly obviously is not doing that.

What sort of blowback do conglomerates see for this? Do railroad executives balk at buying GE locomotives because their GE refrigerators fail?

Pivoting is seen as a tremendously good thing in the startup community. If you have a product that isn't working and isn't getting users, you do something different or your company dies. You simply cannot keep throwing developer time at such a product.

Google has a lot more money than a startup and can afford to waste developer time, but it still isn't good. "We tried this thing out and it didn't get a lot of users" is an absolutely reasonable argument for killing a product. Google just gets known for killing products because they are so big and therefore start so many new products.

What's good for the startup community is not the same for the entrenched behemoth community.

>. If you have a product that isn't working and isn't getting users, you do something different or your company dies. You simply cannot keep throwing developer time at such a product.

Google however can. But instead of developing their product further, they announce it as the next thing, get millions of users, and then forget about it, don't update it, don't promote it anymore, and eventually close it pissing off all those users and failing to attract more users due to their own inaction.

(See the ex-googler's comment above about how this process goes).

Killing a thriving service is not the same as pulling the plug on one that no one uses.

I used to be a 100% Google products user, but my faith that it is fundamentally a good and ethical company has been systematically destroyed in the past years.

Section 7:

7.2 Deprecation Policy. Google will announce if it intends to discontinue or make backwards incompatible changes to the Services specified at the URL in the next sentence. Google will use commercially reasonable efforts to continue to operate those Services versions and features identified at https://cloud.google.com/terms/deprecation without these changes for at least one year after that announcement, unless (as Google determines in its reasonable good faith judgment):

(i) required by law or third party relationship (including if there is a change in applicable law or relationship), or

(ii) doing so could create a security risk or substantial economic or material technical burden.

What exactly do they owe you?

Not enough people were using Inbox. It was an experiment and now they're moving on.

MS is probably supporting XP in the embedded world. If you are not selling to consumers you have to be prepared to do that

When companies launch experiments and features that people actually like and then take them away, they piss some people off.

The bad PR they are getting from this means they didn't make it clear they were going to discontinue the service in 2020 (or something like that) and make it super easy to transition.

It's pretty weird they wouldn't just keep their Inbox service up and running and minimize maintenance costs.

Seems to suggest they want to make big changes to the underlying data storage and don't want to worry about backward compatibility.

This is oversimplified. Google makes products expecting something in return: users provide it data and ad revenue. More directly, users invest time and thought into learning it and integrating it into their lives. Google invited people to depend on it, and after they did, it killed the product. That's real hours wasted for real people. It's not irrational for them to feel betrayed.

Yes, Google has the right to kill a product, just as you have the right to tell a party guest to leave your house. But don't expect them to love you afterward.

> Not enough people were using Inbox. It was an experiment and now they're moving on.

Why weren't enough people using Inbox? Speaking personally, I never tried it because I expected exactly this. I don't want to waste my time on things that will be shuttered.

Google seems to think that each product is an independent experiment. But it seems more likely that each "experiment" they end contributes to the failure of subsequent ones.

Google doesn't owe people products. But people don't owe Google goodwill, either. And without goodwill, it can't launch new products.

EDIT: I don't care about downvotes, but if you are going to do it at least leave a comment of why you think I am wrong.

2. Softlayer completely f'ed us twice now with down time resulting in a substantial dollar loss.

> 1. AWS saves us money despite the apparent higher costs because our developers spend more time working on our core business than managing infrastructure, and developer time is our most expensive resource.

But in most cases you lose any preserved savings because of the very ease of use and lack of needing to think about the infrastructure management. This is because more often than not problems are solved by just adding another instance, vs actually solving the larger problem.

Also, I would say part of the core business is providing the server, not simply writing the software that is the interface to the service being provided to the end users. E.G. Keeping servers up and and the right number of them in operating is just as important to the core of the business as writing the software / website of the service you are intending on providing. Outsourcing that a 3rd party removes your ability for you to control the entire service that you intend on providing, it is left in the hands of somebody else who may not be aligned to your business needs.

> 2. Softlayer completely f'ed us twice now with down time resulting in a substantial dollar loss.

AWS has f'ed near half the internet before, and probably will do so again.

Service outages are shitty, I get it, but my suggestion for Softlayer was just that, there are others, and my favorite is actually colo with everybody else's cheap EOL servers.

As a anatotal I have seen far to many projects move from bare metal, to AWS or the likes who at a minimum tripple the running cost for less performance. You could say the engineers suck, but I thought they were going to get to spend more time working on core business?

I have ran the numbers many time myself and I can't support AWS for anything other than bootstrapping a well funded startup. After that if you want to lower your cost you are either going to have to jump through hoops and formulate your service to use the cheapest parts all while not focusing on the busness but trying to get that AWS bill down.

Somewhere, you're drawing the line between what you build in-house and what you outsource. Where to draw the line depends on many factors. There's definitely no "right" place, such as never using cloud resources.

For example, I used to work for a solar power company that would install panels on the roofs of big box stores and then sell the power to the stores below grid prices. This company did not manufacture panels -- they bought them at market rate from various suppliers.

The company got acquired by a major silicon wafer manufacturer. One of the things this wafer company made were solar panels -- boom, vertical integration. What a win, right? Well, as it turned out, after about a year, their competitors were able to bring their panel prices down whereas the acquiring company moved a bit more slowly. Thus the wafer company became an albatross around the solar power company's neck. They had to use the parent company's panels, instead of their more cost-effective competitors, and ended up no longer being competitive in the market.

So vertical integration can and often does make sense, but it comes with a loss of agility, and sometimes being nimble is more important.

In your ancedote the buying company seems to be benefit with increased sales for a non competitive product. Ofcourse they are doing at the expense of the eroding target , but they are deriving value not the way you see it perhaps or the best possible one but value nonetheless.

Amazes me when I see automation stacks with 5x the hardware you need to run the entire production / dev / stage environments

This is a phrase tossed around a lot, and I am challenging it.

If you make the developers part of the process then the software that is produced is forced to keep the entire vertical inline with the business needs.

You do this by giving the developers the budget along with the requirements. Developers are smart, they will figure out how produce the solution with the budget at hand. And when they realize they will be the one getting the call when things go wrong they will ensure systems are robust and fault tolerant by baking those features directly into the software they are building.

But I guess part of the process is there is a big effort to dumb down each segment of building software so people who have no desire to build software can simply use people as pawns in the game of business. It really shocks me that we still have businesses built with the core of people coming form antiquated business schools. Where they have reinforce the notion that a business needs to be swamped with a bunch of people who collect big paychecks for attending meeting after meeting after meeting while the engineers and developers continuously bring real value to organization.

Nobody ever talks about that CEO, CFO, or VP of whatever or Director of what ever as being expensive. Nobody ever talks about how to cut cost at that level. Meanwhile we have all sorts of strategies and cost cutting measures to lower the amount of budget going to the very people who are actually creating the value in a company.

I will tell you what is expansive. Paying some guy 6+ figures to tell you the guys who build the software that the company's revenue comes from is expansive. When was the last time you heard somebody outsourcing the executive team at a company ?

For those enraptures and founders out there, please don't get me wrong. I am not talking about you. I am talking about the people you may hire, or the people that other people say you need to hire.

The problem is, at a place like SL, they're not actually your own systems.

> can save you a bundle

It can, and usually does provide at least some savings, but it still comes with both the obvious form of vendor lock-in, and a subtler disadvantage, which is that you're limited by SL's specific hardware and engineering (including network) choices.

The real (performance and/or cost) magic of running ones own servers comes from custom combination of commodity ingredients, not merely lack of virtualization.

You are right, I do prefer colo and EOL hardware for low budget operations. But SL is a step lower than AWS. SL still can give you a punch in the face. But the point I really want is bare metal more than anything.

Also, if you need current gen stuff not owning can be nice because you won't have to repair when they break.

> It can, and usually does provide at least some savings, but it still comes with both the obvious form of vendor lock-in, and a subtler disadvantage, which is that you're limited by SL's specific hardware and engineering (including network) choices.

I advise you never to use vender provided features (that means avoiding AWS features along with depending on SL network topology (which is vlans, nothing special)).

Anybody making a service today should be able to buy a server at any provider, or setup a colo anywhere and join those resources in and get advantage of those resources instantly. All without depending on stacks and software you have no control over.

I hear this as a reason not to own, but I struggle to understand it, given my experience with how reliable modern hardware is (with notable exceptions[1]).

Regardless, you don't have to repair anything broken at all. It may seem preposterous at first, but, for low enough failure rates, on things with low enough replacement cost [2], using warm spares and abandoning in place can be a reasonable strategy. This can work remarkably well for disks in remote locations, especially in non-hot-swap enclosures.

> depending on SL network topology

One doesn't have a choice, though. There's no alternate topology (nor maximum bandwidths) available. Not taking maximum advantage may be premature optimization (optimizing for stability, rather than performance).

> Anybody making a service today should be able to buy a server at any provider, or setup a colo anywhere and join those resources in and get advantage of those resources instantly.

That would be nice, but it's tantamount to asking everyone go "multi-cloud", which removes too much of the "don't have to think/worry about it" purported benefit of cloud/IaaS.

[1] high-density (say, more than 1socket/U) seems to be the worst offenders

[2] by which I mean the current equivalent, including something like half of a server of a quarter of a CPU

That would defeat the entire purpose of using voting to manage the signal to noise ratio; in general, if a comment is worthy responding to, it shouldn't be downvoted, and vice versa.

If you upvote, and had to reply saying the same thing because you agree no new information is presented. Thus simply upvoting is needed.

But if you downvote, that means somebody has a differing opinion. Leaving it at a downvote only lets us know somebody disagrees and no new dialog can be had about what other ways something could be viewed.

That being said I think we mostly use the upvote and downvote feature on HN wrong but I could be wrong because I never really looked it up.

I think the intent is a upvote and downvote marks relevance, not agreement, but we often use it for agreement when upvoting. And downvotes seem to happen for both relevance and disagreements.

For example, replying to a post about what hosting provider is best with "I like chocolate ice cream", and "Rackspace is a good option" could both be downvoted for very difference reasons. One for being off topic, OR not liking chocolate ice cream" and the other for simply hating Rack Space.

So if you find you are downvoting something that has no comments that cover your settlement and the post is on topic then it would be helpful for many who may not share your sentiment if you explain why. I don't think that is too much to ask for.

No, it doesn't.

Downvote means “this post is not a productive contribution to the discussion”.

Disagreement may be a reason for that, but it's far from the only reason.

> Leaving it at a downvote only lets us know somebody disagrees and no new dialog can be had about what other ways something could be viewed.

If a comment presents a productive platform for on-topic dialog, then comment and don't downvote.

Downvoting is for things that don't do that.

It was in the phrasing, not in some defense of the "Cloud", which is overrated for existing businesses.

But I can see how that phrasing might warrant a down vote.

He got his code running on Elastic Beanstalk in about 2 hours. I spend $40/mo on AWS, but an extra team member would cost me at least $10k/mo.

Never say "never". Many (most) of us would prefer predictable, high infra costs over unpredictable (possibly even higher) payroll.

There's also some good integration with PM and IDE software that we use and enjoy.

I look forward to the national election where a politician stops what they're doing to complain every single time someone doesn't vote for them, and interrupt what's happening to demand an explanation.

That isn't how voting works.

"cost a ton more than you realize" - unless you look at the prices for the contract you're agreeing to? Y'know, like you do?

"Should have" - telling someone what their company should have done, without even knowing what their company /is/, let alone what they were trying to achieve and what constraints they had on their available options. Assuming or implying that the cheaper thing is always the more correct thing and no other factors can change that.

Maybe I will agree, or disagree. Maybe I will learn something. But simply downvoting because you don't agree leaves no new information for me or anybody else reading to learn something.

I could be horribly wrong. And the process of being told why somebody thinks I am wrong might inlighten somebody else even if I hold to my initial view.

That being said, the voting system AFAIK on HN is more about being relevant to the topic, and less about agreeing. Although in practice upvotes tend to be more about agreeing and down votes more about being off topic or illrevent.

Not everybody can downvote, so when somebody does it means they have been around long enough to gain enough magical internet points to do so. So they might have some real insight that could help a OP or inlighten others. Along with making a good conversation even if no agreement is made at the end.

> I look forward to the national election where a politician stops what they're doing to complain every single time someone doesn't vote for them, and interrupt what's happening to demand an explanation.

Nobody is a politician here, what does that have to do with anything? This entire site was designed to talk about things, so I am hardly interrupting "what's happening"

> "cost a ton more than you realize" - unless you look at the prices for the contract you're agreeing to? Y'know, like you do?

AWS has public pricing, I can compare them to other publicly priced places. I don't need a contract that simply don't exist in most cases.

> "Should have" - telling someone what their company should have done, without even knowing what their company /is/, let alone what they were trying to achieve and what constraints they had on their available options. Assuming or implying that the cheaper thing is always the more correct thing and no other factors can change that.

I can compare server for server , compute for compute, and all the above. I don't really need to know what our anybody else is doing with a system to understand the raw resources you can get from the services offered and compare them based off that.

And long enough to know that they can write a reply if they want to write a reply, without being prompted.

Nobody is a politician here, what does that have to do with anything? This entire site was designed to talk about things, so I am hardly interrupting "what's happening"

It's illustrative because politicians are the main thing people deal with when 'voting' for something, and the scale of political votes draws attention to the problem. Imagine HN if every comment that got downvoted had a line asking for an explanation - that would be almost every single comment - totally interrupting the flow of the comment threads. Imagine if political votes with millions of voters were stopped by someone demanding an explanation for one or two "down"votes. It would be unworkable. Voting is an aggregate, noisy, large-scale summary. And now this really is dragging it off-topic talking about voting instead, and entreaties to "explain your votes" to people who could have done that if they wanted to, always will tend towards "that's not downvote-worthy", "yes it is", "no it isn't".

AWS has public pricing, I can compare them to other publicly priced places.

Right. So why are you telling other people they are spending "more than they realize"? Either they didn't bother reading the prices, or they don't understand the prices - where's any evidence for either of those? How is it any more than an insult about their inability to understand the public pricing before signing up?

"I can compare server for server , compute for compute, and all the above. I don't really need to know what our anybody else is doing with a system to understand the raw resources you can get from the services offered and compare them based off that."

Indeed you can. What you can't do - or what I disagree with - is you saying "I can get cheaper compute resources here, /so/ that's what your company /should/ have done". It doesn't matter what you started with, who you employ, what skills they have, what constraints you had on timescale or rewriting or redesigning, what your management or investors would support, what discounts you could get, what your future plans are, none of those things matter, only a rudimentary price-per-ghz is enough to tell you that you did the wrong thing and say I know better.

The most recent that springs to mind is the ditching of ADO in favour of ODBC which pissed a lot of developers off. There are plenty of other examples.

You may have gotten confused by this clickbait TechCrunch headline, which does not match the article content: https://techcrunch.com/2018/08/29/google-steps-back-from-run...

Disclosure: I’m executive director of CNCF which hosts Kubernetes.

Also they don't have any feedback / bug report channels - these are also important if you plan to support your own stuff (I know you can monitor a lot but it's still not the same level of customer support)

I'd honestly even settle with something like a program where users can choose to enroll in these programs in some sort of test phase. Maybe put some kind of marker in the name or even on the logo that clearly informs and denotes "this product might not last long, it might go into production, it may die after 3 years, you have been warned".

There's a word for this but for some reason it eludes me (and apparently eludes google as well). At least it'd soften the blow when they inevitably roll things up on one of these so designated services.

Beta? Developer Preview?

Google (mis)uses both already. Heck Gmail was in Beta for years (5? Not sure, but that seems the right ballpark).

The bottom line is that Google is so big and important that other companies just have to put up with Google's behavior. Until that changes there won't be a migration away from Google's APIs.