Sad that this is necessary, but glad someone did it. There are AWS services listed here which — when explained this way — I realize I might want to take advantage of.
What's amazing is the amount of services Amazon offers.
Whenever I look at my AWS console I see these reems of badly named services and I think to myself
"after I've dealt with the current problem for which I've logged in AWS,
I might get to figure out what all that other stuff actually is".
However, I never do because there is more stuff to take care of, and since AWS doesn't make this easy to understand, you just don't bother. Now I know that AWS actually has some really useful stuff, and for things I would never have considered using Amazon for, like video processing (Elastic Transcoder), source control (CodeCommit) and OAuth as a service (Cognito).
I'm just 'starting out' with a lot of this, despite a few years building/hosting websites, and these sort of services are the things I'm starting to look at.
I'm completely disinterested in Amazon's offerings chiefly because they're so obtuse. Why should I expend so much cognitive load just figuring out what each service is and what it could do for me?
It's undoubtedly possible to do, AWS has a hell of a lot of users, but I simply am not going to perform the mental gymnastics to work out what they could do for me, let alone work out the price (which seems cleverly designed to keep the final figure a total mystery).
Maybe I'm too early in my progression to really need this stuff yet ( I probably am TBH) and so I'm not motivated enough to really dig into it, but the point stands - why should I need to be?
Because when you figure out how to use them, you can save a tremendous amount of time and energy, and build sophisticated systems with simple code and little effort. When you have the need in a certain area, a lot of them will feel like "Wow, I didn't know that someone could automate this for me with so little effort compared to doing it myself". Most of it becomes increasingly valuable as you operate larger systems with many moving parts.
These AWS services are each solving a separate problem that people encounter, and usually embody a sort of "design pattern" like a distributed queue, or a load balancer, or a cache. Microsoft Azure and to a lesser extent Google Cloud Platform have similar lists of services (many services, each doing a different thing): https://azure.microsoft.com/en-us/services/
It's really just like figuring out any other software ecosystem, though. If you stacked up a list of open source libraries or commercial libraries in a certain area, I'm sure it will feel the same. For example, so you want to get one application to speak to another over RPC. Well, you could use Apache Thrift, or Google Protocol Buffers, or Cap'n Proto, or Swagger.io, or SOAP or ASN.1 or I'm sure countless other things, and that's simply to perform the same task. What if you wanted a message queue? RabbitMQ, ZMQ, IBM MQ, ... I don't know if anyone has tried to put all of these on the same page and product matrix, or even keep track of them.
There's just a lot of stuff out there to learn and take advantage of. Being an effective software engineer in business is just as much about reusing existing stuff as it is about building new stuff from first principles. I'd say it's actually more about reusing stuff, since all other things equal it saves a lot of time. Don't build yourself or manage yourself what you can use for free or buy unless it's your core competency.
Anecdote: after deploying and maintaining applications in Opsworks for a while I feel it's comparatively incredibly hard to do that anywhere else.
The services they offer are great. Remember that you don't have to learn them all at once though. I've worked with amazon services for a couple of years and I still don't know/haven't used most of them. Just use what you need, really.
I find this is the key to understanding a service, library or technology. It is very difficult for me to wrap me head around something if I haven't yet encountered the problem it solves.
For example, I'm sure Docker is awesome, but I don't really understand it yet because I haven't yet felt the pain Docker takes away. So I enjoy following new technologies, but when I don't really see the point I just assume I haven't experienced the pain the new technology takes away.
You shouldn't. I've spent months trying to figure out a few services to launch some apps and it's been a complete and utter waste of time. Yes, there are a lot of services, but the platform is incredibly buggy, the docs beyond unusable and unsearchable, and the customer support extremely slow. Not only that, but you'll get stuck in a proprietary system that's going to charge you many times what more traditional hosting options would. Here's a different experience that's probably very similar to what you'll go through: http://lucianux.com/blog/2015/08/26/aws:-i'd-rather-cut-my-o...
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.
Except when they suffer huge outages because of some upstream issue and HN/twitter/etc go stupid with "omg half the internet is offline" because everyone thinks AWS is indestructible.
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.
Plenty of medium sized companies would work out better off overall, with a skilled Ops person to setup cost effective services
> Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.
You don't have to compete. They are trying to make a profit. You just need to be better off, long term. That could be a mixture of lower service fees, more flexibility, improved productivity, less vendor lock in, etc.
Relying on any single company's services, particularly for key/essential systems your business relies on, doesn't sound like a smart strategy.
I don't see how a single "skilled ops person" can deliver "lower service fees, more flexibility, improved productivity".
On the other hand, Cloud Computing will, by definition, let you turn on and off services based on business demands. It doesn't get much more flexible and cost effective than that.
"You just need to be better off, long term." - This is a good one. Do you really think your homegrown Docker environment, Hadoop cluster and/or state-of-the-art Cassandra ring maintained by your one and only skilled Unicorn is a better long term plan than 100% managed alternatives?
Let's see how well (and how secure) your in-house stuff work 2-3 years down the road and how it will then compare with the always "up-to-date" alternative.
The "vendor lock-in" part is your only valid argument, in my opinion. Costs/benefits will have be weighted properly. How much do you value business agility and pace of innovation vs. increased vendor dependency?
The proper answer will be different for all businesses, but I would argue that as long as a specific IT component/technology is not part of your core business, you might be better off buying it off-the-shelves instead of building it and maintaining it yourself.
If you make so much money that it really matters if your software depends on Amazon, that is a rather pleasant problem to have. Build it, and they will come.
It is not an accurate description, however, of the economics or value proposition of Direct Connect. When we're moving TB to an off-cloud location it's almost a no-brainer. Similar when latency sensitive.
The highest barrier, quelle surprise, is dealing with interconnect telcos.
Yeah, and at certain data centers it is as simple as ordering a cross connect. There are many AWS services and each have many use cases where the customer is getting an excellent value. Unfortunately, just like deciphering all of the names is very difficult as OP demonstrated so well, understanding the use cases where you can get a good value as a customer is also esoteric and poorly documented. While AWS has pretty good docs in general for each service. Most of the naive implementations presented in tutorials and docs would not be a valuable reason for a customer to use the service. I wonder if documenting this type of stuff better would help them grow the business or if they just don't care and they want to just rip off as many faces as possible. I guess in traditional enterprise software, this is always the role of the consultants / partners rather than the role of the vendor. The vendor sales guy always just wants you to take the license that puts the most money in his pocket and it is up to those partners and consultants to explain to you how to optimize your usage and licensing.
I've found that nearly any use-case of AWS is like "stacking cash on the sidewalk and lighting it on fire". It's very overpriced and there's a lot of smoke and mirrors involved in figuring out how much you're paying.
Disclaimer: I work at Linode, but have felt this way since before I started.
> Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car.
To make the analogy accurate:
Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car, hire a driver, find a good mechanic, lease a parking spot, purchase automobile insurance, remember to buy gas, deal with speeding tickets, schedule regular maintenance ....
At some point it makes sense, but it is way, way down the road for most startups.
Empirically I've found that point to be at approximately the $30k/month spend rate (somewhere around 4-5 years in--arguably no longer strictly a "startup"). Of course it's pretty context-dependent, YMMV, etc.
Yeah, I agree that initially, startups should focus on building value over lowering infrastructure costs.
But I'm continually embarrassed when companies who raised $100Mns in Series B funding continue to rely on AWS when they could have build out much sooner, and reduced their burn rate measurably.
Why didn't I read this earlier?! I was at an AWS hackathon all day and it was my first time ever using any of their offerings . This would have been super useful.
I think this comes from considering all those services as separate products. After all, today every product needs a distinguishable name, a logo, etc. /s
It's like they started to create different products with their own identity and stopped here. Each product has the same doc, same yellow/white/black design, same marketing, but with a special name. So we have nothing to anchor our mind but that. They should continue to do what they were doing and do a whole sub-website for each one of their product with their own marketing identity. It will make more sense for newcomers to wrap their mind and will ease how they should think about them. They should do the same websites than Vault, Consul, Docker with Route 53, S3, Glacier...
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.
I have to say that I think "glacier" is an inspired name. It takes a negative -- slow data retrieval -- and turns it into a positive -- indestructible, huge, unstoppable.
Ha, I also browsed through the list, curious to find the name for AWS Lambda. Perhaps it's omitted because it is tougher to find a good name? Amazon NoServer Computing? Amazon NoEC2?
I think it is a pretty strong reference that many programmers understand, and speaks volumes about the execution-model-as-value-proposition: "Just give us a piece of code, we'll do the rest". I'd say it's up there with Glacier and CloudFormation as an evocative product name.
There is a category violation in the name since, arguably, AWS Lambda functions are not true anonymous functions, having ARNs to identify them. If only I could save environment state along with the code function (e.g. for injection of runtime secrets); it'd be AWS Closure.
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 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??
Yep, a lot of it is "plain English" for the values of "plain English" that include "entirely inaccurate" and "explained in terms of other, just as obtusely named services you may or may not be familiar with".
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.
That's like me asking you "what car do you suggest?" without telling you what I want to use it for, how big my family is, or where I live.
I have no idea what your business does or what services you need, but there are plenty of other vendors from simple rented virtual machines up to full co-lo of customer owned hardware. The good ones will rely on good customer satisfaction rather than artificial vendor lock-in to remain profitable and competitive.
> * 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.
Considering all AWS ElastiCache is is "hosted Redis", that one confused me the most. Out of all the AWS services, this is the least 'magic' and custom and easiest to come up with a name.
From memory, when you create an ElastiCache cluster, you have to choose whether it's memcache or redis. It's really just a very thin wrapper around them running EC2 instances in your VPC which are running either memcache or redis.
So, if I understand this right, you're getting really really worked up at a slightly tongue-in-cheek post that tries to explain AWS in a way that's relateable to a lot of programmers. And you're upset because the words used in this post, which is about explaining Amazon's services to people who are familiar with similar services, wouldn't be a wise choice for Amazon to actually use, since it's too familiar with their competition?
That seems silly, and kind of missing the entire point of this submission. I haven't used any of Amazon's services, so having something to translate back to things I can understand was really helpful, and I feel like I have a much better idea of what Amazon offers.
Exactly what i was thinking about as i submited this. Don't read this article as a "They should rename the Services to..." and more like "This name would explain the Service in a simpler form". Thanks for reading my mind btw :)
The post claims to have "better hames" for the AWS services. Many of those names are much worse.
Take the suggested "Amazon Beginning Cut Pro" which was their suggestion for "Elastic Transcoder".
"Beginning Cut Pro" is clearly a reference to Apple's NLE, Final Cut Pro. I would suggest that there are literally zero people on the planet, who would use Amazon's video transcoding service (I imagine it's essentially a distributed ffmpeg queue.) to process video files before importing them into FCP.
This isn't "tongue in cheek", this is "stupid and confusing as an attempt at a laugh". I mean, what if I suggested that a hosted Memcached service be called AppStart because it uses memory and Apps use memory.
> having something to translate back to things I can understand was really helpful
My issue is that several of the services covered, already have a MORE MEANINGFUL name. So if I had no idea what "Elastic Transcoder" did, but it was instead called "Amazon Beginning Cut Pro", I would then assume it's somehow a tool meant to work with FCP, and disregard it (I don't need a NLE, at most maybe I need something akin to ffmpeg, so I can transcode/scale video files between formats automatically and efficiently.
If it's comedy, call it comedy, and make it actually funny.
If it's meant to be a useful guide, make it fucking accurate, or it's worse than what AWS is doing already.
I wouldn't want to be around you when you're actually worked up.
I found it both funny and useful. But I can see where you're coming from. If I wanted something fucking accurate that goes into greater fucking detail than 1-2 mostly tongue-in-cheek sentences I'd go to the fucking source.
The fucking source is confusing, remember? This is frankly just as confusing for different reasons. It isn't funny enough to be considered comedy so I honestly don't understand the point.
FTP is a protocol, but people use FTP in a variety of wrong but commonly understood meanings:
FTP Server = Hard drive accessible via FTP, not the server on that machine running the protocol
FTP Program = a file-management interface that uses FTP protocol to send commands
HTTP is also a protocol, though 'web browsers' can browse other protocols, as well as offline files.
Saying that an FTP Client that contains support for S3 is a misnomer is like arguing that accessing a file from your desktop using a 'web browser' isnt correct since you arent browsing any web.
The list is aimed at demystifying the confusing terms for the layman, its not aimed at providing the most technically correct taxonomy (since that would also not communicate much to the layman)
When I use my FTP client for SFTP am I using FTP or SSH?
It took me forever to understand what each services aim to do. Like I could have literally been a better programmer by spending all the time learning algorithms instead of figuring out what each of the aws services do. I wish I've had access to this post before.
I like the services they offer, I just really hate the names they gave it. Funny enough, Jeff Bezos said in an interview that names of a product is important #irony
You've got a nasty shock coming then, you'll spend far more time scouring badly written documentation about something that is supposedly simple but just doesn't work and once you've got working you'll never, ever use again until you've forgotten everything and then you need to set it up again and you'll have to go through the whole soul destroying process again but the documentation you find is now out of date, why-god-why, than you ever will implementing algorithms.
In fact, if you spend more than a couple of weeks implementing algorithms in your entire career you're probably doing it wrong or part of the 0.1% of programmers working on low level libraries.
Now re-read your first paragraph in light of the second one.
Sometimes, it really is easier to just implement something your self than go through the "soul destroying process" of figuring out how to correctly set up and configure a library, framework, or piece of open source infrastructure.
Not an algorithm, but it can be a lot easier to write your own SQL, for example, than setting up and configuring Spring and Hibernate. (Talk about soul destroying. Yes, I am a Java developer, why do you ask?)
> Sometimes, it really is easier to just implement something your self than go through the "soul destroying process" of figuring out how to correctly set up and configure a library, framework, or piece of open source infrastructure
But then the next person to look at your code has completely 0 support, rather than the very little support they'd have from the crappy documentation and stack overflow if you used an open source library.
Yes, if you do what jimbokun suggests you're definitely doing it wrong.
Edge cases will consume months of development instead of spending a day or two wrestling with poorly written error messages or badly documented APIs.
The one I always hit in .Net development is logging, log4net and elmah are both abysmally poor at documentation, but incredibly easy once they're actually set up.
Great post some of this stuff has been is a mystery to me. Probably one of the reason I use Digital Ocean. For my personal needs, a simple VM will do and they even let me attach my Keys before instance creation.
* S3 is not FTP. It's more like static web hosting and storage.
* VPC is not a "colocated rack" as it doesn't offer physical placement of hardware. Amazon VLAN would be a better name. It's just private network address space.
Not to me. The absurd lack of plausibility and simply erroneous analogy makes the whole rhetorical technique distracting and misleading rather than funny and insightful.
S3 (or any object store) "is like FTP" has been the best explanation I've used. Way too many people I've talked to think that it's a POSIX-compliant filesystem and "like FTP" is familiar enough to them to know that treating it like a standard filesystem is a terrible idea.
Yeah but just because a flawed analogy happens to work for people who are completely clueless about S3, doesn't mean you should deliberately misname your service to accommodate this lowest common denominator.
I did not read the article as literally suggesting that Amazon change the name of its service, but rather, as a means of conveying the crux of the idea behind the services.
I also did not take this particular description to indicate a literal FTP service.
Analogies do not have to be perfect to be helpful. I've never used Amazon web services, perhaps partly because I found their terminology too obfuscated to bother trying to figure out what it did. Similar services provided by other companies were more recognizable to me for what they were.
236 comments
[ 3.8 ms ] story [ 270 ms ] threadWhenever I look at my AWS console I see these reems of badly named services and I think to myself
However, I never do because there is more stuff to take care of, and since AWS doesn't make this easy to understand, you just don't bother. Now I know that AWS actually has some really useful stuff, and for things I would never have considered using Amazon for, like video processing (Elastic Transcoder), source control (CodeCommit) and OAuth as a service (Cognito).They just seem to be bad at marketing their stuff. Here's an example: https://www.google.de/search?q=source+code+repository+online...
Why isn't CodeCommit here on the first page of the search results?
I'm just 'starting out' with a lot of this, despite a few years building/hosting websites, and these sort of services are the things I'm starting to look at.
I'm completely disinterested in Amazon's offerings chiefly because they're so obtuse. Why should I expend so much cognitive load just figuring out what each service is and what it could do for me?
It's undoubtedly possible to do, AWS has a hell of a lot of users, but I simply am not going to perform the mental gymnastics to work out what they could do for me, let alone work out the price (which seems cleverly designed to keep the final figure a total mystery).
Maybe I'm too early in my progression to really need this stuff yet ( I probably am TBH) and so I'm not motivated enough to really dig into it, but the point stands - why should I need to be?
These AWS services are each solving a separate problem that people encounter, and usually embody a sort of "design pattern" like a distributed queue, or a load balancer, or a cache. Microsoft Azure and to a lesser extent Google Cloud Platform have similar lists of services (many services, each doing a different thing): https://azure.microsoft.com/en-us/services/
It's really just like figuring out any other software ecosystem, though. If you stacked up a list of open source libraries or commercial libraries in a certain area, I'm sure it will feel the same. For example, so you want to get one application to speak to another over RPC. Well, you could use Apache Thrift, or Google Protocol Buffers, or Cap'n Proto, or Swagger.io, or SOAP or ASN.1 or I'm sure countless other things, and that's simply to perform the same task. What if you wanted a message queue? RabbitMQ, ZMQ, IBM MQ, ... I don't know if anyone has tried to put all of these on the same page and product matrix, or even keep track of them.
There's just a lot of stuff out there to learn and take advantage of. Being an effective software engineer in business is just as much about reusing existing stuff as it is about building new stuff from first principles. I'd say it's actually more about reusing stuff, since all other things equal it saves a lot of time. Don't build yourself or manage yourself what you can use for free or buy unless it's your core competency.
I do think the page shared here is fantastic though and has changed my attitude somewhat towards AWS.
The services they offer are great. Remember that you don't have to learn them all at once though. I've worked with amazon services for a couple of years and I still don't know/haven't used most of them. Just use what you need, really.
I find this is the key to understanding a service, library or technology. It is very difficult for me to wrap me head around something if I haven't yet encountered the problem it solves.
For example, I'm sure Docker is awesome, but I don't really understand it yet because I haven't yet felt the pain Docker takes away. So I enjoy following new technologies, but when I don't really see the point I just assume I haven't experienced the pain the new technology takes away.
I've work with complex and critical linux firewalls, and I love some AWS networking aspects...
Your comment was like a fresh air of sincerity. We all need to deal with domain specific issues. You need to be practical to keep going on.
http://arstechnica.com/information-technology/2015/08/netfli...
http://arstechnica.co.uk/information-technology/2015/08/netf...
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.
Here, that's the catch. Most companies simply can't. Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.
> Competing against Amazon, Microsoft and Google for talent doesn't sound like a smart strategy.
You don't have to compete. They are trying to make a profit. You just need to be better off, long term. That could be a mixture of lower service fees, more flexibility, improved productivity, less vendor lock in, etc.
Relying on any single company's services, particularly for key/essential systems your business relies on, doesn't sound like a smart strategy.
"You just need to be better off, long term." - This is a good one. Do you really think your homegrown Docker environment, Hadoop cluster and/or state-of-the-art Cassandra ring maintained by your one and only skilled Unicorn is a better long term plan than 100% managed alternatives? Let's see how well (and how secure) your in-house stuff work 2-3 years down the road and how it will then compare with the always "up-to-date" alternative.
The "vendor lock-in" part is your only valid argument, in my opinion. Costs/benefits will have be weighted properly. How much do you value business agility and pace of innovation vs. increased vendor dependency?
The proper answer will be different for all businesses, but I would argue that as long as a specific IT component/technology is not part of your core business, you might be better off buying it off-the-shelves instead of building it and maintaining it yourself.
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.
The highest barrier, quelle surprise, is dealing with interconnect telcos.
Disclaimer: I work at Linode, but have felt this way since before I started.
To make the analogy accurate:
Running a business on AWS is like taking Uber to work every day. At some point it makes sense to just buy the car, hire a driver, find a good mechanic, lease a parking spot, purchase automobile insurance, remember to buy gas, deal with speeding tickets, schedule regular maintenance ....
At some point it makes sense, but it is way, way down the road for most startups.
Netflix spends millions on AWS -- but it would never make sense for them to do it themselves.
My average was ~$140K per month -- and it would NOT have made sense to do self DC.
Right now, im deploying from DC to AWS and dropping my cost and increasing my performance...
Thing is, unlike the "get driven to work" analogy, programmers/etc are in the same problem domain as the required services.
It would be like a mechanic taking an Uber to his garage every day because he couldn't be bothered personally owning a car. What?!
"Car leases" (rented dedicated servers [possibly even managed]) are a happy medium everyone should consider.
But programmers should be focusing on delivering their startup's unique technology or service, not building and maintaining commodity infrastructure.
But I'm continually embarrassed when companies who raised $100Mns in Series B funding continue to rely on AWS when they could have build out much sooner, and reduced their burn rate measurably.
I can't wrap my head around why Amazon would make names for some very useful services so inscrutable.
It's like the developers were put in charge of naming everything.
I think this comes from considering all those services as separate products. After all, today every product needs a distinguishable name, a logo, etc. /s
https://youtu.be/DERzYnthq1s?t=21m13s
"There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." ~ Jeff Atwood
You're welcome!
My clear favorite is Google. Things are generally simpler (in a good, well-designed way). I get the feeling smart hackers are designing things.
With AWS, the general feeling is that is designed by bureaucrats, the type of people who like big, slow and boring companies.
should have been called: Amazon GitScanner
Use this to: search your online source code repos for injudiciously committed access keys
It's like: Slamming the door in bitcoin miners' faces
I'm surprised they don't offer this actually
There is a category violation in the name since, arguably, AWS Lambda functions are not true anonymous functions, having ARNs to identify them. If only I could save environment state along with the code function (e.g. for injection of runtime secrets); it'd be AWS Closure.
Where's the main danger as you see it
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
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.
I have no idea what your business does or what services you need, but there are plenty of other vendors from simple rented virtual machines up to full co-lo of customer owned hardware. The good ones will rely on good customer satisfaction rather than artificial vendor lock-in to remain profitable and competitive.
Considering all AWS ElastiCache is is "hosted Redis", that one confused me the most. Out of all the AWS services, this is the least 'magic' and custom and easiest to come up with a name.
That seems silly, and kind of missing the entire point of this submission. I haven't used any of Amazon's services, so having something to translate back to things I can understand was really helpful, and I feel like I have a much better idea of what Amazon offers.
The post claims to have "better hames" for the AWS services. Many of those names are much worse.
Take the suggested "Amazon Beginning Cut Pro" which was their suggestion for "Elastic Transcoder".
"Beginning Cut Pro" is clearly a reference to Apple's NLE, Final Cut Pro. I would suggest that there are literally zero people on the planet, who would use Amazon's video transcoding service (I imagine it's essentially a distributed ffmpeg queue.) to process video files before importing them into FCP.
This isn't "tongue in cheek", this is "stupid and confusing as an attempt at a laugh". I mean, what if I suggested that a hosted Memcached service be called AppStart because it uses memory and Apps use memory.
> having something to translate back to things I can understand was really helpful
My issue is that several of the services covered, already have a MORE MEANINGFUL name. So if I had no idea what "Elastic Transcoder" did, but it was instead called "Amazon Beginning Cut Pro", I would then assume it's somehow a tool meant to work with FCP, and disregard it (I don't need a NLE, at most maybe I need something akin to ffmpeg, so I can transcode/scale video files between formats automatically and efficiently.
If it's comedy, call it comedy, and make it actually funny.
If it's meant to be a useful guide, make it fucking accurate, or it's worse than what AWS is doing already.
I found it both funny and useful. But I can see where you're coming from. If I wanted something fucking accurate that goes into greater fucking detail than 1-2 mostly tongue-in-cheek sentences I'd go to the fucking source.
http://cyberduck.io https://panic.com/transmit/
They also support SFTP, and WebDAV too. Are these protocols all the same thing now, just because some apps support multiple protocols?
FTP is a protocol, but people use FTP in a variety of wrong but commonly understood meanings:
FTP Server = Hard drive accessible via FTP, not the server on that machine running the protocol
FTP Program = a file-management interface that uses FTP protocol to send commands
HTTP is also a protocol, though 'web browsers' can browse other protocols, as well as offline files.
Saying that an FTP Client that contains support for S3 is a misnomer is like arguing that accessing a file from your desktop using a 'web browser' isnt correct since you arent browsing any web.
The list is aimed at demystifying the confusing terms for the layman, its not aimed at providing the most technically correct taxonomy (since that would also not communicate much to the layman)
When I use my FTP client for SFTP am I using FTP or SSH?
If you're using sftp you're using ssh. It doesn't matter if your client also talks to ftp servers.
I like the services they offer, I just really hate the names they gave it. Funny enough, Jeff Bezos said in an interview that names of a product is important #irony
In fact, if you spend more than a couple of weeks implementing algorithms in your entire career you're probably doing it wrong or part of the 0.1% of programmers working on low level libraries.
Sometimes, it really is easier to just implement something your self than go through the "soul destroying process" of figuring out how to correctly set up and configure a library, framework, or piece of open source infrastructure.
Not an algorithm, but it can be a lot easier to write your own SQL, for example, than setting up and configuring Spring and Hibernate. (Talk about soul destroying. Yes, I am a Java developer, why do you ask?)
But then the next person to look at your code has completely 0 support, rather than the very little support they'd have from the crappy documentation and stack overflow if you used an open source library.
Edge cases will consume months of development instead of spending a day or two wrestling with poorly written error messages or badly documented APIs.
The one I always hit in .Net development is logging, log4net and elmah are both abysmally poor at documentation, but incredibly easy once they're actually set up.
* S3 is not FTP. It's more like static web hosting and storage.
* VPC is not a "colocated rack" as it doesn't offer physical placement of hardware. Amazon VLAN would be a better name. It's just private network address space.
It's fine the way it is.
I also did not take this particular description to indicate a literal FTP service.
Analogies do not have to be perfect to be helpful. I've never used Amazon web services, perhaps partly because I found their terminology too obfuscated to bother trying to figure out what it did. Similar services provided by other companies were more recognizable to me for what they were.
I found the post here helpful.
Neither did I. But it's flawed even as a rhetorical device. For that kind of thing to work for me, it would have to at least be plausible.