Similar to https://expeditedsecurity.com/aws-in-plain-english/
Why does AWS use such convoluted language? Is it because they're dominant and it adds friction to moving to another provider?
Why does AWS use such convoluted language? Is it because they're dominant and it adds friction to moving to another provider?
Imagine the confusion if S3 were called "Amazon Unlimited FTP Server." That gets every word wrong, except that "Amazon" is merely redundant. It's not unlimited (having to pay for a thing is a limit), it's not using FTP, and it's a service, not a server.
Or if VPC was "Amazon Virtual Colocated Rack". A "colocated rack" means your computer in their datacenter. They actually have this service, it's called Direct Connect, because you can actually
Lambda does require you've got some vague notion of what lambda notation is. But "AWS App Scripts" suggests it's for mobile "apps", but it is not specific to those. And it suggests it's only for scripts, but you can run an entire application on Lambda just fine.
Or even DynamoDB. They recommend "Amazon NoSQL." They're not offering many NoSQL databases, just their proprietary one: DynamoDB. They have a service that offers many relational databases and that is called Relational Database Service.
My point is that definitely are named for these concepts but AWS uses brand names which is quite confusing for people who are new to AWS.
Using these brand names might make it easier to evolve them later, or they really wanted nice sounding names because eventually you'd have to write out long phrases with the AWS prefix, and that's probably harder to market.
Which serverless? ECS Fargate? Lambda? Step Functions?
There are tons of AWS services which are technically "serverless". Even S3 obfuscates away the server.
Some of the "WTF, how did they come up with that name" with AWS comes entirely down to the public name being the internal project name, e.g. Snowball. Various engineers and managers have facepalmed hard when marketing decided to go with the easiest option and use that name rather than come up with something meaningful.
Oracle's EC2 is called "compute instances", S3 "object storage", SES "email delivery", Lambda "functions" etc.
And object storage could have been Casper, load balancer Flamingo, or data transfer Rhino.
But, the saying initially was about IBM. The CTOs in the 60s and 70s who chose IBM instead of one of their competitors in hindsight made a good decision. You can still buy hardware from IBM today that can run COBOL programs written thirty to forty years ago. All of IBMs competitors are long dead.
From a recruitment standpoint, you can easily find someone who knows or wants to learn AWS or Azure - Oracle Cloud - not so much.
Like when you think about if a startup had to sell people on a single one of these services, they would have to actually say "like an unlimited FTP server BUT" and thats the only way they could get into board rooms and they would spend years on just that wrong and skeuomorphic branding just to get off the ground
Whereas Amazon doesn't have to do that, and doesn't have to explain the skeumorphic stuff to anyone, they'll just mention it in some conferences about what you can do now, the end.
Yeah, thats really cool. It doesn't mean there isn't a better way, but I can see how it isn't as arbitrary as I thought.
Kubernetes Engine, Compute, Storage, Memory Store, Cloud SQL, PubSub.... almost all of the main services do what they say on the tin.
The only downside is - ironically - it sometimes makes googling for help a bit tricker. Eg. Are you search for generic cloud storage or the Google product with the same name?
How long has the idea of “ubiquitous language” when talking about a business domain been around?
Everyone technical at my company from the CTO down can have conversations and talk about CloudFront, API Gateway, Lambda, S3,SQS,SNS,DynamoDB, Aurora, Fargate, CodeBuild, CodePipeline, CloudFormation, IAM, WAF, EC2, ECS,ECR, Cognito, etc.
I’ve seen developers come in and within 3 months it’s second nature.
because Amazon can ignore trademarks? That would have been an entertaining lawsuit between Amazon and Microsoft though.
Because it's run by engineers (not a bad thing).
Consumers expect most companies to act like a coherent unit, (purportedly due to Dunbar's Number), and when you don't have enough oversight or leadership everything begins to look schizophrenic.
"Self-organizing" is organized chaos. If nobody picks winners at the end it never stops being organized chaos.
This is the exact reason I prefer Azure. I can use the search textbox to find something and the name is usually pretty explanatory (but they do have some daft stuff, like 3 different queue offerings with pretty vague documentation on the differences).
Providing complex answers to simple questions, almost always is due to a need to hide sth.
Having gone from AWS in my last role to GCP in my current, I can tell you with 100% certainty that for me, AWS' mnemonic device naming convention is far, FAR more effective in helping me remember which service does what.
S3? Storage. EC2? VM/compute. GCP's equivalent? GCS/GCE. I don't do a whole lot with VMs in my role but it takes me a few good seconds to remember "GCE" whereas EC2 is instantly memorable. Don't get me started on Google's many "Data X" services (Datastore, Dataproc, Data Transfer, Data Catalog, Data Fusion, Dataprep, Data Labeling).
tl,dr; the lizard part of my brain very much prefers AWS' naming style, and I have a hard time remembering GCP's services despite the descriptive naming.
I suppose because of this, Google tend to use the full name in most of their documentation. It does make learning how to use Google Cloud as a beginner a lot easier though.