Hacker News Reader

Comment by justin_oaks | Hacker News Reader

The complexity of the cloud exists because the cloud vendors allows a user to do advanced things if the user understands how. Using AWS, GCP, and Azure as Infrastructure-as-a-Service (Iaas) means that there's no easy mode.

If you want easy (or easier) mode, you'll have to use a Platform-as-a-Service (PaaS).

The major cloud vendors might have problems with quirky designs and poor documentation, but beyond that is necessary complexity.

You want a high-availability website allows user-uploaded files and does asynchronous task processing? You're probably going to have to get familiar with servers, load balancers, queues, and object storage, at a minimum.

You want it all to be secure? You're going to have to configure network rules/firewalls and set up lots of access policies.

There's no free lunch.

View on HN

How many totally-different-yet-common sets of requirements are there for user uploads or task processing do you think there are that necessitate the ultimate flexibility and complexity? I suspect vendor lock-in is a more likely cause of the complexity.

> I suspect vendor lock-in is a more likely cause of the complexity.

I think people give large organizations credit for being mustache twirlingly evil when the collective consciousness that makes up AWS is simply not smart enough to be this evil. If AWS had the coordination to do this the product would be better.

It's much more likely that the complexity is the result of a huge number of teams working independently and integration complexity being 2^n. Like AWS had one good transformative idea to make coordination easier which is to be API first but that only forces superficial consistency.

AWS and Amazon for that matter didn't just happen. There absolutely is a lot of enterprise architecture and strategy built into them with the goal of capturing markets and extracting rent. Corporations exist for the exact reason that this is possible.

This seems seriously naive.. its not mustache twirling evil, it is business and its a big part of it to build moats and prevent yourself from unintentionally filling it in. Businesses absolutely will maintain worse functionality if improving it can aid a competitor.

"You want a high-availability website allows user-uploaded files and does asynchronous task processing? You're probably going to have to get familiar with servers, load balancers, queues, and object storage, at a minimum."

Really? I disagree. I could probably build that with Rails and Heroku in an afternoon, after creating a single S3 bucket and an access key for presigned POST. AWS has "necessary complexity" in the same way a giant hole in your head improves your brain's cooling potential. (i.e. maybe, in some very rare cases, but you almost certainly don't need it)

Now scale it to twenty million concurrent users.

Are you kidding me? Amazon, on their biggest day of the entire year (Prime Day), reached peak traffic of approximately 290m requests per minute through CloudFront. I would bet that loading a single Amazon page uses much less than a minute and serves more than 10 requests per page load.

If you're not going to be as big as the entirety of Amazon you don't need to serve 20 million concurrent users. Ever.

Ok, pick whatever smaller number makes you happy then. My point is just as valid with 100k concurrent users.

All of these are basic requirements. Yet they're available for use only after AWS specific proficiency. Why do I need an AWS setting to permit DB access when the DB had that feature already? I don't need the extra layer of complexity AWS puts on most things.

Tangent - Their docs are abysmal. Written like a novel which I'm meant to cross reference to their SDK.

Only partly agree, definitely not all complexity there is necessary.. part is vendor lockin and another one is their own grown complexity due to rewiring/wrapping their own stuff for reuse in different forms.. and grown complexity that maybe made sense at some point, but grew too much - as almost everywhere.

Are you saying that there is already only little incidental complexity and friction, and it's mostly essential to the problem domain?

What evidence or convincing arguments are there for your position?

For me it seems clear that this is not the case, the needless friction in eg CDK dev experience seems ridiculous.

> The complexity of the cloud exists because the cloud vendors allows a user to do advanced things if the user understands how.

The complexity of the cloud exists because it wasn't designed very well and all reactionary.

You look at AWS and it feels like things are getting tacked on because there's "demand" instead of thinking of what the platform should look like and building it out. Every service is done by a different team that doesn't talk to each other as well. There's no consistency anywhere.

> If you want easy (or easier) mode, you'll have to use a Platform-as-a-Service (PaaS).

It's been blurred a long time ago so how do you make this distinction? They all have PaaS features / services.

> There's no free lunch.

You had to pay to begin with so what's free?

Yeah wait till you need to do SOC2 and friends! Azure has tools to help you with this.

The "free lunch" was sold in a form of the hybrid cloud orchestrator. These pretended to make all clouds look the same, but were more shallow layers of abstraction that didn't add much value.

to be fair it was a brilliant play. my sympathies go out to all those who ended up holding the bag.

this is true, but doesn’t stop mistakes from being made or criticism from being useful.

Reply on news.ycombinator.com