Live data from Hacker News

Farewell EC2-Classic, it’s been swell

allthingsdistributed.com

91–100 of 187 posts

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

#91
post #58

Earlier quoted context omitted.

They have live migration now (for many years) but they didn’t back in the early era. I’m not sure they set it up for the classic environment but I think they must have - in the early 2010s you could get notices that your VM’s host had failed or was about to fail and you needed to launch a new one but I think that stopped by around 2015 as I had servers running for a deprecated project which were finally shutdown this…

I received last such email about a year ago for a VM in either free-tier or like the cheapest one available. This probably has to do with VM flavor you choose as well as with the time you created it.

Definitely possible - I only had about ten old servers but that’s a nice stretch without a hardware failure.

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

#92

Earlier quoted context omitted.

I think it just was never going to get the mass adoption it needed to justify the upkeep.

The upkeep was apparently 12 engineers and they had tens of millions of users. It doesn't take that many users to justify 12 engineers plus infra, so it sounds like it was more that Google doesn't care to operate any product unless it will have users in the hundreds of millions.

Broadly, I think some business models are better suited for smaller companies than Google for sure.

Reader probably didn't have much B2B potential and was maybe profitable but yeah, they tend to swing for larger audiences.

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

#93

> one giant network of 10.2.0.0/8 Huh? Do they mean 10.0.0.0/8, or 10.2.0.0/16 (/15 would also work), or is this a new CIDR notation? Something specific to AWS, maybe?

You encounter that all the time in the networking world - formally the bits outside of the prefix length should be 0, but informally you'll often see set bits. Often it is a way to say "the subnet that includes this ip address". So 192.254.33.12/16 or something. Could just be a typo, too. Regardless, it doesn't really matter what is in the bits outside of the prefix length, because they get zeroed out when used.

Yeah, but that makes sense -- it's a shorthand for "the IP address 192.254.33.12 which is in the /16 subnet".

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

#94
post #23

Earlier quoted context omitted.

Can you explain "minimaxed" in this context, please?

Not bad enough to be outright spam with just enough relevance to be shown in the top ten search results. Try finding product reviews, or product comparison articles. It will likely be LLM garbage that doesn't say anything, but uses the right keywords and enough coherency to be indexed.

> It will likely be LLM garbage that doesn't say anything, but uses the right keywords and enough coherency to be indexed.

Or some site that "aggregates" Stackoverflow, Quora and whatnot. Pure hell and I wish everything bad possible on this planet to the people who have implemented this kind of scam.

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

#95
post #38

Ec2 classic was dirt simple. You basically were on a big public lan it felt like. If I remember right there were some issues with folks running scans / abuse originating inside AWS that felt like got a touch slow of a response - then at some point it all cleared up? I remember hardening internal systems as if the they were public which was a good practice even as vpc arrived. They might have gotten a default public i…

[parent comment was edited, it originally mentioned SimpleDB] Speaking of SimpleDB, we still use it. It's amusing how it's basically swept under a rug at AWS. It's never mentioned, barely documented, but continues to work. It's a pretty good product for what it is - a very simple key/value store where you don't need/want to manage provisioned throughput, costs, keys, etc. The way they handle SimpleDB makes me respect…

They added Python 3.11 last month. Why do you call it close to abandoned?

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

#96
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'…

What ADs? Install uBlock.

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

#97

Earlier quoted context omitted.

I don't know the details of this particular migration, but I used to have a VM in some low-price tier that was running for a long time (few years), and, eventually AWS sent me an email telling they are going to shut it down for maintenance reasons. Guess this was something similar. VMs, if not specifically configured to be able to move cannot really be moved automatically. Think about eg. randomness of ordering in PC…

The clouds have figured this out: https://dl.acm.org/doi/pdf/10.1145/3186411.3186415

That's a very bold claim :)

If you prepare for migration, then it will work. If you don't -- it might or might not work, and it depends on way too many things to be confident that it will.

For example, in our VM deployment process we heavily rely on PXE boot and our code that runs during initramfs and also after pivot. So, even if whatever you have in the hypervisor and the virtualized OS has somehow managed to solve the moving problem, our own (screwy) code might not be so smart.

In general, the more of the underlying infrastructure you touch, the harder it will be to move you, unless you specifically prepare to move. Eg. what if you set up BMC for various components on your system? What if your code relies on knowing particular details of hardware to which you were given pass-through access from your VM, like, eg. you record somewhere the serial number of your disk in order to be able to identify it on next boot, but suddenly that disk is gone?

Even simpler: MIG flag on NVidia's GPUs is stored in the persistent writable memory of the GPU itself. Suppose your VM has moved to a different location and is connected to a different (but compatible) GPU -- you need to run the code that sets the flag again and then reboot the system in order to start working with the GPU, but the host may not be even aware of the fact that you need that particular setting.

The guest side of things needs to be prepared to move, to mitigate these problems.

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

#98

So if I'm understanding correctly, all the classic instances were migrated to more modern types with no intervention from the account holder? Did they suffer a reboot during that migration, or was it done via some live-migration process (it's hard to live-migrate off a virtualization platform that was never designed with that in mind!). What about the original network setup? Is that still emulated, or might some cust…

I don't know the details of this particular migration, but I used to have a VM in some low-price tier that was running for a long time (few years), and, eventually AWS sent me an email telling they are going to shut it down for maintenance reasons. Guess this was something similar. VMs, if not specifically configured to be able to move cannot really be moved automatically. Think about eg. randomness of ordering in PC…

> Think about eg. randomness of ordering in PCIe bus (i.e. after moving the devices may not come up in the same order as before moving), various machine ids, like MAC address -- if you don't make sure VM isn't affected by these changes, it's likely that it will be, if moved.

QEMU/KVM/libvirt/... are idempotent when it comes to hardware the VM sees - the exception is the CPU model, that one can't be changed on the fly without at least rebooting the VM in question, and hardware in passthrough mode like GPUs.

All the VM sees from a live migration is a few seconds of "lost" time, as if someone had stopped the CPU clock.

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

#99
post #6

I still remember when I worked at Serif and we needed web hosting for our new social media website that would be integrated into our scrapbooking desktop software. There were a lot of shiny new technologies around at the time (as there always are). One of them was Microsoft Silverlight, and we implemented its "Deep Zoom" into the website so our users could easily zoom around in the scrapbooks that got published and e…

I remember those days, there was no database layer at AWS so we used instances with Elastic Block store for durability.

Yup, and for performance, you would RAID Stripe a bunch of EBS volumes together. But sometimes you'd get a volume on a noisy neighbor, and its performance would be terrible.

Where I worked at the time, I wrote some Chef tooling that would hdperf the volumes it provisioned, and if some weren't any good it would provision more until it got 8 good ones. Only then would it RAID them together, then deprovision the bad ones.

Now they have provisioned iops, and I haven't seen a slow EBS volume in a decade.

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

#100
post #31

This is a level of support all software companies should aspire to. It's also what the enterprise likes to see and will give you money for.

I continue to choose AWS for the companies I work at not because their offerings are better, but because their support is so far superior.
Post reply on HN