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

161–170 of 355 posts

Re: AWS services explained in one line each

#161

Post by freeone3000 »

philipodonnell wrote: post #150
v8engine wrote: post #19

Reminded me of these similar threads I read a while earlier: Azure: https://web.archive.org/web/20190321175020/https://www.exped... https://news.ycombinator.com/item?id=13442597 AWS: https://expeditedsecurity.com/aws-in-plain-english/ https://news.ycombinator.com/item?id=10202286

Any update to the Azure list anyone has seen? 2017 is a long time ago.

New Azure services tend to have names like "Cognitive Services Speech" or "Cognitive Services Image Recognition" or "Azure Stateful Functions"... There's not a lot to riff on.

Re: AWS services explained in one line each

#162

Post by rubber_duck »

flurdy wrote: post #152
013a wrote: post #138

> Lightsail: Amazon’s hosting provider (vps, dns, storage) Doesn't feel like accurate description for Lightsail, nor a useful one. Maybe something like "simplified deployment and billing for some AWS resources, including VPS, databases, DNS, and load balancers" (listing "storage" as something Lightsail does is kind of weird; of course, it does instance-attached block storage, you couldn't have a VPS without that. cri…

Sometimes I feel it is easier described by saying what its main competitor is. Lightsail is basically AWS' version of Heroku and App Engine. (i.e. a PAAS) I wish Google would also do this. Many times on GCP's website or at Google Next you try to decipher what the product is that they are talking about, then you realise "ah, it is their version of S3, CloudFormation etc". If they just had said that at the start... Of…

I've seen companies post feature comparison charts listing competitors, they are very useful when switching from a different provider or discovering what the product does in terms of established player

Re: AWS services explained in one line each

#163

Post by scarface74 »

mixedCase wrote: post #159
scarface74 wrote: post #142

Earlier quoted context omitted.

Yet another reason to use native tooling. If you want to take advantage of AWS features - you have to use AWS features. Blame Hashicorp if they don’t have a similar feature.

Moving from Terraform to CloudForm is as pleasant as chewing glass, and the last thing we need is more AWS lock-in unless you're running an AWS consultancy.

If you are using Terraform you are still “locked into” AWS since all of their provisioners are cloud specific.

Also if you are at any type of scale, your IAAC choice is the least of your problems.

Have you actually done a realistic project plan and estimated how much it would cost to migrate infrastructure from one provider to another once you reach any scale - including regression testing, auditing, training, etc? Do you really just use your cloud provider to host a bunch of VMs? Even then it’s not that easy at scale.

Re: AWS services explained in one line each

#164

Post by scarface74 »

unethical_ban wrote: post #160
scarface74 wrote: post #142

Earlier quoted context omitted.

Yet another reason to use native tooling. If you want to take advantage of AWS features - you have to use AWS features. Blame Hashicorp if they don’t have a similar feature.

I'm training on AWS and part of an AWS infra team - but we use Terraform partially because we intend to have production support at our company for all three big US clouds, and want the IaC layer to be uniform. I get that there are times to dive all the way in, but there is still a part of me that says "Is this what the Internet is now?"

You have looked at the provisioners for the different providers haven’t you?

Terraform in no way provides you an abstraction layer over the different cloud providers.

Re: AWS services explained in one line each

#165

Post by doorstar »

ashtonkem wrote: post #139
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.

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've been horrified at how bad this is on Azure, I'm sorry to hear that AWS has the same issue. I've signed in some mornings only to discover that I've been charged $20 for a MongoDB instance that's been sitting idle all night. Support can only come back with some hand-waving about RUs, a term that defies any clear definition.

Re: AWS services explained in one line each

#166

Post by nolok »

gowld wrote: post #153
nolok wrote: post #88

Earlier quoted context omitted.

You're absolutely right, and also absolutely missing his point. As a massive user of AWS for a long time, yes you can know exactly to the sub-detail line what you pay for, no you can absolutely not have an overview or good estimation of mapping what a change in your software stack / setup will cost or save you. Unless we're talking "remove an entire service" and then duh, yeah.

How is that different from if you ran all this stuff on prem?

First, the obvious that if a massive surge happens (attack, bug, ...) on prem stop serving, aws surprise-drain your bank account. Yes it's possible to have fail safe to avoid it, it's also very common to not have them or that they're not tested or working.

Second, the "in-between" costslike bandwidth from service to service, iops on your disk, ... They mostly don't exist on prem, you either have enough of it and it works or you don't and it doesn't work and you need to go buy a bigger pipe. They're one of the biggest source of surprise cost on AWS.

Eg take a basic data storing application, the cpu and storage space are easy to estimate and are the same as on prem, but suddenly you also need to estimate your iops, and you realize you have no idea about it. Do you have an on-prem database running somewhere ? How many iops does it need ? Unless you've had to figure it out, you have no idea and will never know on prem.

Re: AWS services explained in one line each

#167

Post by tilolebo »

Very nice!

I was surprised by 2 descriptions:

Opsworks: I thought it was using Chef under the hood. Is it really Ansible?

CloudWatch: it's actually so much more than logging, as it also provides timeseries, alerting and even scheduling. Not sure how to summarize this, though.

Re: AWS services explained in one line each

#169

Post by bcrosby95 »

koheripbal wrote: post #127
tr33house wrote: post #122

a bit tangential: I think a lot of AWS customers would actually benefit by hosting on their own machines in a data-center. The tools (and hardware) out there have become so good that there's minimal benefit to hosting on AWS for more than 4x the price. A lot of DCs also accept shipments so that even makes things easier. The trouble is that we've been conditioned, as an industry, not to think for ourselves or dare que…

That's what we (mid/small-sized company) with couple dozen machines. It is probably 10% the cost of AWS - but you do need to have at least one person that can handle the servers when/if there are issues. That one person only needs to devote maybe 2-5% of their time to it (once the systems are setup), so it's still a net gain.

Yeah, we use a mix of AWS and self hosted machines. We've had up to 40 servers with this method and devoted similarly trivial amounts of time to it. If you want it to be long term sustainable, you probably want at least 2 people that can handle it, so they can go on vacation.

If your goal is to be the next billion dollar company, it probably doesn't matter that much. But if you're self-funding and need a sustainable business model from the beginning, there's a huge growth phase (mid-sized) where the cost savings from doing this sort of thing can be large enough to be worthwhile.

I'm not sure why so many developers seem afraid of hardware. Back in the early 2000s it definitely felt more commonplace for developers to be able to deal with it. Maybe it's because we grew up having to deal with our own in the form of desktops. Nowadays it seems like lots of people just use a macbook. And that's their only exposure to hardware

Post reply on HN