1. IAM -> Users, Keys and Certs. But other commenters have already pointed out this leaves out the whole roles, permissioning and policies that is really the core of IAM.
2. S3 -> Amazon Unlimited FTP Server would imply to me that S3 actually just follows the FTP protocol, which is totally false.
3. Lambda -> AWS App Scripts. I have news for the author, but I know some companies and architectures that use Lambda as a basis for an entire serverless infrastructure, a heck of a lot more than "little scripts", e.g. serving whole websites.
4. Cognito -> Amazon OAuth as a Service - except many companies use it to store plain user accounts (e.g. username and password), not just setting up OAuth for accounts managed elsewhere.
5. SNS -> Amazon Messenger. But SNS can be used for a lot more than just sending emails, texts or push notifications. For example, it can be used to trigger lambdas. "Notification Service" seems to much better encompass the generic nature of the notification handling that SNS provides.
Some of the names are completely uninformative though -- cognito for example doesn't convey anything about oauth. Neptune doesn't make me think graph database. Kinesis doesn't make me think distributed log. Redshift doesn't make me think analytics database.
I think my personal issue with aws naming is that they've run out of three letter acronyms. So I have to remember is EKS the kubernetes service, or the hosted kafka service?
Does Microsoft make you think computer OS? Does Apple make you think of computers and personal devices? Do common names Alexa/Siri mean anything specific to you?
None of the words used in those examples have anything to do with what they do, but they are now synonymous with everything you think of when those words are spoken/written. That's because the companies have spent time developing them as brands. AMZN through AWS has just come up with names so that they can be discussed more easily. They haven't really spent time with ad agencies running lifestyle campaigns for them.
I also think it falls into "I don't use something enough to fully remember what it does". However, is anyone reading this really not aware of what S3 does? EC2? Those are the basics where pretty much anyone starts with. Sure, not everyone will need EKS and it becomes more esoteric, but people that do it day-to-day know exactly what EKS is.
That's kind of the point, though. A "brandable" name is something that generally evokes what the service does, but is not so limited that it only specifies the exact features at the time of initial release.
I mean, by the author's logic, Amazon itself should have been called Internet Book Store. Which name do you think would have been more successful?
S3 is an object store. Give it a key and up to 5TB of data and it will store it.
(Yeah, you can translate one to the other, see AWS Transfer. But they are different.)
In fact, it's much closer to a WebDAV server!
That's funny. Because we have hundreds of developers using AWS every day, using IAM all the time, and never using a single IAM User.
IAM is actually named extremely well. identity and Access Management. I can't think of a better name. And if your problem is that you just don't like acronyms, you probably picked the wrong industry.
Once upon a time, I worked for a company that bought a lot of IBM's 8656-1RY, which was later renamed to "x-series $whatever", according to some obscure scheme made up by marketing. Fortunately, the Japanese site was not yet updated, so I could get firmware updates through them. Some weeks later, an IBM representative showed up, he did not even try to sell us anything after complimenting us on finishing some setup work for 10% of the effort he would have billed us. "Any questions?" "Yes, what's with the naming scheme?" He smiled, pulled out a mouse-pad "the evolution of the x-series". "Yes, marketing-BS, but that's the only documentation on the renaming we've got".
Summa summarum: Criticizing some intrinsics does not automatically put you in "the wrong industry", maybe you just have seen enough to call BS BS when you see it.
The users & keys part is actually just a tiny part of it.
Maybe they should try the military? I hear they only use acronyms occasionally!
The acronym is totally useless, tells you nothing beyond it being for Queues and completely obfuscates what’s happening for anyone not in the eco system.
By the standard of tech names SQS seems, relatively speaking, extremely descriptive.
I don't think it's possible to build a queue-as-a-service that is any simpler than SQS, so there is literally no better name than SQS. (also, the suggested name "Amazon Queue" is pretty similar to the name "Amazon MQ" which does in fact exist)
It's a queue. It supports enqueue and dequeue. And that's pretty much it. It's a Simple Queue Service.
If you want to 'queue' things, there are many options, including a number of options hosted by AWS as-a-service. For quite a long time a 'queue' hasn't really been a 'queue'.
There is SQS, the simplest of them all. There is MSK, which is Apache Kafka, but managed, so you don't have to deal with it yourself. There is Kinesis Streams and Kinesis Firehose, which is like a many-to-one queue, there is a hosted ActiveMQ, which is more complicated than just a 'simple' queue, and then we have Redis which gets used as a queue by plenty of libraries, and there is a set of services that you can use to 'construct' queues, like EMR, Glue, Airflow, Data Pipeline etc. You can also construct a queue out of generic hosted services by combining S3, EventBridge, Step Functions and Lambdas.
So no, it is not totally useless as a name or as an acronym, and to add insult to injury: if you are not in the ecosystem you are probably not even close to the target audience. Just because you don't know something doesn't mean it therefore must be bad. You probably don't know what T&E is in the physical world, that doesn't mean it's a useless acronym or shorthand, it just means it's not for you. (It's Twin & Earth, used in a lot of domestic electrical installations)
Most of AWS isn't for random people off of the street to immediately jump in to. Neither is flying jumbojets, surgery, or recombinant DNA engineering.
Actually, there is, it's called AWS Kinesis.
Yes there is: https://aws.amazon.com/amazon-mq/
What in the world? Why would I want a rack in the world of a cloud.
I want a virtualized private cloud, which not so oddly is named Virtual Private Cloud.
I feel like the person who wrote this got into web dev back when I started in the 90s, then never left the time frame. This dude, much like this webpage, clearly have not kept up with the times
I'm on my fourth or fifth time and it's starting to get wearying. I'm glad I'm not building simple PHP apps on MySQL anymore, but a new AWS whatchamacallit gets little more than a groan from me.
So a VPC (Virtualized Private Cloud) is "a cloud" (e.g. the whole of AWS), all to yourself, on top of a real shared multitenant Cloud, through the magic of virtualization.
In both cases, the traffic going over the LAN or Cloud is isolated from other tenants by the virtualization mechanism, so you don't need to encrypt said traffic the way you would in an untrusted "just leasing several random VMs in separate racks in a colo and having them communicate over the colo's shared LAN" environment (which is what AWS's pre-VPC "Classic" EC2 environment was.)
“Virtualized racks” doesn’t make a whole lot of sense since the metaphor is lost. You don’t think of power, top of rack space how many U’s some resource will take.
If you hate the word “cloud” then IaaS might make for a better name.
Also, since every single AWS service requires a rack, I assume you also want to put Rack in every single name?
Google's acronyms also just all blend together for me. GCP has GKE which uses GCE instances. The entropy is not high enough for me to parse that unless I pronounce every word that the letter is standing in for. Meanwhile, "AWS has EKS which uses EC2 instances". More entropy, more comprehensible.
I don't think any of this really matters much, but I also don't think that being generic and simple is necessarily the end game.
for AWS and GCP side by side in plain english
rip of other article (https://expeditedsecurity.com/aws-in-plain-english/) and ancient
Plenty of discussion over the years:
Original 2015 https://news.ycombinator.com/item?id=10202286
2017 where the author repeats that this is old https://news.ycombinator.com/item?id=13442022
IAM is similarly not that bad - Identity Access Management pretty much tells me what it is.
When we have a field where things are named in extremely unclear ways - kubernetes, docker, kafka, prometheus, etc etc etc - these really don't seem that bad by comparison.
Boring descriptive names are better, but don't look as good when marketing the product (I'd assume).
If I want something to provision infra I could go for Chef, Puppey, Ansible, Terraform. Or is it better for me to write my Infrastructure as Code setup using Whitespace Significant Serialization Format?
with "Virtual Servers", I would have only had to look it up once. With "Elastic Computer" it took me months of rereading what that service was for it to sink in.
With generic terms using generic words making up significant phrases, my mind struggles mightily, whether that's virtual private servers or integrated change control or steering rack control arm... This incidentally is why I struggle to learn any e.g. Car mechanics in English because it's all regular words strung up together Instead of bespoke unique keywords
Imagine you're being taken on a "backstage tour" of the Internet. They open the door, turn on the lights, and as the distinct odor of decay and the chaotic scene of confusion and disarray greet you, you hear the guide blurt out, "Ah, crap! Who made this mess?! I swear it was presentable just a little bit ago! Well, good luck getting ME to clean this up! OK folks, we're outta here!"
And THAT is AWS in "plain English".
The other half is best learned by porting services from competitors to AWS and back again.
Can you please add Azure and GCP service names too?
