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…
AWS services explained in one line each
251–260 of 355 posts
Re: AWS services explained in one line each
#252Re: AWS services explained in one line each
#253Route 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
#254as well as visual representation https://moca.computingarchitectures.com/en/~hello-world/
Re: AWS services explained in one line each
#255Earlier 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…
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
#256Earlier 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…
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
#257Consider 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?
Re: AWS services explained in one line each
#258Re: AWS services explained in one line each
#259You 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...
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
#260Earlier 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