Live data from Hacker News

I returned to AWS and was reminded why I left

fourlightyears.blogspot.com

621–630 of 684 posts

Re: I returned to AWS and was reminded why I left

#621
I generally agree with this, especially the Lambda and DynamoDB advice.

DynamoDB: I think DynamoDB is great, actually, if you think about your use cases up front and thoroughly. For most apps, that just isn't realistic and it is too easy to paint yourself into a corner. If you're not sure what you're doing, you are better off with a traditional database.

Lambda: Don't use it for your backend / API. There are too many weird limitations: request and response sizes, timeouts, etc. For handling "events" emitted by other AWS services, it is often fine (example: do something when there is an S3 upload.) I prefer ECS/Fargate for API.

Re: I returned to AWS and was reminded why I left

#622
post #572

AWS / GCP / Azure aren't for individuals or small businesses. They won't tell you this anywhere, and they won't stop you from signing up - but they simply do not care one iota about users with anything less than $100k billing per month. They treat big account owners like kings, they fly them out to Formula 1 events, they get 3 day workshops in swanky retreats, because a few k spent on this equals maybe millions of do…

All good points. What do you recommend for the "small potatoes"?

I'd go with a smaller VPS-focused provider like Vultr.

Re: I returned to AWS and was reminded why I left

#624

Hmm... I was very early AWS, and it might even be "the guy from the US" that spoke at the first AWS Melbourne event was me, back in 2010. I agree with few of the things that have annoyed Andrew Stuart, and brought him to leave. I disagree with a few. Let's pick one: DynamoDB was brilliant. I even knew one of the key engineers behind it, Stefano Stefani, as brilliant as he was hilariously funny as a person. It solved…

No it wasn’t you Simone. I don’t think you had joined AWS at this time. It was a nice guy I think named Mike. He has since passed away. I think you misunderstood the blog post. I was never employed by AWS, I was a customer. Since there’s people here from AWS I’ll give some feedback that might prevent posts like this……. if you suspend/restrict someone’s account - put yourself in their shoes - they probably want it bac…

There's many reasons to dislike a company or service. I know.

It is not a good reason to look for employment to "get in and out". If I were your hiring manager, I would be upset to know.

Mike Culver, great guy and a bit of a mentor to me. Yes, very sadly he passed away several years ago now. RIP.

Re: I returned to AWS and was reminded why I left

#625
post #559

I'm surprised by the author's hate towards DynamoDB. It's probably one of my favorite AWS Services. Great availability and no operational overhead. Cost was pretty minimal too each time I've used it, but you do need to spend some time architecting your data model up front, and that requires reading service docs and understanding it.

I might be holding it wrong, but last time I tried to use DynamoDB it made absolutely no sense performance-wise to me. Postgres on my laptop was many orders of magnitude faster for fraction of price. It seemed like it maybe might make sense when you hit multiple TBs of database data and can no longer run on a single server? But then the costs would be sky-high and you probably could engineer your way around this with…

It's hard to do apples to apples performance with postgres - it really does depend on the data model and how you interface with it, but the thing about performance for DDB is that it can be very consistent. Pricing also depends a lot on your access patterns and data structures.

For me though, it's not having to worry about DB uptime, performance, or version updates that keeps me reaching for DDB even for small hobbyist stuff. But I'm also comfortable architecting for it, probably more comfortable than I am for traditional dbs, so that's a huge part of it.

Re: I returned to AWS and was reminded why I left

#626
post #579

Earlier quoted context omitted.

All good points. What do you recommend for the "small potatoes"?

Hetzner. You won't get much better support, and you will have to deal with EU legislative nonsense, but it won't be hard to do that if you are actually small. Why do I say Hetzner? It's very budget friendly and has a very small list of services so its much harder to screw yourself into a situation where its hard to leave.

Hetzner has the most unintuitive UI out of any host I've ever used in 20+ yrs of using different web host. Spending hours trying to do basic things, and even AI couldnt help. Switched to one of their competitors after 2(!) days of trouble shooting and got the same basic task done in ~10 mins.

Re: I returned to AWS and was reminded why I left

#627
post #209

Earlier quoted context omitted.

A lot of these projects work on a business model where they open-source their core product, and provide advanced services, installation, maintenance or fully-managed services around their product. AWS was bypassing them by providing fully-managed services. On this, I am on the side of the people behind the projects. Basically AWS was eating their lunch. They had no choice but to change the licenses.

> They had no choice but to change the licenses. Then why did they advertise themselves as open-source efforts when they weren't? They should have been the best possible providers of managed service offerings given they wrote the software they'd be managing, no? Why are monopolies OK here but not elsewhere? Choosing a hard-to-win business model is not supposed to be a choice that guarantees you business income.

Companies are making a trillion dollars on Open Source free code then maybe donate 50k to that project. People are spending huge amounts of time , stress, their lives, to help these projects. Companies have proved themselves to be very self centered. CEOs getting 2x yatchs and 5x houses while Open Source guys are trying to figure out which grocery store has the cheapest food items.

Re: I returned to AWS and was reminded why I left

#628

sorry to hijack this but since we're talking the AWS egress exorbitant prices, could someone recommend a reliable production-tested s3 service that will not ruin me financially? i have been with hetzner and while their vps server are great, they are absolutely terrible at s3. random downtimes, incomplete uploads/downloads, capacity issues, terrible api key management, etc - but the failure rate is really high

Check out Tigris: https://www.tigrisdata.com/

Re: I returned to AWS and was reminded why I left

#629

Earlier quoted context omitted.

3 things to untangle here. 1. It's about trust and auditability, while you may not want or need it, there are a lot of customer that are either interested or legally obligated to know who have accessed certain data. 2. It's about dogfooding - how would you trust an identity and access system when the company does not even use it internally? 3. In general, there are quick buttons and template to do it if you don't wan…

That's all fine and good, but I still don't know how much trust the EBS team versus the ALB team. And I don't think you do either.

You don't need to trust EBS or ALB team. You just have a contract that says whether ELB/ALB get access to your data/resources or not.

Also the access are not "team", it's software. The control plane would have access to resource if you granted the service principle and then it would go ahead to do what was already written as service logic for those resource. The engineers do not gain access to your resource now - all prod service principles are access gated and we can only see certain non-PII logs as required by operational events. We don't run the service manually.

Re: I returned to AWS and was reminded why I left

#630

Earlier quoted context omitted.

IAM is NOT from any lineage. It has grown organically and is complicated, just as any other policy language. AWS even uses an automatic proof assistant to verify IAM policies. However, the secret to IAM in AWS is to NOT use IAM. Just create separate AWS accounts for separate services and only share whatever resources are needed. Then you can have dead simple IAM policies because you won't need to do granular permissi…

> Just create separate AWS accounts for separate services My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic. I've been irritated at AWS (and the other large cloud providers) that they charge $0.01/GB for cross-az traffic. That's $3.24/Mbps -- about the same I was p…

> My understanding is that different AWS accounts have different mappings of availability zones, so it's very easy to suddenly find yourself with an unexpected bandwidth bill due to all the cross-az traffic.

As far as I remember, accounts within the same organization will have the same mapping. You also can use stable zone names these days, instead of the regular mappings.

And yeah, egress traffic pricing is freaking insane at this point. It's the biggest reason to NOT use AWS.

Post reply on HN