[m0xte]

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.

[makebelieve]

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.

[meddlepal]

> 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.

[Can_Not]

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

[scarface74]

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.

[mech422]

>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 :-)

[mrweasel]

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.

[EMM_386]

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?

[scarface74]

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.

[freehunter]

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

[cthalupa]

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.

[itomato]

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

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