> SWF -> Amazon EC2 Queue Use this to Build a service of "deciders" and "workers" on top of EC2 to accomplish a set task. Unlike SQS - logic is setup inside the service to determine how and what should happen.
I do not find this one to be that helpful, as "deciders" and "workers" doesn't make sense in this context. Logic isn't encapsulated inside of SWF, and the workers do not need to be hosted on EC2. SWF basically tracks workflow and activity versions, and is essentially a state management and work distribution system. It distributes out tasks to polling workers based on what the workers are polling, and what state is currently in SWF.
I think a (possibly) better name/use this to would be Amazon Task Orchestrator/Schedule and run jobs that do a bunch of things in order that can be distributed, where you want to run the workers on either EC2 or your own machines.
Ok, maybe not too much better, but I think it shows the use case a little bit better.
It is a general messaging service and can deliver messages to SQS, AWS Lambda, email and arbitrary HTTP(S) endpoints.
For example, we have some S3 buckets set up to send an SNS message to an SNS topic on new object creation, the topic then in turn notifies our subscribed HTTPS endpoints by sending the SNS message which we can then parse. You can also connect S3 directly to AWS Lambda so that a new event in the bucket sends an SNS message to a lambda function - which is very handy for doing things such as "server-less" thumbnailing, transcoding, etc etc.
I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.
Sounds like a good fit as an open source documentation project for a dedicated group of platform researchers to knock out collaboratively in a month.
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.
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.
Disclosure : I am Founder of oauth.io to what Cognito is compare.
Could you add the pricing model and notes? It seems to me that the pricing infos are always hidden somewhere and very hard to find out until you actually used them.
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.
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.
Disclaimer: I work at Linode, but have felt this way since before I started.
The highest barrier, quelle surprise, is dealing with interconnect telcos.
* 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.
You can also set up billing alerts, though as has been discussed, they aren't strict caps, so you can still exceed your cap.
You can start with just a few EC2 instances, so conceivably, you could everything on those you'd do with a VPS.
Maybe you decide that managing a database is taking too much of your time, so now you're looking at RDS. It's more expensive, but, it manages just about everything for you. Maybe you make the decision to switch to RDS Now you turn down that EC2 instance running your database.
Maybe now you're thinking that RabbitMQ is too much of a pain to manage, so you do the same thing with SQS. Analyze the time/cost savings of switching, and see if it makes sense.
I think for new applications, estimating is a lot harder, right? You have no traffic until someone is interested in your product, but you can sort of spitball. There's a bunch of free load testing services out there to let you roughly simulate N concurrent users, and open-source projects to simulate those users yourself.
Ultimately, and maybe someone has an idea how to do this: I don't think you can ever plan beforehand. You could be optimistic, and assume your app is going to explode, and that you'll need 8 web servers and redundant load balancers and DB with a read replica... but that's just what it seems like, optimistic. I think the closest you can get is spitballing -- assuming maybe you'll get 100 concurrent users or something -- and making sure you can handle that.
Separately, there's the whole issue of trying to make smart decisions ahead of time with your infrastructure, but similarly, this can be really hard to do.
The good thing is that services and charges that are hard to estimate (SQS, egress network bandwidth, S3 access charges) are mostly drops in a bucket compared to those that are easy to plan for (ec2, RDS, S3 / Dynamo storage).
IIRC, Amazon also offers services for a fixed monthly price, you could look into that too.
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.
Also, S3 is NOT some ftp service, it is a new concept. And why should they call Cloudfront instead Amazon CDN? Anyone using it knows what a CDN is and what Cloudfront is? Its like insisting Toyota call the Camry the Toyota Mid Size Car.
Amazon invented their own terms out of hubris.
Like most entries on the list, Amazon S3 _is_ a new concept but try explaining it to somebody without mentioning FTP -- you'll see what I mean.
What was that quote about the only hard problems in Computer Science?
Replication, versioning, security, life-cycle management, events to name a few.
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.
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".
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.
So now my Amazon dashboard looks like: https://dl.dropboxusercontent.com/s/iko1p8jdwdvjpaq/2015-09-...
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?)
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
This is very common for small companies without marketing experience, but this happening in companies like Amazon and Microsoft (Azure), I can't understand.
TL;DR version: I use "Amazon's <service name>" instead of a code name.
Pretty spot on...
In addition to KV pairs storage, DynamoDB supports querying, documents, indexing and streaming from a feature stand point and infinite provisioning/scaling from a infrastructure stand point. Give it a shot and ping me about any questions!
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
I wrote a quick and dirty chrome extension that adds these names to the dashboard: https://github.com/pierceg/Amazonese
As the co-founder of a startup doing exactly that (https://emailoctopus.com), I respectfully disagree!
Also, love the light application of humor.
It's like: Stacking cash on the sidewalk and lighting it on fire
