4 ms·
This doesn't capture the basics of capacity planning, which really started in the 1980's with roll-out of bank ATM networks. The first step is not to use techn
by w10-1 3y ago
This doesn't capture the basics of capacity planning, which really started in the 1980's with roll-out of bank ATM networks.
The first step is not to use technical measures like throughput or response time, but to use business units (like ATM account balance checks or withdrawals), so you can forecast capacity according to business plans.
In modern web apps, that's served by issuing a transaction id to user actions, and tracing that through all the systems and sub-systems required to service that transaction. That's your data plane.
Unfortunately, the next step of applying queuing theory to your software model is almost moot in a multi-core, multi-machine world with GPU's on a modern memory bus, because the model cannot be both abstract and accurate.
But the real problem is cultural: IT is willing to set targets for measures it can own and manipulate, but it's much, much less willing to commit to business unit measures that senior management can see clearly. Indeed, one of the best ways to understand how IT fits into the organization is to ask what's being measured.
- davecb 3y agoI was attracted to my current employer when the ops director said almost exactly what you did in your last sentence. He wanted our dev/ops arm to be numerate and to work in dollars and TPS. We actually do capacity planning in dollars to this day, and did do queuing models of both batch and multi-core, multi-machine transaction processing.
- eastbound 3y agoIncredible. Imaging for my startup how much it would take to translate potential features into dollars. “We can take this market of $55bn, it would take 70 features and 12 marketings, that’s 100 million per feature, but you only get it if the market develops accordingly.” The simple fact that a large company is able to liquefy a non-linear large-blocks market into dollar amounts that you can measure, is the ultimate dream of any 1800 economist.
- losteric 3y agoI understood the prior post differently, in that they tied capacity planning to biz metrics rather than TPS. For example, businesses in HR might have metrics like average case correspondence count, open rate per day, idle status, etc. The dev team would commit to certain of these metrics, and optimize both costs and these meteics. This, to me, would signal an IT organization with high status (autonomy delegated to tech leaders). Whereas a different company might have IT committed to X TPS without the ownership of business metrics