31–40 of 237 posts
Earlier quoted context omitted.
Seems to work for Reddit, Zynga, Dropbox and Netflix.
Netflix had to go through a massive engineering effort to make their system reliable enough to work on AWS. If they knew what it would take in human and capital investment, they may have chosen to build their own datacenter.
http://arstechnica.com/information-technology/2015/08/netfli...
I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actual AWS name:
* Amazon Unlimited FTP Server - why? ftp is a transfer protocol. S3 is about storage. It should be called Amazon Storage Server. Which it basically is (Simple Storage Service - S3)
* Amazon Memcached - I don't used the service so I don't know if it's only binary compatible with memcached but if its a generic cache that has multiple interfaces (the page references redis too) then more generic term like cache (and elastic implies it can grow/expand) seems more logical.
* Amazon Beginning Cut Pro - wtf. Transcoding is literally the process of converting a file from one type of encoding to another. That seems to be what this does. Final Cut Pro is not a mere format converter, it's a non-linear editor.
* Device Farm - I'll only concede that maybe this should reference mobile devices, but the name seems pretty clear and concise.
* CodeCommit - how is "code commit" less clear than "github". By this logic, Apple's email client should be called "Apple Outlook" because Outlook was a well known email client on the market.
* EC2 Container Service - the reference to EC2 means its slightly non-obvious, but Amazon Container Service would be much better than something referencing Docker. Docker !== Containers.
* WorkDocs, WorkMail - seriously, you're just replacing "Work" with "Company" here.
* Storage Gateway - what are you trying to be obtuse? From your very description, this sounds like exactly what the name describes - a local gateway to a storage service.
* Elastic Map Reduce - the compute/processing part of Hadoop is Map/Reduce. How is "Hadooper" more clear than the current one?
* Machine Learning - you're just being facetious now, right?
* OpsWorks - again, why does their name have to reflect a single specific implementation of a fairly well understood term(s) - Operations, DevOps, etc??
edit: typos
[deleted]
Where's the main danger as you see it
Earlier quoted context omitted.
Seems to work for Reddit, Zynga, Dropbox and Netflix.
Netflix had to go through a massive engineering effort to make their system reliable enough to work on AWS. If they knew what it would take in human and capital investment, they may have chosen to build their own datacenter.
http://arstechnica.co.uk/information-technology/2015/08/netf...
Some of these names make you wonder if Amazon are more in love with their own cuteness than in actually getting people to use their stuff - "Elastic Beanstalk" FFS? Either way, Bezos should hire the author of this piece and make him product-naming czar.
So many ways to make your software depend on Amazon.
Seems to work for Reddit, Zynga, Dropbox and Netflix.
AWS makes even less sense at scale than it does for small companies. Once you can afford to hire competent Ops staff (and assuming you don't have developers who insist they know everything needed to run a complex system in a high traffic environment, so Ops will 'get in the way') you can get much better results with co-lo or even rented full-hardware, and largely the same Open Source software AWS is built on, but without the confusing naming and vendor lock-in.
"It's like: Stacking cash on the sidewalk and lighting it on fire" Is an accurate description of a large number of products that I have been forced to use after various CTOs have played golf with a vendors sales team.
Except that lighting cash on fire would be more fun and take less time ;)
Let me preface this by saying I use AWS only when clients insist on it. I think there are much better options that don't lock their customers in anywhere near to the same level. I think AWS has plenty of badly named services, but some of these suggestions are much worse worse (and have a huge American influence - that fascination with using brand/implementation names for a generic/standard item) than the current actu…
The idea, though, is great - provide some overview of Amazon's zillions of services that doesn't read like it's been generated by a markovbot. Perhaps the authors will improve the implementation.