Hacker News Reader

Comment by drchewbacca | Hacker News Reader

I hate AWS so much.

I spent 3 hours trying to get a bucket to host a static single page of html and failed completely.

I use amazon polly. I wanted to know how many characters I was using each month. I spent 2 hours searching through hundreds of pages and literally couldn't find that information.

I thought of trying to start a little text to speech service for dyslexics to make it easy to use Polly but one of the main thing putting me off is having to get my arms mangled in the AWS machine.

The whole thing is so totally maddening. I would love to be able to sit in on their meetings where they talk about usability, what do they say? Do they think everything is fine? Do they know it's totally broken and don't care? Are they unable to hire a UX designer? What is the problem?

View on HN

If you hate AWS so much, wait until you use Azure. Worst support ever. UI not in sync with the az-cli, documentation super chaotic, lots of basic features from AWS not yet supported in Azure.

From my experience, AWS has up-to-date documentation pages for everything. And when something is hard to understand from their docs, you can find really everything you need by searching on Google. Literally, everything. And if you ask the support forum, you'll be provided with an answer in relatively short time. Competent answers most of the time.

So, what's the alternative to the ugly AWS web console? Learn the basic concepts, and maybe use the aws cli.

Speaking about the bucket -> https://medium.com/@P_Lessing/single-page-apps-on-aws-part-1...

My experience is exactly inverse to yours. IMO Azure's documentation, in general, is far superior to AWS's. And my experience with Azure support has been stellar.

Azure’s documentation is plentiful, which is good, but it’s also confusing (the same topic might be covered in different ways among two pages, some of it will likely be obsolete because last week the interface changed again, etc...) which is bad.

Knowledge management is hard.

> some of it will likely be obsolete because last week the interface changed again, etc...) which is bad.

One of the problems with the Azure documentation is that the API endpoints are versioned (?api-version=yyyy-mm-dd) but the documentation doesn't make it easy to find the relevant version or see the differences between versions.

The interfaces don't change if you pin to a version.

I've been deep diving on Azure for awhile (and have worked extensively with AWS and GCP in the past) and in general I find both Amazon and Azure's docs to have the plentiful but confusing problem. Google's documentation is slightly different... I can never seem to find what I'm looking for but when I do it's comprehensive and complete, but then I can't find it again the next time I need it.

The big pain point with Azure is wrapping your head around Active Directory and AD IAM if you come from a non-AD world. I still vastly prefer Amazon's IAM system to Azure's (Google's is just a confusing mess and needs to be redesigned.)

I just had flashbacks to the one and only Azure project I ever worked on. I don't know if they were in a transition phase but it was exactly as you described and I wasted days setting up some simple services for our team. Give me AWS any day.

I had the exact opposite experience, and we ran our entire company off of Azure for 3 years without any issues.

The only complaint I had was when I needed to rapidly get like 15 N-Series GPU instances and it took like two months. At the time they were new so weren't allocating them as quickly as they do now. Amazon was way faster for us to get GPUs running on - but this was over two years ago now so I'm not sure if that's still the case.

For me that isn't the problem. It's mapping the several-thousand acronym riddled hairballs into reality. The reality matches no other reality which means the knowledge is probably useless in 20 years time, much as the knowledge I had of proprietary stuff then is useless now. My head has only a certain amount of space and motivation for ephemeral complexity hairballs like AWS.

At this point I have to wonder if this is intentional. It makes it difficult to escape if all you know is AWS's reality abstractions.

Being in technology means constant learning. My knowledge of the intricacies of the 65C02 in the 80s, working with DEC VAX and Stratus VOS in the 90s, knowing MFC and DCOM in the 2000s, etc all useless.

When I started learning AWS, it was quite simple mapping what I’ve done for over 20 years on prem from both a development and networking perspective.

>My knowledge of the intricacies of the 65C02 in the 80s, working with DEC VAX and Stratus VOS in the 90s

VOS rocked! Loved the old Stratus boxes :-)

The last point is echoed in every IaaS and CM product.

As with any "convenience tech", learning the underlying protocols is essential.

I second this. I found it easier to spin up servers on other services and run big install scripts than to try do decode Amazon's naming/acronym hell. The requirement to connect invented names to computational activity is big overhead.

I guess each AWS service get's named it's own thing as it is developed and those names just stick forever. it is maddening. Reading the docs outloud often sounds like a weird technical Dr. Seuss. I've never looked at Azure, but since Microsoft has been the king of making up their own names for things, I expect it to be just as bad.

I wonder how this naming issue comes about. If AWS devs and early adopters are doing this as their first big rodeo, then everything might seem new and they get to invent names - as if the computing were new. But after these devs and early adopters work on 2 or 5 of these kinds of projects in different environments they will see that special naming is a mistake, because it makes it incredibly hard to communicate about the same computing tasks using dozens of different names and acronyms.

I know computing requires continuous learning, but specialized naming tends to obfuscate higher order abstractions. And if you grok the higher order abstraction and want to dev a system, then the naming and minute computing differences make development on any given service harder than it needs to be because it requires learning specialized lingo. As human beings we need to get much better at getting to standard names and conventions faster. It will speed all our development.

> I've never looked at Azure, but since Microsoft has been the king of making up their own names for things, I expect it to be just as bad.

I use Azure and the naming is pretty straightforward. It's entirely unlike Amazon in that regard and also very unlike classic Microsoft.

It feels like they're trying to vendor lock your vocabulary.

The naming system ... Route53, Fargate, Greengrass, Sumerian, Step Functions, Kinesis ... none of these conjure up basic computing concepts.

Why? Why should "Greengrass" be used for IoT?

Route 53: What port do you use to connect to DNS?

But the rest, I’ve got nothing as far as making the naming conventions make sense.

But honestly it took me about a year to go from not knowing anything about AWS to being sable to hold my own from a development and networking/Devops standpoint with AWS. Almost everything mapped to concepts I had done before - even the IOT stuff from my time developing field service apps for old Windows CE ruggedized devices.

I could basically draw up an architectural diagram of how I would have implemented the same systems today if I had had AWS at my disposal.

Not to mention they have two products named EBS: Elastic Beanstalk and Elastic Block Storage. Makes work conversations real fun.

I haven't used Beanstalk in forever, and don't think that it's particularly relevant compared to other alternatives available today, but last time I did, AWS support always abbreviated it to EB when I had to work with them on issues related to it.

Right, the naming "scheme" for AWS is insane. I think one of the reason for the terrible web UI is the fact that AWS does so much, and they just cram everything in upfront. One of the things I feel Azure does very well is showing you the bit you're most likely to use, especially if you're new to the platform (that and they just call stuff be names that makes sense, a VM is a VM, not an EC2 instance). The more advanced feature are available, but not in your face from the beginning.

As for documentation: I don't think that neither AWS nor Azure have excellent documentation. The Azure documentation lacks depth, the AWS documentations is just throw together, things that are part of the same system is documented wildly differentially, e.g. some CloudWatch metric are complete, how you use them, which dimensions are available for which, and you get example. Other parts of CloudWatch: "Well we have some metrics and these dimensions, have fun figuring out which goes together.

I completely agree. I feel stupid everything I try use AWS. I have a pile of credits in my account that I am not using because I cannot bear to try (and fail... Again).

It's maddening and they clearly do not care.

What's your level of experience with ops/networking etc.? Because it all boils down to that. If you need a simpler service, maybe you could use digital ocean etc...

Technically you're right of course but I think you miss the broader point. AWS is ludicrously complicated and overkill for most startups, like a corner store implementing SAP. The problem is it's the gold standard for "cloud" and choosing anything else (apart from GCS, perhaps) attracts the need for justifications and, ultimately, unwelcome accountability. "Nobody ever got fired for [choosing AWS]".

I'd personally love it if AWS implemented a digital ocean-like "basic" interface which, realistically, covers 90% of startups' needs. Simple is good. If needed, they can switch over to "Fortune 500 mode" later.

> I'd personally love it if AWS implemented a digital ocean-like "basic" interface which, realistically, covers 90% of startups' needs. Simple is good.

Have you looked at Amazon Lightsail? It might be closer to what you're after.

https://aws.amazon.com/lightsail/

I use lightsail and route53. Oddly lightsail doesn’t show up on the “frequently accessed” shortcuts

Your startup on AWS is either capable of developing their platform in house or contracting one of many solution architects.

They may be so lean they exclusively run lambda jobs and host from S3. This is a 24 hour learning curve.

>> "Nobody ever got fired for [choosing AWS]".

"Hey Joe, the app you built for Goldberg Partners uses AWS right?"

"Yeah."

"What does it do on AWS again? Store some files?"

"Yeah, and a load balancer in front of a few containers that handle thumbnail generation for those images. Pretty standard stuff."

"I see. What was their pricing like?"

"Last time I checked, the billing page said something like $0.023 per GB for the first 50 TB or something like that, and $0.0116 per hour for the containers. I don't remember the load balancer pricing, but it should be pretty cheap, we don't have that much stuff on there."

"Interesting, okay. Can you explain why they sent us a bill for $10,372.77?"

I think you’re right on. I worked as a lead for a startup that ended up with all these credits in SoftLayer years ago, and we steered into a Vyatta network setup that was fairly complicated and I had to really learn a bunch of networking in real-time. But understanding a lot of underpinnings made it super easy to map to aws primatives, and appreciated because what they do with vpcs/networking kills so much complexity.

Usually when I’m getting into a new area of aws I try to find what they’ve built the technology with. Then I try to go get a good base in that technology, then figure out what AWS has done and understand why/reasoning. This also helps alleviate common concerns about only learning some aws stack. Learn both things, one might one day become less relevant, the other will help you build solid base understandings that last longer.

Just curious, where and how would one get credits in their AWS account?

Uploading a single file to S3 seems like it should be a simple job, that is well-documented:

https://docs.aws.amazon.com/AmazonS3/latest/user-guide/uploa...

There are parts of AWS that are hard to use, and non-intuitive. But S3 didn't ever seem to be one of them, though perhaps I'm forgetting how hard it was initially.

You might consider a "friendly" system for static hosting if raw-S3 is too hard though, such as netlify. There are a lot of services out there which basically wrap and resell AWS services. (I run my own to do git-based DNS hosting, which is a thin layer upon the top of route53 for example.)

Ha, I can't upload anything into S3. I'm unable to, from memory, create or modify any of my own buckets. My account is in some weird half-suspended state from a past billing incident, long resolved, where things mostly work - but modifying S3 is not one of them. Support insisted everything was fine even as I uploaded videos of the failures and eventually I just gave up.

I leave a few legacy things running there (billing works, of course) but these days just put personal stuff on Digital Ocean, which seems to meet basically all my needs without the complexity and cheaper to boot.

Uploading to S3 is easy until it isn't. It works pretty nicely for one-offs but when you have to blast a few hundred gigs into it or large files from a bit of software you wrote it's a royal pain in the butt. The phrase "multi-part upload" makes me cry inside.

Why is that hard? The CLI automatically does multi part uploads. It’s also simple with the various AWS SDKs.

It looks like it works but it's not reliable so your reliability concerns then get externalised into your application which multiplies complexity terribly.

What do you mean by it's not reliable?

I’ve never had the experience myself, but I would assume he means you would have to build in some type of retry logic in your script.

Just from a cursory glance, I couldn’t find any samples of how to do a multipart upload with retries in Python with Boto3.

This is an example of how to do multipart uploads though.

https://medium.com/@niyazi_erd/aws-s3-multipart-upload-with-...

Fun Trivia note: when you do a multipart upload, the S3 hash of the object is not the same as it is when you do a single part upload. I had a file with the same contents but a different hash when I used Python than when it was transferred with the CLI or CloudBerry. The quick and dirty way to fix the hash is to copy the file to itself with Boto3.

Yeah I managed to get the file into the bucket. However I couldn't get the permissions to let it be publicly visible despite working through several tutorials.

I ended up on Netlify, it's 1000x more my speed.

I've never used S3 to host a website before so I decided to try this and see if it's really that complicated.

First, I searched for "host static website on S3" and found an AWS docs page with a walkthrough.

Then, I created an S3 bucket through the console. I uploaded a "hello world" index.html file to it.

Then I went to Properties, checked "Use this bucket to host a website" and gave it the name of my index file. When I clicked Save, I had a hosted HTML file that I could navigate to.

I'm struggling to see how it could be simpler than that. What exact problems did you run into?

So this was a while ago and I fully admit it might have been me being stupid.

However when I was doing it I don't think there was a "Use this bucket to host a website" button. Instead you had to give the bucket a special type of permissions which meant anyone could see the contents but no one could write to it. I kept following the guide as closely as I could but I couldn't get it to take.

Maybe it's been updated since then. This is the guide I followed: https://docs.aws.amazon.com/AmazonS3/latest/dev/HostingWebsi...

Ok yeah I think it was changing the policy that access I couldn't get to work.

Again it may be that is super easy and I fucked up something obvious however I tried a lot of times a lot of different ways until I gave up in rage.

Did you see https://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteHosti...

I'm of two minds about this.

On the one hand, the cloud is a meaningfully different abstraction from hosting locally, and figuring out how to do things effectively with it end to end without prior experience is a little bit like going from Windows to Linux, or back.

On the other hand, the use case you describe is one of the most basic, standard and well documented out there.

I’ve had these same experiences, only with GCP, not AWS.

Reply on news.ycombinator.com