I'll take names over alphabet soup. My EBS EC2 machines are not playing nicely with ELB (but my EFS ones are), I think it might be to do with EMR, or maybe EKS.
You could always say: "My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."
No soup.
You nailed it, I hate the tendency of english speakers, specially in tech, to use nonsense acronyms when it would be much easier and understandable to use the word itself, or at least part of it.
"My elastic block service elastic cloud compute machines are not playing nicely with elastic load balancers (but my elastic file system ones are), I think it might be to do with elastic map reduce, or maybe elastic kubernetes service."
"My elastic services are not working. Cloud compute machines..."
The problem is partly that AWS—sorry, Amazon Web Services—refer to their products like this in all their documentation and marketing. Using acronyms is great for brevity in communicating within closed environments (we use our own acronyms within our own office to refer to many things, including clients), but if you're product names so long-winded in the first place that you're acyronymizing them all publicly in your own materials you have a problem.
No way engineers will ever do this. We're far to use to TLAs and also, it's way too long. Having a simple, metaphorical brand name allows you to then build on top of that. Can you imagine if Java had instead been called WriteOnceRunAnywhereC++Alternate instead of java? Then, we'd have the writeoncerunanywhereC++alternate Virtual Machine
