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

21–30 of 36 posts

Re: An engineer’s guide to cloud capacity planning

#21

Post by adrianratnapala »

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?

The thinking is probably that if usage spikes and some people can't get access to the game and they know that this is because of spiking usage, then this just builds buzz and demand -- like hip restaurants with visible queues.

So in this case the business demand on the engineers was presumably to make sure that 10% of users get good service during the spike while the others are gracefully shown a "Sorry we are too busy right now " message.

Whether or not this is evil depends on the pricing model and other factors that determine whether those bounced user had a reasonable expectation of service.

Re: An engineer’s guide to cloud capacity planning

#22

Post by samstave »

adrianratnapala wrote: post #21
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?

The thinking is probably that if usage spikes and some people can't get access to the game and they know that this is because of spiking usage , then this just builds buzz and demand -- like hip restaurants with visible queues. So in this case the business demand on the engineers was presumably to make sure that 10% of users get good service during the spike while the others are gracefully shown a "Sorry we are too b…

These engineers and C-levels of this company should be punched in the face.

Re: An engineer’s guide to cloud capacity planning

#23

Post by jacobr1 »

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?

Going from autoscaling in EC2 (with a mix or RI for baseline load and spots for peak) to Lambdas has cut our service costs down by half. This is largely due to better utilization rates.

Re: An engineer’s guide to cloud capacity planning

#24

Post by jacobr1 »

ryanmarsh wrote: post #11

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

For general compute yes. But you still need to scale your persistent data stores. That is why AWS is investing in things like Aurora. Also you need to understand where to optimize on a cost basis by not just profiling code, but comparing costs, to usage, to performance gains in reduced resources needed.

Re: An engineer’s guide to cloud capacity planning

#25

Post by beberlei »

tyingq wrote: post #15
cakeface wrote: post #12

Earlier quoted context omitted.

How do you work on Digital Ocean or some other cloud without VPC? I haven't been able to figure this out. Sure, if I just have 1 or maybe 2 servers it's fine. More than that what are you doing? Mesh networking like ZeroTier? iptables on every machine? It just seems like a lot more work than setting up a VPC.

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

Re: An engineer’s guide to cloud capacity planning

#26

Post by rescbr »

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

There's IPsec, although you are now trading VPC costs with sysadmin overhead costs.

Re: An engineer’s guide to cloud capacity planning

#28

Post by tyingq »

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

Ovh might be good cheap alternative if you have that need. They have a virtual rack product that's much closer to a VPC.

Re: An engineer’s guide to cloud capacity planning

#29

Post by lostcolony »

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?

Depends what happens as to whether it's a problem or not.

Maybe it fails to handle the load, the users get a "failure to authenticate" message or similar, and they try again. If their peaks are really sharp and short, that's probably just fine, because that second attempt almost invariably works.

Re: An engineer’s guide to cloud capacity planning

#30

Post by ryanmarsh »

jorgec wrote: post #27
ryanmarsh wrote: post #11

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

Serverless means to pay somebody for runs the server. Serverless is more server and its funny.

Seriously it is a terrible name. It seems to have stuck though.
Post reply on HN