Live data from Hacker News

AWS services explained in one line each

adayinthelifeof.nl

251–260 of 355 posts

Re: AWS services explained in one line each

#251

This is a 100 x better than their website. I've actively walked away from Amazon products because I could barely make out what it really was and if I could use it for the application at hand. Many thanks!

nowhere close to 100x. actually it’s worse than the aws names across the board. the names have a logic to them but I agree it’s intimidating to learn hundreds of things at the same time - so you don’t. you learn the bits and pieces you need. for example: EC2 actually comes from Elastic Cloud Compute. You have Compute in the Cloud which also happens to be elastic. S3 is Simple Storage Service. It’s a Service for Stori…

TIL what runs on port 53. I have never understood this name and I’ve been a professional software engineer for 8 years.

Re: AWS services explained in one line each

#253
I made this list for my buddy a while back. It's meant to be more humorous than exactly correct

Route 53 - Holy shit! It's NSD

WAF - Holy shit! It's modsecurity

SES - Holy shit! It's Postfix

Inspector - Holy shit! It's OSSEC

GuardDuty - Holy shit! It's Snort

Data Pipeline - Holy shit! It's Cron and Bash

Athena - Holy shit! It's Prestodb

Glue - Holy shit! It's Hive Metastore and Spark

OpsWorks - Holy shit! It's Chef

VPC - Holy shit! It's a VLAN

Snowball - Holy shit! It's a truck full of hard drives

CloudWatch - Holy shit! It's syslogd

Neptune - Holy shit! It's Neo4j

ElastiCache - Holy shit! It's Redis

DynamoDB - Holy shit! It's MongoDB

S3 Glacier - Holy shit! It's DVD backup

EFS - Holy shit! It's NFS

Elastic Block Store - Holy shit! It's a SAN

Elastic Beanstalk - Holy shit! It's Apache Tomcat

EMR - Holy shit! It's Apache Hadoop

Elastic Cloud Compute - Holy shit! It's a virtual machine

Kinesis - Holy shit! It's Apache Kafka

QuickSight - Holy shit! It's Tableau

Re: AWS services explained in one line each

#255
post #238

Earlier quoted context omitted.

go to: https://aws.amazon.com/products/ look up your service. each service has a 1 line description that captures what it does. eg Athena = query data in s3 using sql i don’t really get why people cannot be bothered to learn what a service does and want to pretend they get it from the name. you need to learn the ins and out of the service. the name is the least of your worries.

> i don’t really get why people cannot be bothered to learn what a service does and want to pretend they get it from the name. you need to learn the ins and out of the service. Names matter. When your first experience with a product is an opaque name or description, it usually tells you one of two things: 1. The people behind it are not good communicators. If so, this will likely show up in many of the other product…

Yes, this is a huge problem throughout the industry.

The tech world is gibberish. The real world is gibberish too, but the comparatively large number of tech products (because of the ease of releasing software) really exacerbates the problem in tech. Everything is a code name, in-joke, or initialism.

If this were limited to public products then you could write it off as overly ambitious branding, but you can tell it's an issue because internal products suffer the same problem. You know it's bad when you can't even navigate your own company's hierarchy because you don't know what half the team names mean.

Unfortunately, this will probably never change; there's too much precedent. Naming things incomprehensibly is fun, it creates a barrier to entry that makes developers feel smart, and the tech world doesn't value communication enough to change it. In a world where stackoverflow serves as de facto documentation for many major tech products because their own documentation is terrible, I hardly expect those same companies to value coherent naming.

Re: AWS services explained in one line each

#256
post #64

Earlier quoted context omitted.

Ha good luck explaining in one sentance the difference between Flume, Spark, Storm, NiFi, Camel, Apex, Flink, Beam.....

I’ll try. Heres what u should know from these: Fast, Reliable, Stream Processing - Flink Data Science on Big Data - Spark Reliable Distributed Log Aggregation - Flume Low Code Data Flows w/ GUI - NiFi Zapier for Enterprise Software - Camel A Single API for Batch and Stream Jobs. Execute on Spark, Flink, managed services etc. - Beam Never heard of anyone use Apex over Flink. Storm community has branched off into Flink…

From the little I know,

Spark was built as a Batch job solution. Flink was built as a Streaming solution. Since Spark needed to adapt, they leveraged micro-batching to operate as a streaming solution.

They are very similar today. Maybe some remnants of the original design make Spark "slightly less appropriate" for pure streaming usecases, or possibly less able to iterate on future features/optimizations, but so-far that line of reasoning has been only speculation.

Re: AWS services explained in one line each

#257
post #26

Consider that your typical enterprise software project will use quite a lot of these, and that you pay for them all separately, and sometimes pay twice for them (e.g. S3 you pay for storage and for outbound bandwidth). It's quite a tour de force how Amazon have taken "separation of concerns", applied it to web services and used it to create complex and difficult to understand or predict pricing to print money. Bravo.

Brilliantly well put. May I screenshot this to 9gag?

Sure

Re: AWS services explained in one line each

#258
post #198

Love it! Does anyone know if something similar for competitors? More specifically azure?

I had this one bookmarked, I think it's originally from 2017. https://web.archive.org/web/20190508145128/https://www.exped...

Awesome!!!!!!! Thank you

Re: AWS services explained in one line each

#259
post #247

You are missing one of the really amazing services: Snowmobile ( https://aws.amazon.com/snowmobile/ ). It is a real truck, that connects to your data center, copies up to 100 PB of data and drives back to one of the AWS data centers and dumps the data there...

"Never underestimate the bandwidth of a truck full of hard-drives driving down the highway" or however the saying goes. Latency is extremely long, but the bandwidth is crazy once it's arrive!

Edit: Original quote (seems I accidentally modernized it a bit):

> Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway – Andrew Tanenbaum, 1981

Re: AWS services explained in one line each

#260
post #234

Earlier quoted context omitted.

We were in no way one of "their biggest accounts". We were a couple guys in a cramped office over a mattress store, with a production service so small we could have run it from my old laptop. I guarantee it cost them at least 10x more to send those consultants over to us than we spent on AWS in a year, even before the optimizations they pointed out.

But here you are, letting us know that they have been wonderful sending consultants. It's part PR, part long term customer acquisition

Maybe, just maybe it’s a good product with good customer service? And the reason it costs so much is because you get what you pay for?
Post reply on HN