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

AWS costs every programmer should know (2019)

david-codes.hatanian.com

Post reply on HN
Print view View original

121–130 of 163 posts

Re: AWS costs every programmer should know (2019)

#121

Post by philliphaydon »

bombcar wrote: post #118
philliphaydon wrote: post #73

Earlier quoted context omitted.

> Thinking back on those, it’s hard for me to believe that most cloud hosted companies are prepared by checking a box without actually testing. We are talking about MultiAZ, Availability Zones. Not different regions. Setting up redundancy across regions is not easy. But for majority of the people using AWS a single region with MultiAZ is good enough.

It's hard to simulate an AZ failing, and when it does, half the internet goes offline, so people don't really complain that much .

About 5 or 6 years ago we had an alert in the middle of the night that our RDS instance dieded. It failed over in about 15 seconds (SQL Server so it’s a bit slow compared to PostgreSQL) but the MultiAZ worked as advertised. The downside is AWS never told us why it occurred.

Re: AWS costs every programmer should know (2019)

#122

Post by deathanatos »

philliphaydon wrote: post #18
fulafel wrote: post #12

Earlier quoted context omitted.

If you're not testing az failovers you're probably just wasting money, like untested backups... But it's true that most people don't know this and aren't testing it because they don't know that az failovers don't automatically just work(tm). And the second downside of course would be asymmetry between the envs and divergence in the IaC etc resulting in more complexity and engineering work. (Of course you're probably…

If you’re building your own infrastructure in a data center then sure you absolutely want to test your redundancy. But with AWS it’s a checkbox. It’s transparent to you and your applications. The infrastructure to host in multiple AZs is already in place. The only real issue with MultiAZ is the failover in RDS depending on the database you use could be seconds or 10s of seconds.

> But with AWS it’s a checkbox.

And I'd test the checkbox all the same. We learned just this week that one of our setups, which checks the cloud-provider provided box to have its VMs distributed across 3 AZs, is susceptible to the loss of a single AZ. Why? Because the resulting VMs … aren't actually distributed across 3 AZs as requested. (The provider has "reasons" for this, but they're dumb, IMO. It should have been as easy as checking the box.)

Re: AWS costs every programmer should know (2019)

#123

Post by tpxl »

moduspol wrote: post #68
tpxl wrote: post #63

Earlier quoted context omitted.

> The amount of app code to solve the same problems without them is orders of magnitude more plentiful and complex, which is why we avoid it. The amount of application code to write to a filesystem is... zero. The amount of application code required to setup a webserver in Java Spring is... zero. Not sure what Kinesis does, but the amount of application code required to connect to a database is zero (spring), to conn…

There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. Whether you call it app code or not, it's something that you (and your team) will be on the hook for building and maintaining over time. Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of J…

> There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things.

And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane.

> Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of Java Spring.

Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science.

> Same with the care and feeding of RabbitMQ and Kafka

Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails.

Re: AWS costs every programmer should know (2019)

#125

Post by kqr »

boberoni wrote: post #24

The two data visualizations in the article are poorly designed. They show line graphs where the X-axis is the type of EC2 instance and the Y-axis is the price. Firstly, the X-axis of any line graph should be time. Or perhaps some other variable that "progresses". It's bizarre to use a category to label the X-axis of a line graph. Secondly, the X-axis is not ordered alphabetically, but seemingly randomly. I don't mean…

The point at which you turn a bar chart or scatterplot into a line chart is when and only when intermediary values can be linearly interpolated between adjacent values.

This is often the case when the X axis is time, but far from always, and there are other types of X axis that satisfies that property too.

That's the strict way of looking at it.

Slightly more loosely speaking, a line also helps comparing whether adjacent values are higher or lower, because humans are fairly good at judging angles relative to each other. So under this looser requirement, the X axis values have to be such that adjacent ones are more comparable than further apart ones.

Under the looser requirement, time is actually a surprisingly bad X axis because values further apart are normally just as valid comparisons as those close together!

There's a third, very loose reason to connect the points of a scatterplot with lines: it helps the eye judge the sequence of points, and thus get a sense of the internal variation in the series.

This is a very loose requirement, but also a powerful tool.

Re: AWS costs every programmer should know (2019)

#126

Post by ceejayoz »

philliphaydon wrote: post #121
bombcar wrote: post #118

Earlier quoted context omitted.

It's hard to simulate an AZ failing, and when it does, half the internet goes offline, so people don't really complain that much .

About 5 or 6 years ago we had an alert in the middle of the night that our RDS instance dieded. It failed over in about 15 seconds (SQL Server so it’s a bit slow compared to PostgreSQL) but the MultiAZ worked as advertised. The downside is AWS never told us why it occurred.

They don't tell you because you're not supposed to care, and there's no human involved in the process to do a post-mortem.

Something on the instance host died, most likely.

Re: AWS costs every programmer should know (2019)

#127

Post by ceejayoz »

philliphaydon wrote: post #62
cutthegrass2 wrote: post #58

Earlier quoted context omitted.

Whilst the VPC itself is free, they get you on the NATGW - which you probably need along with the VPC in most cases.

Had to use a NATGW temporarly on AWS Lambda's to access the database and make remote http calls. But now it all works without the NATGW. Haven't had any other need for one.

IIRC, you want one per AZ, or you'll get billed for extra cross-AZ traffic when instances in zone B's private subnet use the NAT gateway in zone A.

Re: AWS costs every programmer should know (2019)

#128

Post by moduspol »

tpxl wrote: post #123
moduspol wrote: post #68

Earlier quoted context omitted.

There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. Whether you call it app code or not, it's something that you (and your team) will be on the hook for building and maintaining over time. Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of J…

> There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. > Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of Java Spring.…

> And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane.

It's substantially less, and declarative. It also includes stuff commonly pushed to phase 2 in on-prem deployments, like TLS between entities, proper IAM, and built-in metrics/logging.

> Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more instances. Not exactly rocket science.

If it's stateless, yes, though I was just responding to an example. Not all technical problems are so simple.

> Same on AWS, except now you are at the mercy of someone else's whims to see this works when it fails.

The business is always at the mercy of someone "else," whether it's you, the person who replaced you, or AWS. And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee. Same with Lambda, Kinesis, DynamoDB, SQS, etc. Unless you've got special requirements, you're wasting time and resources reinventing the wheel.

Re: AWS costs every programmer should know (2019)

#129

Post by tpxl »

moduspol wrote: post #128
tpxl wrote: post #123

Earlier quoted context omitted.

> There will be substantial amounts of code you are writing to provision, set up, maintain, scale, and troubleshoot all of those things. And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. > Getting your Java Spring web server to scale to thousands of concurrent instances will require a lot of undifferentiated work outside the scope of Java Spring.…

> And the amount of infra code you have to write to do that in AWS is any less? No, it's just as much, except more arcane. It's substantially less, and declarative. It also includes stuff commonly pushed to phase 2 in on-prem deployments, like TLS between entities, proper IAM, and built-in metrics/logging. > Scaling a RESTful webserver is an exercise in slapping a load balancer in front of it and running a few more i…

> It's substantially less, and declarative

There are declarative ways to manage bare metal machines, such as terraform, nix and puppet.

> And AWS is way better at keeping S3 running at scale and maintaining this stuff over time than your average IT / DevOps employee

Yeah no, the outages we faced _because_ of AWS were way, way worse than what we faced with our average IT/DevOps employees at my old jobs. This keeps getting repeated and it's going to keep being wrong.

Re: AWS costs every programmer should know (2019)

#130

Post by garethmcc »

dijit wrote: post #51
moduspol wrote: post #46

Earlier quoted context omitted.

This doesn't feel like a meaningful distinction. You can go from an empty cloud account to a fully-provisioned application stack in minutes with the right infra-as-code. Provisioning infrastructure at that level is mutually exclusive with self-hosting. But true, even with self-hosting, you can use infra-as-code at various levels (Ansible, OpenStack, self-hosted Kubernetes). It's just not really comparable to having y…

Who cares when you can accidentally bankrupt your company with the wrong keystroke? Time to spin up is nice for prototypes, it can be very freeing. The mistake that people make is assuming AWS can host things better than they can, since they’re only mere mortals: it leads to a sort of learned helplessness where you assume the cost of a thing is it’s true value and not an egregious markup. My biggest gripe with these…

The "bankrupt your company with the wrong keystroke" is not entirely accurate. AWS does work with companies (or even individuals) if they genuinely made an error that wracked up a huge bill. Personally they have dropped bills of $1000's when I made a bone headed mistake and have seen companies get $100 000's of bills credited due to the same issue. They are not in the business of ripping people off in the short time who would spend a lot more than that in the long term.
Post reply on HN