Live data from Hacker News

AWS S3: Sometimes you should press the $100k button

cyclic.sh

61–70 of 240 posts

Re: AWS S3: Sometimes you should press the $100k button

#61

Earlier quoted context omitted.

>There’s no delimiter. What's the delimiter parameter for then? https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListObje...

To help you fool yourself. It affects how object list results are presented in the api response.

"To help you fool yourself" seems like a euphemism for "to fool you". It's gotta be tough to go from "scant knowledge of S3" to genuine knowledge if the documentation is doing this to you.

If the docs are misrepresenting the details, who can blame the author of the post?

Re: AWS S3: Sometimes you should press the $100k button

#62
post #12

TL-DR: Object stores are not databases. Don't treat them like one.

Try telling that to developers; they love using S3 as both a database and a filesystem. It's gotten to the point where we need a training for new devs to tell them what not to do in the cloud.

You can either train them with a calm tutorial or you can train them with angry billing alerts and shared-pain ex-post-facto muckraking.

I, for one, prefer the calm way.

Re: AWS S3: Sometimes you should press the $100k button

#63
post #52
post #22

Your website renders as a big empty blue page in Firefox unless I disable tracking protection (and in my case, since I have noscript, I have to enable javascript for "website-files.com", a domain that sounds totally legit).

The problem is that the DIV that contains the main text has the attribute 'style="opacity:0"'. Presumably, this is something that the JavaScript turns off. A lot of sites like to do things like this for some reason. I haven't figured out why. I like to use Stylus to mitigate these if I can, rather than enabling JavaScript.

The page animates in. I have no idea why it does, but it does, which explains why the opacity starts at 0%.

Re: AWS S3: Sometimes you should press the $100k button

#64
post #7
post #3

We’ve got data in S3 buckets not nearly at that scale and managing them, god forbid trying a mass delete, is absolute tedium.

Mass delete also takes an eternity on my Linux desktop machine. The filesystem is hierarchical, but the delete operation still needs to visit all the leaves.

(This is a good example where Garbage Collection wins over schemes which track reference explicitly, like reference counting. A garbage collector can just throw away the reference, while other schemes need to visit every leaf resulting in hours of deletion time in some cases.)

Re: AWS S3: Sometimes you should press the $100k button

#65
post #52
post #22

Your website renders as a big empty blue page in Firefox unless I disable tracking protection (and in my case, since I have noscript, I have to enable javascript for "website-files.com", a domain that sounds totally legit).

The problem is that the DIV that contains the main text has the attribute 'style="opacity:0"'. Presumably, this is something that the JavaScript turns off. A lot of sites like to do things like this for some reason. I haven't figured out why. I like to use Stylus to mitigate these if I can, rather than enabling JavaScript.

mitigation for a flash of unstyled content (FOUC) maybe?

Re: AWS S3: Sometimes you should press the $100k button

#66
post #52
post #22

Your website renders as a big empty blue page in Firefox unless I disable tracking protection (and in my case, since I have noscript, I have to enable javascript for "website-files.com", a domain that sounds totally legit).

The problem is that the DIV that contains the main text has the attribute 'style="opacity:0"'. Presumably, this is something that the JavaScript turns off. A lot of sites like to do things like this for some reason. I haven't figured out why. I like to use Stylus to mitigate these if I can, rather than enabling JavaScript.

This is a common anti-pattern — I believe they're trying to ensure that the web fonts have loaded before the text displays but it's really annoying for mobile users since it can add up to 2.5 seconds (their timeout) to the time before you can start reading unless you're using reader mode at which point it renders almost instantly.

Re: AWS S3: Sometimes you should press the $100k button

#67
post #60

The AWS horror stories never cease to amaze me. It's like we're banging our heads against the wall expecting a different outcome each time. What's more frustrating, the AWS zealots are quite happy to tell you how you're doing it wrong. It's the users fault for misusing the service. The reality is, AWS was built for a specific purpose and demographic of user. It's now complexity and scale makes it unusable for newer d…

In this case it is absolutely the user 'doing it wrong'.

AWS allows you to store gigantic amounts of data, thus lowering the bar dramatically for the kinds of things that we will keep.

This invariably creates a different kind of problem when those thresholds are met.

In this case, you have 'so much data you don't know what to do with it'.

Akin to having 'really cheap warehouse storage space' that just gets filled up.

"It's now complexity and scale makes it unusable for newer devs. I'"

No - the 'complexity' bit is a bit of a problem, but not the scale.

The 'complexity bit' can be overcome if you stick to some very basic things like running Ec2 instances and very basic security configs. Beyond that, yes it's hard. But the 'equivalent' of having your own infra would be simply to have a bunch of Ec2 instances on AWS and 'that's it' - and that's essentially achievable without much fuss. That's always an option to small companies, i.e. 'just fun some instances' and don't touch anything else.

Re: AWS S3: Sometimes you should press the $100k button

#68
post #45

sigh . My team is facing all these issues. Drowning in data. Crazy S3 bill spikes. And not just S3 - Azure, GCP, Alibaba, etc since we are a multi-cloud product. Earlier, we couldn't even figure out lifecycle policies to expire objects since naturally every PM had a different opinion on the data lifecycle. So it was old-fashioned cleanup jobs that were scheduled and triggered when a byzantine set of conditions were m…

The data protection regulations really are so freeing, huh. It's amazing to be able to delete all this stuff without worrying about having to keep it forever.

now this is a spin i havent heard before.

Re: AWS S3: Sometimes you should press the $100k button

#69
post #45

sigh . My team is facing all these issues. Drowning in data. Crazy S3 bill spikes. And not just S3 - Azure, GCP, Alibaba, etc since we are a multi-cloud product. Earlier, we couldn't even figure out lifecycle policies to expire objects since naturally every PM had a different opinion on the data lifecycle. So it was old-fashioned cleanup jobs that were scheduled and triggered when a byzantine set of conditions were m…

Disclosure: I'm Co-Founder and CEO of a cloud cost company named https://www.vantage.sh/ - I also used to be on the product management team at AWS and DigitalOcean.

I'm not intentionally trying to shill but this is exactly why people choose to use Vantage. We give them a set of features for automating and understanding what they can do to manage and save on costs. We're also adding multi-cloud support (GCP is in early access, Azure is coming) to be a single pane of glass into cloud costs.

If anyone needs help on this stuff, I really love it. We have a generous free tier and free trial. We also have a Slack community of ~400 people nerding out on cloud costs.

Re: AWS S3: Sometimes you should press the $100k button

#70

Earlier quoted context omitted.

AWS does the optimizations over time based on access patterns for the data. Should have made that clearer in the article. The problem becomes unusual burst load - usually from infrequent analytics jobs. The indexing cant respond fast enough.

Thanks for the clarification. But now I'm confused about the limits: > 3,500 PUT/COPY/POST/DELETE requests per second per prefix > 5,500 GET/HEAD requests per second per prefix Most of those APIs don't even take a delimiter. So for these limits, does the prefix get inferred based on whatever delimiter you've used for previous list requests? What if you've used multiple delimiters in the past? Basically what I'm tryin…

Those are what I would assume for performance when the system is stable. The concerns come from bursty behaviour — for example, if you put something new into production you might have a period of time while S3 is adjusting behind the scenes where you'll get transient errors from some operations before it stabilizes (these have almost always been resolved by retry in my experience). This is reportedly something your AWS TAM can help with if you know in advance that you're going to need to handle a ton of traffic and have an idea of what the prefix distribution will be like — apparently the S3 support team can optimize the partitioning for you in preparation.
Post reply on HN