The problem I have with these renamed is that by "simplifying" the name, they often cut out major pieces of functionality. The original names are at least "brandable" so that when I think of that name, I think of the entire suite of functionality. Some examples:
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.
I can certainly agree that some of those descriptions don't fully encompass what you're getting. Some of your points are more picking at the authors choice of simplifying language, rather than the effort to simplify the names themselves.
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?
>Some of the names are completely uninformative though
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.
I get the point, that with sufficient branding to a target audience, the issue is negated, but I think you're conflating branding for a corporation with branding for niche products. The level of effort put into branding the corporation at large versus the level of branding for any individual service is orders of magnitude apart.
Importantly, with AWS, there's dozens of services, all competing for a three letter address space. It's getting saturated, so it's easier and easier to get confused.
> Sure, not everyone will need EKS and it becomes more esoteric, but people that do it day-to-day know exactly what EKS is.
This is sort of my point. I work with kubernetes and kafka. The kafka instance that I connect to is managed, the k8s cluster I deploy to is not. I can't tell you off the top of my head if EKS is managed k8s or managed kafka. That was the breaking point for me to stop putting effort into trying to remember.
I have pretty severe ADHD, so I can accept that I'm probably outside a standard deviation as far as ability to remember three letter acronyms, but I think I still stand as a contradiction to your assertion.
I had intended to add Windows to that, but my brain-to-typing-fingers skipped over it. The word "Windows" tells me nothing about what it does in the "same contenxt" as what's being discussed here. We've just had that crap shoved down our gullets for all this time it has become synonymous with software operating system not because the word is descriptive of purpose.
Disagree on that too, the concept of movable "windows" into programs is quite descriptive also. What else would you call it? Programmable Rectangles? Subscreens?
No, because it is Company not an OS. And today I bet more people associate Microsoft with Xbox, or Office then with Windows. Windows has been Microsoft's least profitable division for awhile now. The OS is their loss leader
> Does Apple make you think of computers and personal devices?
No, Apple makes me think of Cringe Hippies over spending on an poorly engineered fashion statement... ;) Or prime example of a company claiming to be environmentally friendly while actively designing their products to have to be thrown away instead of repaired...
>AMZN through AWS has just come up with names so that they can be discussed more easily.
I dont think that is true at all, even in tech circles trying to remember what the different service names are is pain.
Amazon AWS took a look at Microsoft, the worse company in the world at naming things, and said "Hold my beer"
>>However, is anyone reading this really not aware of what S3 does? EC2?
S3, probably not but it is also the oldest product and has become Standard Standard Cloud based Object Storage, S3 while an AWS service is also a protocol adopted by countless other services, and open source projects.
EC2, Yes I better there are those that do not know what EC2 is, or that to use EC2 you need EBS. And the deeper you go the more complex the web of services become.
> Some of the names are completely uninformative though -- cognito for example doesn't convey anything about oauth.
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?
Yea I agree mostly. They could have explained a bit differently. For example, it says that S3 Should have been called Amazon Unlimited FTP Server. That is definitely over simplifying it. S3 stores objects and a regular FTP server is just a server with files. I would explain S3 as "Kinda like an SFTP server but you get to add encryption, versioning, tagging, metadata to files when they get uploaded"
IAM "Should have been called Users, Keys and Certs"
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.
> 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.
It just shows that someone is writing something from their personal perspective and thinks the rest of the world should conform to their view points. Also, it really sounds like a recent cloud "convert" trying to make hay as a thought leader (which is a phrase that makes me want to hurl), all the while revealing their ignorance as not fully understand the topic at hand. In other words, typical blogosphere crap (even though this isn't really a blog, just a syndrome).
IAM has been in use, without any confusion that I've encountered amongst various clients, for well over 10 years. How is it confusing? It sounds like people are wanting dumbed-down "Romper Room" names. Meaningful acronyms serve as mnemonics as to what the thing is. Noobs should learn and embrace.
Some of these are clearly deliberate obfuscation. I need something to handle Queues, what should I use? Amazon SQS obviously. Oh cool, what’s that? It’s a Queue service! Oh great, why is called SQS? Simple Queue Service duh! Is there a more complex queuing service? No. There’s only SQS.
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.
I mean, what would you call it? It's basically a 'push/pop' interface with timeouts. Like, do you think 'Kafka' is more descriptive? Or Prometheus? Or any of the essentially randomly generated names that various projects and products choose?
By the standard of tech names SQS seems, relatively speaking, extremely descriptive.
Having them start everything with “Amazon” would put them in the “kde” league of everything stupidly starting with k for no reason other than to start with k.
I'm really failing to see how that's any clearer. If you're looking at SQS you probably already know it's an AWS service, and pubsub seems less descriptive than queue...
pubsub would also be misleading, given SQS does not support the pub/sub pattern. It's a queue where each message is processed once by a single consumer; it's not a pub/sub system where multiple consumers can subscribe to messages of interest.
AWS offers a bunch of different queue-like services: SQS, Kinesis, MSK, Amazon MQ (supporting both ActiveMQ and RabbitMQ).
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.
I think SQS was the first AWS offering. In that context “simple” means simple compared to other offerings of the 2000s/rolling it out yourself. I agree it’s a little convoluted for newcomers in 2021 although probably unintentional.
It is neither 'clearly' nor 'deliberate' or 'obfuscation'. It is possible that you personally simply do not understand all the terms or definitions, that is a different story.
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.
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
Maybe you're not the intended audience. It can get exhausting to keep up with the (new) times and learn a new stack again.
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.
A colocated rack is a much more limited concept than a VPC. VPCs let your architect an entire network. You can have multiple private and public subnets, set security groups to filter traffic between them, do service discovery, use policy based access control, health check load balance, and host PaaS entities into the network (like Aurora serverless). On top of that, you can flex your compute. VPC is more like a rack with a firewall, an f5, a smart switch with vlans, something like kubernetes to automatically scale compute… but there are things that aren’t even possible in a rack because you can transparently both manage your own compute with ec2 and add PaaS managed offerings like RDS, elasticsearch, kafka, etc. all to the same network.
The last bit doesn’t make a whole lot of sense because AWS is all hosted in racks. It’s just that people don’t typically set up virtualized networking that way.
We did and it was fantastic. All of our “environments” were overlay networks spanning our hypervisors and we provided “ops” services outside those networks just like AWS where they just got an interface in the environments.
I'm convinced that there is no other way to manage networks after this. The ops team has their own completely separate view of the infrastructure that can be managed, moved, and shifted around so long as you keep the fiction the same.
A VLAN (Virtualized [private] LAN) is a LAN all to yourself, on top of a real shared multitenant LAN, through the magic of virtualization.
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.)
Right. What really makes this work is that Amazon builds their own specialized routers.[1] They have a control plane hidden from their customers, one which lets them set customer-visible MAC and IP addresses more or less arbitrarily.
'All problems in computer science can be solved by another layer of indirection. But that usually will create another problem'. - David Wheeler.
Logical isolation of resources instead of physical and virtualized compute, networking, and storage.
“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.
I actually read the whole piece as a humorous way of giving you an overview of some of the key AW services. I had a pretty good laugh at least, and thought it did a good job of it. :)
Google seems to have adopted the simpler naming scheme ("Cloud Storage", "Cloud SQL", etc.) and it honestly doesn't help much. Imagine you have some application that can write to various providers' object storage implementation. The user has to configure that somehow, and what do you call the configuration keys? In the AWS case, it's easy -- "S3_BUCKET". With Google, you end up having to use an incredibly long name. "STORAGE_BUCKET" -- too general. "CLOUD_STORAGE_BUCKET" -- too general (there are many clouds). "GOOGLE_CLOUD_STORAGE_BUCKET" -- there you go. Type that in all caps without a typo. (It's unclear to me whether or not "GCS" is an acceptable acronym for Cloud Storage. I think I use "GCS_BUCKET", but I'm also pretty sure I just made that up.)
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.
I'd like someone to do one of these for Policies. Every time I need to tweak an IAM or an S3 or a permission, I have to write a policy. I never quite know what I'm doing, but I get it to work. I'd really like a hand-held walkthrough of why policies are written that way, and how to write one without accidentally footbulleting myself.
What's in a name? Really, is "Amazon Virtual Servers" much better than "Elastic Compute" ? Maybe slightly. But at the end of the day you have to go look at it and see wtf that means no matter what, and the 'elastic' verbiage is fairly consistent across AWS products.
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.
I think everything you said just pointed out how bad it really is in the field. You either have an acronym, which people assume you know, or nonsense words.
Boring descriptive names are better, but don't look as good when marketing the product (I'd assume).
They're products, sometimes even brands, so I'm not sure why this requirement for clarity is needed. It at least helps differentiate projects in the same space.
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?
maybe it's an issue with my neurology, but for me if the name isn't descriptive it takes me longer to make association between the name and what it actually is.
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.
That's fascinating and shows how different people are. I'm completely opposite! If you name something "gnorf" or "harjblang" and give me a definition, it occupies a specific unique place in my mind and I can learn memorize use and associate it.
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
I read the title and first expected some satire like this:
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!"
It's a bit early to mention this as its still in the works but we're trying to take the same premise of explaining complex things in "plain english" but specifically for AWS billing terms and concepts here:
The comparison of AWS WAF to Sophos could not be more misleading. It’s an engine for building a limited set of HTTP exploit detections, and has nothing to do with endpoint protection whatsoever.
Heroku is a good comparison. Beanstalk is a way to specify the resources you need without needing to understand aws very well - AWS automagically provisions things for you and replaces instances when they become unhealthy. Compare to CloudFront, which as the declarative way to specify what you need but requires you to know AWS in depth.
