[Spooky23]

It’s an old and lazy/annoying complaint.

There’s a difference between consumer stuff and enterprise stuff with contracts. Grown up services like GSuite, AppEngine, etc have been alive and well for many years and aren’t going anywhere.

It makes sense to do risk assessment and avoidance where there is value. General emotional stuff isn’t productive.

Building your entire business on AWS Lambda, for example, is a risk you need to understand. In the past, I worked on a team that chose to put a critical business process on a IBM POWER/Aix platform... in our case we went through the options, identified risks/opportunities for standardizing a long lived process on a sole source platform, and made a decision. It was a decision that served us for about a decade before we moved on, so it was very successful.

[Jugurtha]

>It’s an old and lazy/annoying complaint.

Granted, you offered a nuanced reply for someone building something on these clouds. However, when you're dealing with enterprise that are directly competing with the main cloud providers on other verticals, they are not being lazy or annoying, they are being careful, and not without a reason, and avoid using their competitor's cloud infrastructure.

Some of our clients have no problems using these cloud providers. Others wouldn't go through them because that would leak information.

If I'm not mistaken, Google used to buy datacenters in stealth mode, under different companies created for that purpose, to avoid getting on Microsoft's radar and keeping how successful search was from them.

We use GCP, for context.

[ignoramous]

> Google used to buy datacenters in stealth mode, under different companies created for that purpose, to avoid getting on Microsoft's radar and keeping how successful search was from them.

I believe, Google for a long time (and still does?) thought their infrastructure was the secret sauce, and that might have impeded them from competing with AWS in the early years (despite having all the pieces in place already)?

[Jugurtha]

There are apprehensions like these all over the place to protect their user base.

This matters to us because we're building our machine learning platform[0] and we want flexibility as opposed to using their machine learning products, because each considers themselves "the only cloud". Therefore, we're compelled to do "multi-cloud"[sigh], because we want to be able to train models on X, deploy on Y, and have data on Z.

It's funny to watch, though, as if I recall correctly, there was an article on one of these companies where saying "multi-cloud" was blasphematory.

- [0]: https://iko.ai

[sturgill]

Eh, even corporate GSuite changes from time-to-time. Google products and services are less stable than AWS. I’m not talking about uptime, necessarily, but for all of AWS half-baked ills you know that half-baked service is going to be around forever.

I don’t think it’s a tired argument: Google is much more likely to cut bait than Amazon.

[etxm]

If this was on occasion it wouldn’t bother me.

If my cloud provider said, “hey we released a half baked service and we’re deprecating it” at least that would give a solid reason to fix some obvious technical debt. Otherwise you may just be band-aiding technical debt for years.

Anecdotally, I’m thinking of ElasticSearch Service around 2017. We were pushing almost a terabyte an hour into ESS.

We ended up tacking on SearchGuard, ElastiAlert, some SSO proxy, and about 3-4 other products, when what we wanted was X-Pack.

It took a lot of toil before we convinced the org to go permit a migration off of ESS.

[ashtonkem]

You might accept it, but I wouldn’t. Telling product owners that their timelines have been pushed because our cloud provider is removing something we depend on again is not a conversation I want to have.

Large enterprises are complicated beasts, and they value stability a lot. Even removing a single feature might cause dozens of teams to drop everything in order to go and fix the mess that someone else made. Why risk it? Especially if the alternative is someone who will wait to release a feature until it’s more than half baked and support it for a decade or more?

[etxm]

I said “on occasion,” not time after time.

I think purging some of the lower quality services from a catalog of over 175 (AWS) services would be a net positive, because orgs wouldnt come along and build on top of sore ice that may not be as extensible as you need it two quarters from now.

[sturgill]

I disagree. Perhaps AWS should be more selective in what they choose to launch, but once a service is launched you should have a very compelling reason to deprecate it. This creates a positive feedback loop that AWS is safe —- in the sense that if you build on top of their services you know that they will continue to be around.

It makes the AWS dashboard a bit more cluttered, but if you use one of AWS’ half-baked services you know it will be around for as long as you want. Maybe you outgrow it; that’s fine. You can opt to move off, but AWS won’t force your hand.

There’s a ton of value in that stability. Your MySQL server running on EC2 still works today if you haven’t migrated to RDS. And if you migrate to RDS, you can be confident that it will be around until well after you’ve moved to your next job.

Ironically, this is related to Golang’s strong 1.X backwards compatibility guarantee. Knowing that what works today will work tomorrow has tremendous value. You don’t have to wake up and migrate everything from vendor to modules. You can build on ECS today and have confidence ECS will be around tomorrow.

[k4ch0w]

It’s human trust. It’s a basic thing in all business dealings. Google has built this reputation themselves over the years by constantly sun setting new products. I mean there is a website showcasing it https://killedbygoogle.com. Google support is known for being notoriously bad and unhelpful. They are the first targeted tech giant going through new antitrust suits and who knows the outcome of them. Why would I trust a business I’d hope could be around for 10 to N years when AWS/Azure are around? Yes, the same could be said for them but the basic human element of trust is on their side.

[jsnell]

Why do you trust AWS when Amazon kills failed non-AWS products left and right? I even remember Bezos bragging about this being a core part of the company culture. Why do you trust Azure when Microsoft's graveyard of non-Azure graveyards has long since overflowed?

For me, it's because Amazon killing their failed phone, their failed Yahoo Answers clone, their failed search engine, or their failed paypal clone says nothing about their commitment to their phenomenally successful $45 billion / year business with high margins and 29% growth.

Google Cloud is a $14 billion / year business growing at 45% / year. It is a smaller business than AWS, sure. But not by an order of magnitude. It's basically 3.5 years behind Amazon on the growth curve. Were you afraid in 2017 that AWS would be killed due to being too small a business?

[whoknew1122]

>"Why do you trust AWS when Amazon kills failed non-AWS products left and right? I even remember Bezos bragging about this being a core part of the company culture."

I'd be really interested in this quote and its context. At AWS, things are always iterated upon and tested. But there's an incredible emphasis on two-way door decisions. Basically, don't make big decisions that can't be reversed if things go poorly. And once you've released something customer-facing (especially something as important as a new AWS service), you're locked in for the foreseeable future.

There are still CloudHSM v1 HSMs running out there in the wild. CloudHSM v2 was released in 2017. And CloudHSM v1 hasn't been available since at least 2019.

There are still EC2 instances running in EC2 classic--that is, EC2 before VPC was introduced.

[jsnell]

It's a pretty common theme in what Bezos says, no? Here's some examples: https://www.investors.com/news/management/leaders-and-succes... has some of such quotes:

> "Failure comes part and parcel with invention," Bezos wrote in his 2013 letter to shareholders. "It's not optional. We ... believe in failing early and iterating until we get it right." Three years later, he added, "Amazon is the best place in the world to fail."

Or:

> “As a company grows, everything needs to scale, including the size of your failed experiments. If the size of your failures isn’t growing, you’re not going to be inventing at a size that can actually move the needle,”

Now, I'm sure that doesn't apply to AWS, and your culture is totally different. You're an enterprise product with real contracts, real commitments, and making real money. You're not the Groupon clone, online pharmacy or whatever that grocery service *Amazon killed today* was.

But if we're accepting that Amazon's general trigger-happiness when it comes to failed consumer products doesn't extend to AWS, why does Google Cloud not get the same treatment?

[jshen]

Google has absolutely abandoned things in their cloud. App Engine has been a moving target for years for just one example.

[bedatadriven]

I beg to differ. We've run our business on AppEngine for 8+ years. We've never been forced to migrate, and when we've chosen to upgrade to newer runtimes like Java8, the transition was smooth.

Upgrading to Java11 will indeed be a big change, but Java8, with memcache etc, is still very much supported.

[jshen]

I led a team that wrote an app app engine using python 2. When Google upgraded to python 3 they completely rewrote entire libraries, like the one for datastore, so we were forced to either rewrite most of our app or to stay on a deprecated platform that stopped getting new updates.

[Crash0v3rid3]

Can you give a more clear example of what GCP has dropped support for?

[Strom]

Google provides a list of App Engine features they've removed. [1] Beyond that there is also a somewhat undocumented phase of working-but-forgotten. Classic App Engine features like the datastore, memcache, Users API, Python 2, Go 1.11 etc go under this category. These are things that still work, but get no updates. Instead you get constant e-mails and other notifications about how you should redesign your app to work with the 2nd generation App Engine system. Which means Firestore (in datastore mode) instead of datastore. Memorystore instead of memcache. Your own solution instead of the Users API etc.

--

[1] https://cloud.google.com/appengine/docs/deprecations

[jshen]

Yes, this. Thank you for explaining it better than I did. I loved this with a real production python 2 app, and my take-away, be very careful building against proprietary systems like classic app engine and all of its services.

[jshen]

*lived

[jshen]

https://news.ycombinator.com/item?id=25854364

[temp667]

Tell to the folks paying for the Maps API who built businesses around it.

What a scam. Has amazon EVER raised the price of an AWS service?

[whoknew1122]

No, Amazon hasn't. If a service is poorly-priced and/or seldom used, they'll rebuild the service from scratch to offer better pricing and features. See Macie as an example.

[cwhiz]

This comment brought to us 9 days after an entire company was yeeted off the internet by a cloud provider.

Old, lazy, and annoying? Come now.

[acdha]

Most customers do not plan to repeatedly break their contract and makes no effort to fix it. Parler’s refusal to follow a legal agreement is only a concern to a small handful of other sites.

[cwhiz]

That’s quite an imaginative take on what happened.

[acdha]

You’re welcome to read the legal filings yourself so you can make less uninformed comments in the future. Here’s an example of the messages AWS contacted Parler about in November:

https://www.courtlistener.com/recap/gov.uscourts.wawd.294664...

The entire filing makes it clear that they were given considerable time and refused to moderate content which violated the terms of service which they had agreed to follow:

https://cdn.arstechnica.net/wp-content/uploads/2021/01/gov.u...

[cwhiz]

Maybe you should actually read your own links. They don't say what you think they say. Not to mention the source is Amazon. Of course Amazon thinks Amazon is in the right.

In a span of seven weeks, on a platform with 8 million users, Amazon found 100 examples of objectionable content.

How many examples of objectionable content do you think I can find on Reddit, Twitter, or Facebook right now?

It's not a question of whether Parler had offensive content on its site. It's a question of Amazon holding Parler to terms that they don't hold anyone else to, including Parler rivals. Parler had moderation tools, were moderating content, and had a clear Terms of Service that outlined the type of content that was not allowed.

Let us travel back in time to 2009. It's three years after Twitter was founded. How robust and effective do you think the Twitter moderation was back at that time?

Even today, in 2021, Twitter is absolutely FULL of illegal content and hate speech. When do you think Amazon will eject Twitter from AWS? Should be any minute now. Any minute.

[acdha]

> How many examples of objectionable content do you think I can find on Reddit, Twitter, or Facebook right now?

This is why I suggested reading the filings: Parler is not unique for having user-hosted content but, unlike Twitter and Facebook, refusing to accept responsibility for managing it – those services are far from perfect but they don’t try to pretend volunteer moderation is enough, either.

If you read the filing note that the 100 examples were a representative sample and additional examples were provided.

The key point to look at is this:

“On January 8 and 9, AWS also spoke with Parler executives about its content moderation policies, processes, and tools, and emphasized that Parler’s current approach failed to address Parler’s duty to promptly identify and remove content that threatened or encouraged violence. Id. In response, Parler outlined additional, reactive steps that would rely almost exclusively on ‘volunteers.’”

That’s after having months to develop a serious plan, and after an insurrection involving many users of their service. Beyond the obvious violations of their contract, at that point AWS would reasonably worry that not enforcing their ToS could invite legal claims that their continued non-enforcement constituted support. The direct costs of that and indirect risk to other contracts – imagine, for example, Congress prohibiting federal IT procurements from any company connected to the coup attempt — are much greater than Parler’s rounding-error portion of AWS’ customer base.