4 ms·

Nice list. Disagree with many of them, though. EC2/"Amazon Virtual Servers" - true today, perhaps. But when EC2 first launched, they were trying hard to sell

by Goladus 11y ago

Nice list. Disagree with many of them, though. EC2/"Amazon Virtual Servers" - true today, perhaps. But when EC2 first launched, they were trying hard to sell the "elasticity" and "pay for what you use" aspects, which were unique at the time. There were no EBS volumes, the storage was all ephemeral. While it was possible to use EC2 instances as virtual servers, that was really not what they were designed for. IAM/Users Keys and Certs - I agree that IAM is a bad name, but it's still useful to distinguish between aws API authentication and other kinds of authentication. Say "IAM" in a conversation and people will immediately know what you're talking about. Say "Users, Keys and Certs" and you'll have to keep distinguishing between certs for your websites, OS host keys, and that kind of thing. S3/"Amazon Unlimited FTP Server" - Sorry but this one would just be very misleading. S3 is not an FTP service it is a distributed object store. VPC/Virtual Colocated Rack" - Again I think using words like colocation and rack would just be misleading. VPC gives you software-defined networking. I think the real issue here is that amazon missed the mark just a little in the original design. VPC should have been the default mode of operation, where the initial VPC was transparent and got a default name. Not a big mistake in the long run but it did mean they had to deploy and name a new service. RDS/Amazon SQL - I think "Relational Database Service" should be easily understood by any developer using a relational database. If you don't know that MySQL, Postgres, and Oracle are relational databases, consider this the right time to learn. SQS/Amazon Queue: "Simple Queue Service" is basically the same as "Amazon Queue" except that it uses the same naming convention as S3 so that it's easily recognized as an AWS service rather than some generic amazon store feature. Elastic Map Reduce/Hadooper: I think "Map Reduce" is much plainer English than "Hadooper." CodeCommit/Amazon Github: This would be a blatant trademark violation. Also implies that it's less "plain English" given that Github is a proper noun and not a straightforward description of a service. I don't love "CodeCommit" but can't immediately think of anything better.

mapgrep 11y ago
> S3 is not an FTP service it is a distributed object store. Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized. And it's hard to see how it's "distributed" when your bucket price varies "based on the location of your bucket" as Amazon puts it. It's probably more redundant than FTP, but saying S3 is like FTP is a reasonable shorthand and cuts through a lot of the marketing BS.
- Goladus 11y ago
  The only real resemblance at all to FTP is that you use GET and PUT instead of filesystem commands. I mean, I guess if you really don't understand what FTP is and have no desire to understand how S3 is different from posix, then saying you have to use S3 like you use FTP kind of works. But it would be misleading to everyone else. > It's probably more redundant than FTP FTP is a transfer protocol, it says nothing about redundancy of the data on the back end. You could put an FTP server in front of an ext4 filesystem, and NTFS filesystem, an NFS mount, or maybe even S3.
  - WhitneyLand 11y ago
    Using FTP as shorthand is better than "Object Store", which sounds like the marketing BS this is designed to avoid.
    - Pxtl 11y ago
      FTP implies a specific protocol. "File Server" or something like that would be better. You're quite right that "Object" is worthless terminology in this case - "Object" is basically nerdspeak for "thing".
      - Goladus 11y ago
        It's not worthless terminology. It's a term that was chosen along time ago to distinguish this kind of storage architecture from filesystems and block devices: https://en.wikipedia.org/wiki/Object_storage https://en.wikipedia.org/wiki/Object_storage. This is a common issue in computer science and software development. Whenever new concepts are discovered or developed, they often need new names. You need to pick something that will distinguish this new concept from existing technologies. For laughs (kind of), look at configuration management software (Chef, Puppet, Cfengine, Ansible). They all quickly discovered that there were a whole bunch of new concepts that needed names, and while in some cases this hints that maybe these tools a bit over-engineered, it's hard to deny they've been popular and useful. Regardless, they all encountered these new concepts around the same time and they all made up their own names for them. So in chef you have cookbooks, where ansible has roles. Chef has roles where ansible has playbooks. Ansible has modules where puppet has providers and resource types. Ansible has tasks which are basically components of what chef would call a recipe and puppet would call a manifest. All in all, I think "object storage" is a pretty fair term for the concept of a data store that neither heirarchical or sequential.

by Goladus 11y ago

mapgrep 11y ago

> S3 is not an FTP service it is a distributed object store. Not really, the only "object" you can store, Amazon's language notwithstanding, is effectively a file. It's not like you could give it something that needed to be serialized. And it's hard to see how it's "distributed" when your bucket price varies "based on the location of your bucket" as Amazon puts it. It's probably more redundant than FTP, but saying S3 is like FTP is a reasonable shorthand and cuts through a lot of the marketing BS.

Goladus 11y ago
The only real resemblance at all to FTP is that you use GET and PUT instead of filesystem commands. I mean, I guess if you really don't understand what FTP is and have no desire to understand how S3 is different from posix, then saying you have to use S3 like you use FTP kind of works. But it would be misleading to everyone else. > It's probably more redundant than FTP FTP is a transfer protocol, it says nothing about redundancy of the data on the back end. You could put an FTP server in front of an ext4 filesystem, and NTFS filesystem, an NFS mount, or maybe even S3.
- WhitneyLand 11y ago
  Using FTP as shorthand is better than "Object Store", which sounds like the marketing BS this is designed to avoid.
  - Pxtl 11y ago
    FTP implies a specific protocol. "File Server" or something like that would be better. You're quite right that "Object" is worthless terminology in this case - "Object" is basically nerdspeak for "thing".
    - Goladus 11y ago
      It's not worthless terminology. It's a term that was chosen along time ago to distinguish this kind of storage architecture from filesystems and block devices: https://en.wikipedia.org/wiki/Object_storage https://en.wikipedia.org/wiki/Object_storage. This is a common issue in computer science and software development. Whenever new concepts are discovered or developed, they often need new names. You need to pick something that will distinguish this new concept from existing technologies. For laughs (kind of), look at configuration management software (Chef, Puppet, Cfengine, Ansible). They all quickly discovered that there were a whole bunch of new concepts that needed names, and while in some cases this hints that maybe these tools a bit over-engineered, it's hard to deny they've been popular and useful. Regardless, they all encountered these new concepts around the same time and they all made up their own names for them. So in chef you have cookbooks, where ansible has roles. Chef has roles where ansible has playbooks. Ansible has modules where puppet has providers and resource types. Ansible has tasks which are basically components of what chef would call a recipe and puppet would call a manifest. All in all, I think "object storage" is a pretty fair term for the concept of a data store that neither heirarchical or sequential.