EC2 Classic was essentially deprecated back in 2013, whether it was said as such at the time or not. 8+ years is an incredibly long sunset period, especially compared to AWS’s competitors.

I know what you mean, but I don’t think it counts as a sunset period if they haven’t announced anything.

yeah, it's not technically a sunset period if they haven't announced the service will be ending. but they've been sending some pretty strong clues - afaik you haven't been able to create new EC2 classic instances for many years now.

From Jeff's blog post:

> All AWS accounts created after December 4, 2013 are already VPC-only, unless EC2-Classic was enabled as a result of a support request.

There were announcements made at the time, but I don't remember if they explicitly called it a deprecated product at the time (hence why I hedged my wording in GP comment).

The writing has been on the wall for quite a while. I got us off our last classics this year due to the october date they had been saying before.

You’re generally right but it’s definitely not a hard rule.

Amazon/AWS has deprecated and then put to the grave multiple payment services. I made that same comment when SimpleDB was deprecated and someone said the same thing. More recently, torrent support in S3 is being killed off with little notice.

The thing has been that historically even though Amazon would "depreciate" a service they kept it running and supported.

"Amazon SimpleDB (N. Virginia) Service is operating normally" is their current status page, but their marketing materials doesn't show any SDB stuff. So if you had some old workload ticking over - you could just leave it usually.

I actually used SimpleDB in a light use case wildly past the point at which it disappeared from all marketing. I kept on expecting an email like the EC2-classic one, but it never came even though simpleDB didn't show up anywhere really

FYI, "depreciate" != "deprecate" — I also used to think it was the former once upon a time :)

My favorite similar mixup is ordinance vs ordnance. Though I suppose they're not mutually exclusive. I'm sure that printed copies of some bylaws are hefty enough to cause serious damage if you lob them at the enemy.

This was hilarious when I saw local businesses put up signs requiring masks due to local "ordnance". I had to wonder what kind of masks they expected us to have

insure vs ensure is another one I've commonly seen. As in "please insure that <some task> is complete".

Interestingly, I think this was correct or at least colloquially correct a few centuries ago. I've seen that spelling used in text from the 1700s and 1800s by educated people. Probably a holdover from before spelling got really standardized.

Glad there’s someone else pedantic here so I don’t have to do it…

One aspect of this mix-up that I enjoy is the fact that deprecating something causes its value to depreciate, by quite a lot!

not only can deprecate cause depreciation, it can be a synonym for depreciate (in the financial meaning). but depreciate can't be a synonym for deprecate (in the end-of-life meaning).

just one of those fun things that gets thrown in to make sure nobody ever fully understands the english language.

As a Swede reading OT comments on HN I can ensure you that deprecate and depreciate are not words I would mix up unless autocorrect gets me. They look similar after all.

Ordnance and ordinance I don't even know the difference between though.

I'm still using SimpleDB in production. I do have plans to migrate that workload, but as long as it keeps working there's really no rush...

We were SOL when Amazon simple payments was killed off with very short notice and then again with FlexPay.

Good example - and goes to show how miserable it is when these folks kill stuff off.

Sounds like a good reason to integrate with Authorize.net or another vendor that provides platform agnostic APIs that let you pick your own payment vendor (at much lower cost than Amazon's payment offerings).

It was never our primary payment method, but we had higher conversion rates with it. We had Authorize.net at the time, then added PayPal PayFlow and Stripe. I actually authored a payment abstraction library that would try providers in order of priority and fall back gracefully, avoiding double charges and even abstracting over payment status, refunds, etc.

> I actually authored a payment abstraction library that would try providers in order of priority

Were you storing PANs then?

No, the retry logic was in-tandem between the client and a separate server endpoint.

SimpleDB is still supported though. You can still make new SimpleDB domains.

Thats part of what people love about AWS compared to Google Cloud. Google is quick to kill off services it finds no longer convenient for it to run. AWS has historically gone out of its way to keep old services running even as it releases new, better alternatives.

Any examples?

I work in the AWS Mobile org. The predecessor to our premier service, Amplify, was called Mobile Hub (https://aws.amazon.com/blogs/aws/aws-mobile-hub-build-test-a...). While I haven't personally worked on either service, I've heard and seen enough to know that they've taken customer obsession over keeping the lights on for any existing workloads farther than most reasonable businesses would. There is no sentiment of "force them to move to Amplify" in any conversations or design discussions, but rather "accommodate their existing workloads" as long as they exist.

Update: it looks like we're executing a migration plan this year by building seemingly-full parity between Mobile Hub and Amplify (https://docs.aws.amazon.com/aws-mobile/latest/developerguide...) such that "if you don't migrate your project to Amplify, your app will continue to function, and all your related cloud resources will continue to be available". This seems like a great solution for existing Mobile Hub customers.

My family is on Google Apps free edition.

Google has been doing it's best to make my life miserable. It recently killed Google Voice in the free edition, so my younger child can no longer get a phone number. With zero warning.

I've been through this each time I've (tried) to use Google for anything critical, so I've stopped.

I mentioned a family example since B2B would be confidential. But I can count at least a half-dozen instances of Google discontinuing something an employer has relied on, leading to a world of pain.

My general cloud policy is AWS, Azure, or anything-but-Google. I have a similar anti-Oracle policy too. Once you're burned a few times, you find that some companies are too expensive to do business with.

GSuite is separate from Google Cloud.

Not according to Google:

https://cloud.google.com/products/ https://cloud.google.com/blog/products/workspace

But it's a moot point in either case, if you want long-term support.

* Internal corporate lines shift with re-orgs

* Culture is shared and common

* I've had issues across Google. I listed the ones I can talk about.

My lesson, each time, has been:

Never Use Google For Business.

Ever.

Considering how many companies use gsuite and are happy with it, I'd say thats a pretty silly lesson.

Five out of six people report being happy playing Russian Roulette.

I assume you mean on the Google Cloud side? Maybe start with https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

The only concrete example of a sunset in the rant is support for Python 2.7 (released in 2010) in the gcloud CLI tool. Seems like a pretty bad place to start.

> I know I haven’t gone into a lot of specific details about GCP’s deprecations. I can tell you that virtually everything I’ve used, from networking (legacy to VPC) to storage (Cloud SQL v1 to v2) to Firebase (now Firestore with a totally different API) to App Engine (don’t even get me started) to Cloud Endpoints to… I dunno, everything, has forced me to rewrite it all after at most 2–3 years, and they never automate it for you, and often there is no documented migration path at all. It’s just crickets.

IIRC, the S3 torrent deprecation announcement was in 2016, the recent announcement was based on API documentation cleanup

> is this one of the first actual depreciation and get off service things AWS has done?

The transition from Amazon Linux to Amazon Linux 2 on Elastic Beanstalk was pretty rough. The migration took a full week, and there was really only a six month window where it could be done.

EB is kinda a mixed bag. Is there much production on EB? It’s great for q&d stuff you don’t want to get into specifics but I couldn’t imagine explaining my architecture with a big “EB does what EB wants to do here” bubble

Notion (my employer) was 100% Elastic Beanstalk until about a month ago, now we’re 100% ECS. We migrated once our 1200 box cluster started stalling deploys randomly while saying everything was healthy in the API. At that many instances, the some pages in the dashboard would hang the browser.

One bad day, it took like 18 hours from deploy attempt started to AWS resolving the situation by fiddling knobs on their side.

Our deploys on ECS take like 15 minutes.

Did the migration went easy? We are currently running all our production service through EB as well, but we only had smaller issues (e.g. deployments stalling, health checks not working correctly etc).

Would you recommend to invest time learning how ECS works or had your company hires that managed that?

ECS and some ECS Fargate work great - I really like that combo. Seems pretty low overhead, and ECS anywhere I've had some luck with just playing around (you can do a local box on a 1Gig link with tons of RAM / Storage etc).

My one compliant is around having fallback to on-remise providers / capacity provider etc support - doesn't seem fully fleshed out across ECS/Fargate/ECS anywhere but I may not have read docs properly yet.

EB is neat when it works, but it’s only as good as it’s weakest link. I constantly get environments stuck in unavailable statuses etc. I don’t recommend it for anyone except maybe that R&D stuff. Much better to go ECS/Fargate/EKS IMHO.

To be fair, this was over a decade in the making.

They deprecate specific versions of RDS software, forcing upgrades or peril.

Same for EKS versions. I think versions of software in general they don't really necessarily keep around long, though these are the only two I can think of.

They have tools for migration and the replacement actually cover the full feature set.

Unlike Google.

GCP promises not to deprecate their service until at least the next monthly billing period. /s

Combining "enterprise" with "vague promise of longevity" is quite the oxymoron. Google should start celling cell service if they want to continue upleveling their doublespeak abilities.

Google Fi already sells cell service, it's essentially T-Mobile service but without most domestic roaming and with higher prices than Mint, T-Mobile Connect and their other MVNOs.

From what I hear MMS stopped working a few months ago for iPhones on Google Fi.

It's a higher price with the benefit of world wide roaming without a special plan. There are also some unlimited and multi line plans now.

I've been on Fi for years and its great.

Google Fi has the same included international roaming country list as T-Mobile.