Farewell EC2-Classic, it’s been swell
181–187 of 187 posts
Re: Farewell EC2-Classic, it’s been swell
#182"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.
That was jarring for me, I wasn't quite sure what the article wanted to say at first. Title "we're doing X", body "we don't do X here".
Re: Farewell EC2-Classic, it’s been swell
#183Earlier quoted context omitted.
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…
Re: Farewell EC2-Classic, it’s been swell
#184Ec2 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…
Re: Farewell EC2-Classic, it’s been swell
#185Ec2 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…
The public IPs were the big part: if you had the default 0.0.0.0/0 rule allowing SSH, you’d see brute force attacks within a few seconds of launching a new instance. VPCs gave a little more room to prevent that but the big thing was really better tooling - the average developer still doesn’t think about security enough to be trusted with the EC2 or GCP launch wizard.
Re: Farewell EC2-Classic, it’s been swell
#186Earlier quoted context omitted.
The public IPs were the big part: if you had the default 0.0.0.0/0 rule allowing SSH, you’d see brute force attacks within a few seconds of launching a new instance. VPCs gave a little more room to prevent that but the big thing was really better tooling - the average developer still doesn’t think about security enough to be trusted with the EC2 or GCP launch wizard.
I remember this. I don’t remember if it was cloud unit or something else like a pre hardened ami, but basically that - you got hammered in seconds after starting in default config so was good to take some steps right on launch.
Re: Farewell EC2-Classic, it’s been swell
#187"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.
Once you got up to the levels of AWS CAFO-style "cattle" instances, it stopped making so much sense. With autoscaling, you need your configuration to be baked into the AMI before it boots, otherwise you're going to be in a world of hurt as you try to autoscale to keep up with the load but then you spend the first thirty minutes of the instance lifetime doing all the configuration after the autoscale event.
A wise Chef once told me that "auto scaling before configuration equals a sad panda", or something to that effect.
Chef did try to come up with a software solution that would work better in an AWS Lambda/Kubernetes style environment, and I was involved with that community for a while, but I don't know what ever became of that. I probably haven't logged into those Slack channels since 2017.
IMO, there are much better tools for managing your systems on AWS. CDK FTW!