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

An engineer’s guide to cloud capacity planning

increment.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: An engineer’s guide to cloud capacity planning

#31

Post by kelnos »

samstave wrote: post #5
cridenour wrote: post #3

> Perhaps surprisingly for engineers who work in mission-critical business applications, occasional spikes of 90%+ of our users being entirely unable to use the sole application of our company was an entirely acceptable engineering tradeoff versus sizing our capacity against our peak loads. I think we found the Pokemon Go engineering team.

Acceptable engineering trade off and acceptable business decision trade off are not always the same thing. That paragraph reads to me “screw the users!” - and for them to say that around “mission critical” seems they don’t understand the critical mission...

I think you're parsing that statement wrong: he's saying that engineers who are used to building mission-critical apps would likely be surprised about how acceptable downtime was for their non-mission-critical app (a game).

Re: An engineer’s guide to cloud capacity planning

#32

Post by ryanmarsh »

johnpython wrote: post #13
ryanmarsh wrote: post #11

I don’t mean to sound flippant here but going Serverless would obviate the need for much of this guide.

Going serverless would increase your costs significantly. Have you seen how much AWS charges for Lambda use? Where did this myth of serverless saving you money come from?

I keep hearing this from people who don’t say they’ve built out Serverless stacks. But I keep hearing from people who switched that they’ve been able to cut costs. So in my limited experience this has so far proven not to be true in practice.

Re: An engineer’s guide to cloud capacity planning

#33

Post by samstave »

kelnos wrote: post #31
samstave wrote: post #5

Earlier quoted context omitted.

Acceptable engineering trade off and acceptable business decision trade off are not always the same thing. That paragraph reads to me “screw the users!” - and for them to say that around “mission critical” seems they don’t understand the critical mission...

I think you're parsing that statement wrong: he's saying that engineers who are used to building mission-critical apps would likely be surprised about how acceptable downtime was for their non -mission-critical app (a game).

Well thank god, that makes way more sense!

Re: An engineer’s guide to cloud capacity planning

#34

Post by closeparen »

beberlei wrote: post #25
tyingq wrote: post #15

Earlier quoted context omitted.

Not to say it's as robust a strategy as a VPC, but DO does have something called a cloud firewall. It supports the idea of tags that apply to groups of servers. https://www.digitalocean.com/community/tutorials/an-introduc...

The problem on DO is not outside tradfic but insode. when you enable networking everyone in the same DC network can access open ports on your machines. That elastixsearxh or redis you use needs ssl and pw protection otherwise you have a big problem

You can configure the cloud firewall so that only VMs in your account with a certain tag can communicate, even over the internal network.

Public network + firewall feels dirtier than private network, but in reality they are the same thing: a network that’s only accessible to your VMs, to the extent that you trust the provider’s software to enforce that boundary.

Re: An engineer’s guide to cloud capacity planning

#35

Post by derefr »

samstave wrote: post #8
lostcolony wrote: post #7

Earlier quoted context omitted.

The critical mission is to deliver as much business functionality as possible within the business constraints. The business constraints often include cost. They also may be arbitrarily far from 100% uptime.

Yeah, agreed - but that paragraph was worded in such a way as to convey "screw the users for spiking use, such that the application is now unavailable, and now ALL business halts..." -- Or did I misinterpret that?

I just read it as "the compute required to reach 100% uptime would cost more per minute than we lose per minute that we can't access the app." I.e., an entirely business-wise consideration, even if phrased in terms of engineering tradeoffs.

Re: An engineer’s guide to cloud capacity planning

#36

Post by samstave »

derefr wrote: post #35
samstave wrote: post #8

Earlier quoted context omitted.

Yeah, agreed - but that paragraph was worded in such a way as to convey "screw the users for spiking use, such that the application is now unavailable, and now ALL business halts..." -- Or did I misinterpret that?

I just read it as "the compute required to reach 100% uptime would cost more per minute than we lose per minute that we can't access the app." I.e., an entirely business-wise consideration, even if phrased in terms of engineering tradeoffs.

That’s actually a salient point! I appreciate you telling me that as I had not thought of it that way! Seriously.
Post reply on HN