An engineer’s guide to cloud capacity planning
increment.com
An engineer’s guide to cloud capacity planning
1–10 of 36 posts
Re: An engineer’s guide to cloud capacity planning
#2This seems more about capacity planning your application when running in the cloud.
I was hoping for some insight when you're hosting your own private cloud, that seems quite a bit more tricky. It's easy to prepare to scale up/down your deployment when all the hardware is already there, but when you're the one running the actual cloud and need to do the same, you can't just do an API call and suddenly have another 100 U of servers and switches racked, cabled and provisioned.
Still a nice article though!
Re: An engineer’s guide to cloud capacity planning
#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.
Re: An engineer’s guide to cloud capacity planning
#4This seems more about capacity planning your application when running in the cloud. I was hoping for some insight when you're hosting your own private cloud, that seems quite a bit more tricky. It's easy to prepare to scale up/down your deployment when all the hardware is already there, but when you're the one running the actual cloud and need to do the same, you can't just do an API call and suddenly have another 10…
So Nutanix and hypergrid are trying to address this, though I’m not sure how well they succeed, but the payment model of hypergrid is enticing: they deploy a cluster for you, and you only pay for what you use, so if you want to have flex scaling you can do that... I’d really look at their offering if you’re looking for a solution for on prem elasticity with a lower cost to enter...
I am not associated with either of these companies in anyway other than looking for a solution to the same problem you mentioned.
Re: An engineer’s guide to cloud capacity planning
#5> 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...
Re: An engineer’s guide to cloud capacity planning
#6COMPOSITE HACKS
• If Truly you Are In Need Of A PROFESSIONAL LEGIT HACKER Who Will Get Your Job Done Efficiently With Swift Response, Congratulations, You Have Met the Right HACKERS
We are a group Of Professional HACKERS , a product of the coming together of Legit Hackers from the Dark-Web, (pentaguard ,CyberBerkut , RedHack , Black Hat, Anonymous ) we have been existing for over 12 years, our system is a very loose and decentralized command structure that operates on ideas rather than directives. you can also find us on the dark web at :http://my7cic3ax7oznkvu.onion (Tor Only)
Frankly speaking, I always give a 100% guarantee on any job i am been asked to do, because we have always been successful in Almost all our jobs for over 12years and our clients can testify to that . To hack anything needs time though, but we can provide a swift response to your job depending on how fast and urgent you need. Time also depends on what exactly you want to hack and how serious you are. Enough time with social engineering is required for hacking. So if you want to bind us in a short time, then just don't contact us because We can't hack within one hour,sorry. Basically, time depends on your luck. If its good luck, then it is possible to hack within one hour but, if its in the other way round, it would take few hours. I have seen FAKE HACKERS claiming they can hack in 1hr , but there is no REAL HACKER who can say this (AVOID THEM).
Please Note : we have only one contact email : compositehacks@gmail.com we will be happy to have you join over 2000 satisfied clients around the world to use our services. We provide prove of job before payment We offer services like:
Hacking Whatsapp account giving you access to the person's whatsapp messages and history .
You can check out our Latest Whatsapp Hack video https://www.youtube.com/watch?v=7_LtFUVMcxY
Initiating Bank Wire Transfers at a resonable fee and completely untracable .
Hacking any smart phone giving you access to all activities on the phone like , text messages , call logs , instant messenger chats and other information.(you can use this to spy on your spouse to know if he/she is cheating on you)
Hacking Facebook , Instagram , Twitter and every other social network Accounts.
Hacking Websites to deface , retrive information, edit information or give you admin access .
Hacking into school's websites (server) to change grades without any trace . .
Hacking any email service provider like Gmail , Yahoo, Comcast , Aol , Hotmail any others .
Location Tracking.
Hacking and selling credit cards , amazon , walmart , paypal , bank logs .
Selling of untracable phones (even the pentagon can not track our phones). .
Selling of Tutorial packs for Beginner Ethical Hackers
You can also contact us for other Cyber Attacks And Hijackings, we do almost All.
Contact us: compositehacks@gmail.com
Re: An engineer’s guide to cloud capacity planning
#7> 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...
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.
Re: An engineer’s guide to cloud capacity planning
#8Earlier 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...
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?
Re: An engineer’s guide to cloud capacity planning
#9This seems more about capacity planning your application when running in the cloud. I was hoping for some insight when you're hosting your own private cloud, that seems quite a bit more tricky. It's easy to prepare to scale up/down your deployment when all the hardware is already there, but when you're the one running the actual cloud and need to do the same, you can't just do an API call and suddenly have another 10…
Well if you want to service huge spikes you can run a hybrid env. with on prem. handling base load and cloud absorbing spikes or you have to bite the bullet and overprovision on prem/private cloud based on you specific business req.
Re: An engineer’s guide to cloud capacity planning
#10If you are a small startup and do not have strict regulatory or other special req. run on something simple like DO, Vultr etc. and save yourself pain and $.