Not sure what that second sentence means...
the names have a logic to them but I agree it’s intimidating to learn hundreds of things at the same time - so you don’t. you learn the bits and pieces you need.
for example:
EC2 actually comes from Elastic Cloud Compute. You have Compute in the Cloud which also happens to be elastic.
S3 is Simple Storage Service. It’s a Service for Storing things. It’s simple because it’s just a key-blob storage.
Route53 is obvious if you know what runs on port 53.
There are loads of AWS services that don’t follow any logic, they’re just distinct, easy to spell nouns.
It's a tongue in cheek about https://en.wikipedia.org/wiki/Redshift#Expansion_of_space and how
> Snowball
It's like Glacier, but it's smaller and moves more quickly. I think this is one of the dumb-codenames-turned-real that crop up from time to time. Fargate is another notable example.
> Chime
A chime is a notification. That's about all I got.
> Route 53
DNS runs on port 53, Route 66 is a famous highway.
> Sumarian
It's a really niche joke about the novel Snow Crash, that popularized the concept of digital "avatars".
Route 53 - DNS runs on port 53
Chime - when you want to talk about something “let me Chime in”.
Snowball and Sumerian. I got nothing. I didn’t even know what Sumerian was until I looked it up and I thought I had at least heard of most AWS services.
https://aws.amazon.com/products/
look up your service. each service has a 1 line description that captures what it does.
eg Athena = query data in s3 using sql
i don’t really get why people cannot be bothered to learn what a service does and want to pretend they get it from the name. you need to learn the ins and out of the service. the name is the least of your worries.
Names matter.
When your first experience with a product is an opaque name or description, it usually tells you one of two things:
1. The people behind it are not good communicators. If so, this will likely show up in many of the other product details: APIs, documentation, complexity.
2. The people behind it deliberately chose to be opaque. Perhaps they want to make the product seem more important than it is. Perhaps they thought marketing jargon would help sales. Etc.
You seem to want to frame this in terms of developer laziness, but I don't think that's right. Both of these are often reliable signals. The criticism here is well-justified.
The tech world is gibberish. The real world is gibberish too, but the comparatively large number of tech products (because of the ease of releasing software) really exacerbates the problem in tech. Everything is a code name, in-joke, or initialism.
If this were limited to public products then you could write it off as overly ambitious branding, but you can tell it's an issue because internal products suffer the same problem. You know it's bad when you can't even navigate your own company's hierarchy because you don't know what half the team names mean.
Unfortunately, this will probably never change; there's too much precedent. Naming things incomprehensibly is fun, it creates a barrier to entry that makes developers feel smart, and the tech world doesn't value communication enough to change it. In a world where stackoverflow serves as de facto documentation for many major tech products because their own documentation is terrible, I hardly expect those same companies to value coherent naming.
I look at the front end web ecosystem and I think it’s all gibberish also and I’ve been using Javascript off and on since it was first in beta for Netscape. But thousands of people take the time to learn it.
The claim isn't that better names help you ramp up faster. It's that they make it faster to figure out which service you need, or if a service is relevant to you. That said, per the point in my previous post, it's likely that if you can't even clearly describe or name your service, you can't write clear documentation either. I've found that's often the case.
> But thousands of people take the time to learn it.
I don't understand what argument you're making. Is it: Since some subset of people will invest time in learning technology even if it's complicated, therefore it doesn't matter if it's too complicated? If so, you'd have to show that the number of people using it wouldn't increase were it simpler, with clearer names, etc.
That seems unlikely. The whole ethos of many successful companies -- Stripe, Mailchimp come to mind -- is to differentiate themselves by simplifying. It matters to the vast majority of users, developers or otherwise.
Well, two points.
1. From a completely selfish standpoint, if people aren’t willing to learn about AWS, it helps me out a lot. I’m able to make more money by taking the time to learn it.
2. There are three credible cloud providers -AWS, Azure, and GCP - and Oracle. Amazon is twice as large as Azure and 5 times larger than GCP. It doesn’t seem to be hurting them.
Just like the obtuse clusterf%%% that is modern front end development doesn’t seem to be hurting the adoption by the $cool_kids.
This is true, and it may even help with adoption among "cool kids." But the adoption could be much, much higher if it weren't such a clusterf%%%. There is an almost infinite amount of marketshare from a wide spectrum of technologies ranging from Wordpress down to "vanilla jquery" that could be eaten into.
Again, you can't look at some successful thing S lacking quality X and conclude "quality X doesn't matter." You have to compare "S with X" to "S without X". Sometimes a direct experiment is possible, sometimes not.