Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS services explained in one line each

adayinthelifeof.nl

Post reply on HN
Print view View original

261–270 of 355 posts

Re: AWS services explained in one line each

#261

Post by 1MoreThing »

rainyMammoth wrote: post #242
ken wrote: 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

Exactly. It's about developer lifetime value, not single customers.

Re: AWS services explained in one line each

#262

Post by adwww »

faizshah wrote: post #174
adwww wrote: 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…

Wow that's actually a pretty good effort.

We use Camel, Spark and Beam to do much the same thing at my work, so despite using them all semi regularly, I've never known why you'd pick one over the other.

Re: AWS services explained in one line each

#263

Post by [deleted] »

biohax2015 wrote: post #260
rainyMammoth wrote: post #242

Earlier quoted context omitted.

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?

[deleted]

Re: AWS services explained in one line each

#264

Post by joshfraser »

Sometimes it pays to be boring. One of the hardest parts of using AWS is learning all their silly names for everything. I know it's tempting to be cute when naming things, but everyone else wishes you would just be clear and descriptive. I've seen this play out at startups that love to name servers after galaxies or cartoon characters. It's all fine until your new employee onboarding guide comes with a massive memorization test before you can be productive. Yes, db-master and db-slave are way more boring names than Saturn and Uranus, but do everyone a favor and express your creativity somewhere else.

Re: AWS services explained in one line each

#265

Post by sokoloff »

joshfraser wrote: post #264

Sometimes it pays to be boring. One of the hardest parts of using AWS is learning all their silly names for everything. I know it's tempting to be cute when naming things, but everyone else wishes you would just be clear and descriptive. I've seen this play out at startups that love to name servers after galaxies or cartoon characters. It's all fine until your new employee onboarding guide comes with a massive memori…

I think they went through a middle phase of cutesy naming, but this seems to have subsided some (to the good).

Simple Queuing Service, Simple Storage Service, Elastic Compute Cloud, SimpleDB are names that very much make sense. Greengrass, Lightsail, not so much. EKS, Outpost, Ground Station, and Lake Formation are more toward the usefully descriptive side again, I think.

Re: AWS services explained in one line each

#266

Post by faizshah »

yazaddaruvala wrote: post #256
faizshah wrote: post #174

Earlier quoted context omitted.

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 t…

So Flink differentiates in stream processing in two major ways:

- Flink guarantees exactly once stream processing through a barrier checkpointing system.

- Flink has very detailed APIs for handling state and doing stateful stream processing.

Additionally, Flink has one of the most active communities in the Apache Software Foundation: https://blogs.apache.org/foundation/entry/the-apache-softwar...

In situations where you want to create a streaming application with persistent state you might choose Flink over spark streaming.

Re: AWS services explained in one line each

#267

Post by alexchamberlain »

elchief wrote: post #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 V…

> Neptune - Holy shit! It's Neo4j

Neptune - Holy shit! It's Blazegraph

https://blazegraph.com/

Re: AWS services explained in one line each

#268

Post by zamalek »

s_dev wrote: post #31

Similar to https://expeditedsecurity.com/aws-in-plain-english/ Why does AWS use such convoluted language? Is it because they're dominant and it adds friction to moving to another provider?

> Why does AWS use such convoluted language?

This is the exact reason I prefer Azure. I can use the search textbox to find something and the name is usually pretty explanatory (but they do have some daft stuff, like 3 different queue offerings with pretty vague documentation on the differences).

Re: AWS services explained in one line each

#269

Post by kavehkhorram »

davedx wrote: 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.

Hey guys,

I faced a similar issue at the company I work for (where a PM had activated an instance for months and racked up a $9k bill). I've been spending my coronavirus time hacking together a service that hopefully makes billing on AWS more clear. It does cost optimization and anomaly detection right now, and I plan on adding more features as I start to see more use cases.

Check it out if you'd like, and let me know what you think!

www.usage.ai

Re: AWS services explained in one line each

#270

Post by zackbrown »

moduspol wrote: post #185
ashtonkem wrote: post #139

Earlier quoted context omitted.

I'm always amazed at the complexity of AWS billing. "Why does this cost so much" turns out to be an incredibly hard problem to answer the moment you don't have 100% perfect discipline when it comes to resource tagging. The fact that there are consultants who specialize in figuring out AWS billing was, in retrospect, a warning sign.

I usually try to cut them some slack. I mean, they're operating this stuff at Internet scale and have never (AFAIK) raised prices. They've basically got two options: * Price things in an intricate way sufficiently specific to actual costs of providing the service for many use cases * Price things more generally in a way that more or less probably results in about the same revenue The problem with option #2 is that it…

To apply established terms to these concepts, the divide you're describing is roughly "cost-based pricing" vs. "value-based pricing."
Post reply on HN