Live data from Hacker News

Farewell EC2-Classic, it’s been swell

allthingsdistributed.com

121–130 of 187 posts

Re: Farewell EC2-Classic, it’s been swell

#121
post #15

Earlier quoted context omitted.

The had to be restarted, but not only that, has to have their networks reconfigured. But they gave people YEARS to do that, and tracked down every user to help them if necessary.

> has to have their networks reconfigured. I don't see why every user couldn't be auto-created a virtual network with the same 10.x.x.x IP addresses as their original machine had - and therefore there is no need to do any reconfiguration on the users side.

Because people could have that same network on-promises on the other side of the VPN (I have).

Re: Farewell EC2-Classic, it’s been swell

#122

Earlier quoted context omitted.

No, migrating did involve intervention from the account holder. More information here: https://aws.amazon.com/blogs/aws/ec2-classic-is-retiring-her... It seems like AWS spent time, people and money to migrate customers off EC2 classic. They made a fairly good effort to automate the process and make it less painful for customers. For example: https://repost.aws/knowledge-center/ssm-migrate-ec2classic-v... The original…

Looking at that blog post, I think AWS could have done the migration for most users with no involvement of the user themselves. In the ideal world, they would have written software to live-migrate VM's to the new platform and emulate the old networking. Emulating old stuff should be pretty easy, because hardware moves on, and an instance back in 2006 probably had far lower performance expectations - and therefore eve…

"emulate the old networking" is something that can't be done per customer, and the new platform makes networking per customer.

Let's say I have my aws account "account1", and my friend has their account "account2", both running classic. We could have both talked to each other's instances by their _private IPs_ even though they're in different accounts. AWS has no way of knowing those two instances are related, other than that they're both in classic.

Sure, AWS could make a global cross-account emulated flat network, but at that point, it's probably cheaper to just use the real thing, which was already built and functions... and at that point, you're not migrating them to "the new platform", but rather to "ec2 classic 2"

Re: Farewell EC2-Classic, it’s been swell

#123
post #8

Earlier quoted context omitted.

Google Reader. Never forget.

Obligatory reminder that RSS is alive and well. It remains popular. I both subscribe to RSS, and support it on my blog. You can too.

Still use it - I even read HN via RSS - but I've never found a tool with the critical mass of users you need to show trending content the way GR did.

Re: Farewell EC2-Classic, it’s been swell

#124

Earlier quoted context omitted.

Looking at that blog post, I think AWS could have done the migration for most users with no involvement of the user themselves. In the ideal world, they would have written software to live-migrate VM's to the new platform and emulate the old networking. Emulating old stuff should be pretty easy, because hardware moves on, and an instance back in 2006 probably had far lower performance expectations - and therefore eve…

"emulate the old networking" is something that can't be done per customer, and the new platform makes networking per customer. Let's say I have my aws account "account1", and my friend has their account "account2", both running classic. We could have both talked to each other's instances by their _private IPs_ even though they're in different accounts. AWS has no way of knowing those two instances are related, other…

If there is a small number of classic users, a single special case in the code to have all classic users connected to a single network of an admin account seems very doable...

I wonder if perhaps part of the reason for not doing this was they were worried about malware spreading across that shared internal network from one VM without security patches to the next VM without security patches.

Even if that were the case, they could monitor all VM's on the classic network, and any VM which doesn't contact another users VM's for ~1 month would have the ability to do so be blocked.

Re: Farewell EC2-Classic, it’s been swell

#125

Earlier quoted context omitted.

> has to have their networks reconfigured. I don't see why every user couldn't be auto-created a virtual network with the same 10.x.x.x IP addresses as their original machine had - and therefore there is no need to do any reconfiguration on the users side.

Because people could have that same network on-promises on the other side of the VPN (I have).

But that isn't a new problem if the same user already uses that address - you're just leaving them with the same issue they already had.

Re: Farewell EC2-Classic, it’s been swell

#126

Off topic, but I'm confused about the IPv4 notation in this quote: > When we launched EC2 in 2006, it was one giant network of 10.2.0.0/8. In my understanding, /8 means the first octet would be fixed (10.0.0.0-10.255.255.255) and I'm having trouble understanding the significance of the 2 here. If the 2 is significant, wouldn't you write it as /16? Given the source and my confidence on this notation, I feel like there…

My thought was that 10.2.0.0/16 is part of the 10.0.0.0/8 address range which is by default a private network address range (i.e. not routable by any other machines). I interpreted what the author wrote to say that your machine would be assigned an address in 10.2/16 but would still be able to route to other AWS services / machines in other 10/8 subnets (e.g. 10.1/16)

Re: Farewell EC2-Classic, it’s been swell

#127
post #9
post #8

Earlier quoted context omitted.

Google Reader. Never forget.

I miss Google Search being good and useful and not covered in intrusive ads much more than I miss something easily replaced with local software or Feedly. Almost everything Google does outside of GCP, Maps, Search, and YouTube could evaporate for all I care. Google's problem is not that they cancel stuff, it's the everpresent need to grow revenue and embed annoying ads into more and more of everyone's daily lives. I'…

> everything Google does outside of GCP, Maps, Search, and YouTube could evaporate for all I care

Honestly, even YouTube could evaporate and it really wouldn't make a difference. 99.9999% of YouTube is just mindless entertainment, which is 100% fungible with every other form of entertainment. The amount of actually unique, insightful, worthwhile content on YouTube is a rounding error, and will find other places to live.

Re: Farewell EC2-Classic, it’s been swell

#128
Personally I wish they would have just bit the bullet and continued Classic with IPv6.

Ironically I think post-classic was a regression — it looks a lot more like the infrastructure we had to deal with pre-cloud.

My new stuff is mostly on Cloudflare, so now I’m really not thinking about subnets, VPCs, etc.

Re: Farewell EC2-Classic, it’s been swell

#129

Earlier quoted context omitted.

For me it's when they stopped showing results that include your keywords and instead a random smattering of anything broadly related to the topic being searched for.

You can use quotes around keywords. https://blog.google/products/search/how-were-improving-searc...

This shifted from "can" to "absolutely have to" a long time ago for my use cases.

Re: Farewell EC2-Classic, it’s been swell

#130

"Retiring services isn’t something we do at AWS. It’s quite rare." I read this while I was taking a break from working on an epic to migrate our stuff off of OpsWorks before it gets shut down in May.

Bloody shame, OpsWorks was a great service in my experience. I built a few clusters with it before Kubernetes and terraform were a thing.

That said, I heard from folks at AWS that it was not well maintained and a bit of a mess behind the scenes. I can't say I'm surprised it's being shut down given where the technology landscape has shifted since the service was originally offered.

RIP OpsWorks.

Post reply on HN