Live data from Hacker News

AWS services explained in one line each

adayinthelifeof.nl

181–190 of 355 posts

Re: AWS services explained in one line each

#181

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'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.

Dealing with Azure causes me physical pain.

AWS you can poke around and figure it out, Azure is a Kafkaesque nightmare of infinitely confusing UI/UX, a permission system that is like trying to hit a moving target in a dark room, being moved by someone that hates you, doing anything seems needlessly complex, and trying to replicate/test anything locally is horrible (looking at you Azure functions).

Re: AWS services explained in one line each

#182
post #152

Earlier quoted context omitted.

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…

Your statement made me wonder if someone else had done this, and sure enough I found something -- https://www.cloudcomparisontool.com/ Look for "Object Storange" for instance and in the row will be links to all the competing services, so you could pretty easily do this to learn about competitors through the one you know... At least for the big players.

Isn't this wrong? At Google's Storage options, it says Google doesn't have Backup or Disaster Recovery options.

As long as I know, aren't those types into Cloud Storage - nearline and coldline object storage types?

Re: AWS services explained in one line each

#183

Earlier quoted context omitted.

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.

That is correct; I've always found it a missed opportunity in Terraform. I still like it a lot as a tool.

A unified abstraction layer would certainly work for a subset of cloud offerings. Think the more basic stuff like EC2, VPCs, etc. Platform specific extensions could be handled as optional arguments to the unified objects.

That said, even though you need custom Terraform definitions for each cloud vendor, using one IaC tool still beats having to use a cloud-specific one for each of your deployments. The parent's point stands.

Re: AWS services explained in one line each

#184
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?

I think "codenames" are easier to reference and discuss once you get immersed in the ecosystem. "lambda" vs. "serverless compute" - which one do you want to say 30 times a day?

Re: AWS services explained in one line each

#185
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 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's dependent upon some customers implicitly subsidizing others (e.g. any "unlimited storage" backup solution). It can work a lot of times, but sometimes it doesn't, and at AWS's scale, that could change quickly. It'll upset a lot of customers if they then have to restructure pricing to account for a small subset of customers' use cases being too costly to provide.

Re: AWS services explained in one line each

#186

Earlier quoted context omitted.

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? D…

Sigh, I should've gone ahead with the longer version of my previous comment that I deleted because I felt that pre-emptively responding to this would be unnecessary by now.

Yes I've dealt with this issue (to be more precise multi-cloud rather than migration, also used other TF providers in tandem like the Kubernetes one), and yes your TF resources are provider-specific, but being able to handle it all with the same tool instead of having to deal with an awful vendor-specific tool (to be charitable, because the reality is having to deal with mutiple ones and having them inter-operate through bash glue) vastly helps in reducing and controlling lock-in, and I would argue it's the baseline step you have to take if you don't want to risk your whole business on a single cloud provider not going to the gutter either because they've grown too big for their own good or because they're being squashed.

CloudFormation means jumping into the pit of lock-in and you can only climb back out by digging your fingers into the dirt wall, Terraform means you have climbing gear to rappel down and if you have to, get back up without as much hardship. Sure you have to put the gear on but your descent is controlled and then you can climb back up at your own leisure.

Re: AWS services explained in one line each

#188

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…

I used to feel like "the cloud is just someone else's computer" but I have changed a bit.

If you do cloud native, there can definitely be pricing and peace of mind benefits. The idea that you can deploy a globally redundant database with automatic backups, with zero installation or server/software maintenance, is pretty amazing. Lambda is awesome and powerful, AWS IAM security model is revolutionary vs. so many different network/LDAP security policies.

Re: AWS services explained in one line each

#189

Earlier quoted context omitted.

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.

Dealing with Azure causes me physical pain. AWS you can poke around and figure it out, Azure is a Kafkaesque nightmare of infinitely confusing UI/UX, a permission system that is like trying to hit a moving target in a dark room, being moved by someone that hates you, doing anything seems needlessly complex, and trying to replicate/test anything locally is horrible (looking at you Azure functions).

My sibling...

I'm trapped in this mess because the nature of our Client is that they'd consider anything besides Azure as a slap in the face, but it's been absolutely the most miserable task I've taken on in years.

As a bonus I'm getting side-eyed by teammates who have a naive faith in The Cloud and can't comprehend why this is taking so long and why I can't just give them a cost estimate.

Re: AWS services explained in one line each

#190

Earlier quoted context omitted.

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? D…

Sigh, I should've gone ahead with the longer version of my previous comment that I deleted because I felt that pre-emptively responding to this would be unnecessary by now. Yes I've dealt with this issue (to be more precise multi-cloud rather than migration, also used other TF providers in tandem like the Kubernetes one), and yes your TF resources are provider-specific, but being able to handle it all with the same t…

Is the only thing you are doing with your cloud vendor is using VMs? Not S3? Not IAM? Not SQS? SNS? You don’t have to go through security audits? Hybrid networks via VPNs/Direct Connect? You don’t have a massive amount of data that has to be transferred? Your DNS entries? Your build pipelines?
Post reply on HN