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

211–220 of 355 posts

Re: AWS services explained in one line each

#211

Post by mixedCase »

scarface74 wrote: post #190
mixedCase wrote: post #186

Earlier quoted context omitted.

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?

No longer at that gig, but in order: Kubernetes applications using Kubernetes abstractions, S3 API abstracted away at the library level, RBAC done through Kubernetes (which includes IAM integration), we did use SQS and SNS but those were easy to replace given our abstractions. No security audits (third party ones at least, we did have scripts and checklists for deps and GDPR compliance). No hybrid networks, we either had an internal API/frontend for our services or we used bastion servers for SSH proxying. Wherever data transfer was a major issue we stayed within AWS, but that's our fault for going with AWS in the first place, which doesn't belong to the bandwidth alliance; a hard migration had been discussed and informally planned for but punted for later. DNS can be handled cross-vendor easily with Terraform since it's easy to set a module's outputs to another's parameters. Pipelines we ran with CodeBuild and hosted in ECR, but running a single command and docker pushing to a repo is not something I would even consider as a migration pain.

Re: AWS services explained in one line each

#213

Post by scarface74 »

unethical_ban wrote: post #202
scarface74 wrote: post #164

Earlier quoted context omitted.

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.

Learning terraform for the various providers = learning the different syntaxes and design philosophies of different python libraries. Learning the different IaC tools for each provider = Learning Python, Javascript, and PHP. Also, Terraform does state management and can be used to package deployments of apps to different platforms. Our IaC pipeline uses Terraform to deploy resources to AWS and several other cloud too…

The provisioners are the easy part - understanding the ecosystem and how the different parts of the cloud providers relate is the harder part. I routinely go back and forth between C#, Python and JavaScript using the official AWS SDKs and I understand how to accomplish what I need in either language. Using those same languages, I wouldn’t know where to start with Azure or GCP.

Using Terraform vs CF is easy compared to using AWS vs Azure.

Re: AWS services explained in one line each

#214

Post by scarface74 »

mixedCase wrote: post #211
scarface74 wrote: post #190

Earlier quoted context omitted.

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?

No longer at that gig, but in order: Kubernetes applications using Kubernetes abstractions, S3 API abstracted away at the library level, RBAC done through Kubernetes (which includes IAM integration), we did use SQS and SNS but those were easy to replace given our abstractions. No security audits (third party ones at least, we did have scripts and checklists for deps and GDPR compliance). No hybrid networks, we either…

Everything seems easy until you actually get your project management organization involved, and your IT staff, your QA, your business analysts, your compliance department, start allocating cost for your staff etc....

Re: AWS services explained in one line each

#215

Post by moduspol »

joosters wrote: post #197
moduspol wrote: post #185

Earlier quoted context omitted.

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…

Doesn't that kind of problem get easier at large scale? It's like any time you have a limited resource to share out. e.g. if an ISP has 150mbits of connectivity, it would be difficult to provide a '100mbit' service to two homes - one busy user will clearly hit the other. But if you have 1500mbits to share out to 20 homes, the service will seem much better. As you scale up, it becomes easier to provision less per cust…

I think that works for ISPs because their service area and customer base are arbitrarily defined and within their control. They don't have to worry as much about a datacenter suddenly opening up in the middle of a neighborhood that throws off the profitability of everyone else.

And they can also impose things like bandwidth caps to curb some less-profitable customers' usage. But cloud providers, by design, are charging "per use" and expected to scale "indefinitely"... at least for expected use cases.

Re: AWS services explained in one line each

#216

Post by dodobirdlord »

teej wrote: post #205
rantwasp wrote: post #195

Earlier quoted context omitted.

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…

Cognito? Lightsail? Redshift? CodeStar? Athena? Polly? There are loads of AWS services that don’t follow any logic, they’re just distinct, easy to spell nouns.

Cognito is an identity service, “incognito” means unknown, “cognito” means known. Polly is a joke about how parrots talk, the service does text-to-speech. Athena is a goddess of wisdom, the service is for querying databases. The name is frequently some sort of silly inside joke. Except Fargate, that name means nothing...

Re: AWS services explained in one line each

#217

Post by bt1a »

skrebbel wrote: post #208
ken wrote: post #176

Earlier quoted context omitted.

I'm as anti-AMZN/AWS as anyone these days, but to their credit, Amazon has their own teams of consultants who will come to your business for free to analyze your usage of AWS and tell you how to save money. They openly joked about how it was their job to get customers to spend less money with their company.

That's not openly joking, it's sales. If you feel like you're way overpaying for AWS, you're much likelier to look out for alternatives. So if they help their biggest accounts save some money, it'll net them way more in the long run.

Right - it gives the illusion that you're 'getting an amazing deal and wow these people are great' when it reality you're probably getting gouged without the consulting and have to opt in for fair prices.

Re: AWS services explained in one line each

#218

Post by dodobirdlord »

adwww wrote: post #62
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?

This is one of the things I love about GCP. Kubernetes Engine, Compute, Storage, Memory Store, Cloud SQL, PubSub.... almost all of the main services do what they say on the tin. The only downside is - ironically - it sometimes makes googling for help a bit tricker. Eg. Are you search for generic cloud storage or the Google product with the same name?

It is kinda funny and heartwarming when you use Google to search for one of Google’s cloud products and the first result is some competitor.

Re: AWS services explained in one line each

#219

Post by StevePerkins »

> Lightsail - Amazon’s hosting provider (vps, dns, storage)

> Kinesis - Collect massive amount of data so you can do analytics (like ELK?)

Based on some of these that I'm already familiar with, I don't think I would rely on these descriptions for the ones I'm not already familiar with.

Re: AWS services explained in one line each

#220

Post by joosters »

inlined wrote: post #204
joosters wrote: post #197

Earlier quoted context omitted.

Doesn't that kind of problem get easier at large scale? It's like any time you have a limited resource to share out. e.g. if an ISP has 150mbits of connectivity, it would be difficult to provide a '100mbit' service to two homes - one busy user will clearly hit the other. But if you have 1500mbits to share out to 20 homes, the service will seem much better. As you scale up, it becomes easier to provision less per cust…

Economy of scale is different when you’re providing a cloud business because your costs (and hopefully revenue) are dominated by the head customers. Imagine a company whose business model isn’t profitable for AWS becomes the next Dropbox. Suddenly the tail can’t subsidize the head. And even if it could, the business is shot. You always need the head to subsidize the tail (e.g. free trials). You can’t let the head bec…

All these are problems, yes, but my point is they become more manageable when you have more customers. Having Dropbox as a client would be exceedingly difficult if you only have two other customers, but it gets easier as you add more customers and scale up.
Post reply on HN