9 ms·

Hey HN, I wrote this, thanks for all the feedback. In particular if I've mischaracterized the functionality of a service or you see something that's really off

Hey HN, I wrote this, thanks for all the feedback. In particular if I've mischaracterized the functionality of a service or you see something that's really off please email me at mike@expeditedssl.com or just tell me here and I'll fix it.

wspeirs 11y ago
This is great... well done. Any chance you could side-by-side it with Azure & Google Cloud's offerings? That would be MASSIVELY useful!
- seiji 11y ago
  Holy Rosetta Stone Grail of Infrastructure as a Service: combine this document, include other provider offerings in the grid matching features, then also include the compatibility list from libcloud (https://libcloud.readthedocs.org/en/latest/supported_providers.html https://libcloud.readthedocs.org/en/latest/supported_provide...) so we can understand how everything can easily be used together. 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.
  - wspeirs 11y ago
    To really "go for the gold" you can add in other abstraction libraries for talking to clouds like http://www.dasein.org/ http://www.dasein.org/ and https://jclouds.apache.org/ https://jclouds.apache.org/
djm_ 11y ago
Hi Michael! Great guide. SNS is not just for mobile app developers and should probably belong in the "Web Developer Services" section. 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.
- michaelbuckbee 11y ago
  All good points, I think this is where the "plain english" starts to break down and you _have_ to really come to grips with exactly what the services are doing. I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.
  - djm_ 11y ago
    Well you did a fantastic job and I learnt a load. Many thanks.
  - JangoSteve 11y ago
    I totally agree with the grandparent comment. We use SNS for a few apps, none of which are mobile apps. If you want a high level explanation for someone, I'd describe it as Amazon Callbacks. It lets you create callbacks for any action in and across any Amazon web service, where that callback can be in the form of an HTTP post (e.g. back to your web application), email, push notification, etc.
brudgers 11y ago
I surprised myself after reading your article by signing up for your newsletter and I can probably count on my fingers without using binary encoding the number of times I've done that based on an HN submission. The article's format is a hard one to sustain across a list that long and stay readable and pulling it off is an achievement. Here's to your newsletter being similar goodness.
frankcaron 11y ago
I'm kind of in love with you after writing this. Thank you for doing what so few product and service companies do: naming a product in a manner that makes it almost instantly-understandable as to what problem it solves.
- samstave 11y ago
  This should be "product management 101" type of doc that all product managers should need to make for anything they are managing the evolution of.
dandare 11y ago
Well done, as a front end developer I find this tremendously useful. Could you go even deeper and describe various components of some of the services? What is a bucket and what is an instance? etc. Thanks
- michaelbuckbee 11y ago
  The plan is to go back through and start doing a similar "plain english" post about each of the services. If you're interested in getting those, please drop your email into the little newsletter form on the page.
  - dandare 11y ago
    I did :)
  - samstave 11y ago
    A great addition to this would be simple, real-world examples of how you may use each service. Build up to a more complex stack by evolving the use of each in iterative layers.... I'd like to help contribute to this if possible.
deleted 11y ago
[deleted]
robodale 11y ago
Thanks dude - finally one place where I can quickly understand everything Amazonian!
genericacct 11y ago
Cognito is probably more like "oauth and backends for your apps"
- edpichler 11y ago
  About Cognito, now I can understand what they are trying to mean.
- patsplat 11y ago
  My primary understanding of Cognito was that it was a great way to turn social or developer login into temporary AWS credentials with a specified role, allowing AWS apis to be safely used client side.
- mehdim 11y ago
  Personally I find that Cognito is a great name, which represent well the big picture and challenge ls of identity issues.on the web. Disclosure : I am Founder of oauth.io to what Cognito is compare.
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.
mkobit 11y ago
I would have preferred if some of the full comedic ones were toned down because this has some use. The amount of AWS services is hard to keep track of, especially considering when they have a bunch of slightly different solutions to a similar problem, is quite staggering. E.g. I want to deploy my code - should I use Ops Works, Pipelines, CodeDeploy, Ec2 Container Service, Elastic Beanstalk, Elastic Breadstick, CodePizza, blah blah blah? > 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.
- shampine 11y ago
  I'm going to start saying Elastic Breadstick and see if my PM starts using the phrase to solve everything. He likes buzzwords.
  - samstave 11y ago
    It comes with Marinara Memory Management -- MMM
    - cmstoken 11y ago
      M3
- michaelbuckbee 11y ago
  I'd considered calling it "Amazon State Machine" - better?
saberworks 11y ago
Thanks for the document, it's fantastic. One thing that would help for me would be spelling out what the actual amazon acronyms mean. For example: EC2 - Elastic Compute Cloud. Also a link from the amazon acronym to the official page at amazon would be helpful.
trevmckendrick 11y ago
Would love to hear by what % your revenue increased today (or in the next month or so from lag time)
- michaelbuckbee 11y ago
  We don't actually have an AWS product released yet. This article was part of our becoming more familiar with all the different aspects of AWS (like a lot of other developers we're long time users of S3 and EC2 and PAAS services built on top of parts of AWS).
HenryTheHorse 11y ago
Your list was discussed extensively in the office today and everybody loved it.
rzv 11y ago
I think you misspelled "ingest" ;)
donlzx 11y ago
A good read and helpful list. 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.
disbelief 11y ago
This is great! One nitpick: I wouldn't say that SQS is like Sidekiq. Because sure, part of Sidekiq is a queue (in Redis), but the more important aspect of Sidekiq is the workers that operate on the queue. If you needed a second example I'd have gone with ZeroMQ.
drfritznunkie 11y ago
Having just come off a stint with Azure, my experience with generic names (like many you suggested and like most Azure service name) is that they're huge negatives. It makes searching impossible even when you're using the service's documentation. Got a problem with Azure Web Apps? Good luck searching for it. What about Azure SQL Database? Or Azure Virtual Network? Azure Storage?

wspeirs 11y ago

This is great... well done. Any chance you could side-by-side it with Azure & Google Cloud's offerings? That would be MASSIVELY useful!

seiji 11y ago
Holy Rosetta Stone Grail of Infrastructure as a Service: combine this document, include other provider offerings in the grid matching features, then also include the compatibility list from libcloud (https://libcloud.readthedocs.org/en/latest/supported_providers.html https://libcloud.readthedocs.org/en/latest/supported_provide...) so we can understand how everything can easily be used together. 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.
- wspeirs 11y ago
  To really "go for the gold" you can add in other abstraction libraries for talking to clouds like http://www.dasein.org/ http://www.dasein.org/ and https://jclouds.apache.org/ https://jclouds.apache.org/

djm_ 11y ago

Hi Michael! Great guide. SNS is not just for mobile app developers and should probably belong in the "Web Developer Services" section. 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.

michaelbuckbee 11y ago
All good points, I think this is where the "plain english" starts to break down and you _have_ to really come to grips with exactly what the services are doing. I was trying to write this from the standpoint of describing what the services did to another developer in a really high level way.
- djm_ 11y ago
  Well you did a fantastic job and I learnt a load. Many thanks.
- JangoSteve 11y ago
  I totally agree with the grandparent comment. We use SNS for a few apps, none of which are mobile apps. If you want a high level explanation for someone, I'd describe it as Amazon Callbacks. It lets you create callbacks for any action in and across any Amazon web service, where that callback can be in the form of an HTTP post (e.g. back to your web application), email, push notification, etc.

brudgers 11y ago

I surprised myself after reading your article by signing up for your newsletter and I can probably count on my fingers without using binary encoding the number of times I've done that based on an HN submission. The article's format is a hard one to sustain across a list that long and stay readable and pulling it off is an achievement. Here's to your newsletter being similar goodness.

frankcaron 11y ago

I'm kind of in love with you after writing this. Thank you for doing what so few product and service companies do: naming a product in a manner that makes it almost instantly-understandable as to what problem it solves.

samstave 11y ago
This should be "product management 101" type of doc that all product managers should need to make for anything they are managing the evolution of.

dandare 11y ago

Well done, as a front end developer I find this tremendously useful. Could you go even deeper and describe various components of some of the services? What is a bucket and what is an instance? etc. Thanks

michaelbuckbee 11y ago
The plan is to go back through and start doing a similar "plain english" post about each of the services. If you're interested in getting those, please drop your email into the little newsletter form on the page.
- dandare 11y ago
  I did :)
- samstave 11y ago
  A great addition to this would be simple, real-world examples of how you may use each service. Build up to a more complex stack by evolving the use of each in iterative layers.... I'd like to help contribute to this if possible.

deleted 11y ago

[deleted]

robodale 11y ago

Thanks dude - finally one place where I can quickly understand everything Amazonian!

genericacct 11y ago

Cognito is probably more like "oauth and backends for your apps"

edpichler 11y ago
About Cognito, now I can understand what they are trying to mean.
patsplat 11y ago
My primary understanding of Cognito was that it was a great way to turn social or developer login into temporary AWS credentials with a specified role, allowing AWS apis to be safely used client side.
mehdim 11y ago
Personally I find that Cognito is a great name, which represent well the big picture and challenge ls of identity issues.on the web. Disclosure : I am Founder of oauth.io to what Cognito is compare.

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.

mkobit 11y ago

I would have preferred if some of the full comedic ones were toned down because this has some use. The amount of AWS services is hard to keep track of, especially considering when they have a bunch of slightly different solutions to a similar problem, is quite staggering. E.g. I want to deploy my code - should I use Ops Works, Pipelines, CodeDeploy, Ec2 Container Service, Elastic Beanstalk, Elastic Breadstick, CodePizza, blah blah blah? > 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.

shampine 11y ago
I'm going to start saying Elastic Breadstick and see if my PM starts using the phrase to solve everything. He likes buzzwords.
- samstave 11y ago
  It comes with Marinara Memory Management -- MMM
  - cmstoken 11y ago
    M3
michaelbuckbee 11y ago
I'd considered calling it "Amazon State Machine" - better?

saberworks 11y ago

Thanks for the document, it's fantastic. One thing that would help for me would be spelling out what the actual amazon acronyms mean. For example: EC2 - Elastic Compute Cloud. Also a link from the amazon acronym to the official page at amazon would be helpful.

trevmckendrick 11y ago

Would love to hear by what % your revenue increased today (or in the next month or so from lag time)

michaelbuckbee 11y ago
We don't actually have an AWS product released yet. This article was part of our becoming more familiar with all the different aspects of AWS (like a lot of other developers we're long time users of S3 and EC2 and PAAS services built on top of parts of AWS).

HenryTheHorse 11y ago

Your list was discussed extensively in the office today and everybody loved it.

rzv 11y ago

I think you misspelled "ingest" ;)

donlzx 11y ago

A good read and helpful list. 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.

disbelief 11y ago

This is great! One nitpick: I wouldn't say that SQS is like Sidekiq. Because sure, part of Sidekiq is a queue (in Redis), but the more important aspect of Sidekiq is the workers that operate on the queue. If you needed a second example I'd have gone with ZeroMQ.

drfritznunkie 11y ago

Having just come off a stint with Azure, my experience with generic names (like many you suggested and like most Azure service name) is that they're huge negatives. It makes searching impossible even when you're using the service's documentation. Got a problem with Azure Web Apps? Good luck searching for it. What about Azure SQL Database? Or Azure Virtual Network? Azure Storage?