Take a scalable infrastructure like the one I'm working with. In my case, the amount of work we can crank out scales well with the number of processing nodes we have running. We have some in-house capacity and are working to use exactly these kinds of services for demand that exceeds our in-house capacity.
When we need it, we deploy a bunch of processing nodes to a Cloud service like that. Once we have deployment automated, it should be a matter of telling the system "I need 20 new nodes", having it spin up 20 new instances, tweak names as needed, and start chewing away. Once the project is done, we turn off those nodes and go on our merry way.
Due to the cost-factors involved (in our case, it won't be for everyone), if this happens often enough it's a good sign that we need to scale our internal infrastructure out a bit more.
There will certainly be a "base load" that we keep running all the time, and for that we like to host that in-house. We'll probably need some always-on instances in the utility-cloud for certain application and data-locality reasons, but those should be in the single digits. Those few servers should be able to support up to hundreds of short-duration processing nodes.
In months where we never need to use the 'surge' capability, we'll still have to pay for the base-load servers we need to keep running over there. However, for other months when we have more work than we know what to do with, we could have hundreds of machines going at any given time.
As for calculations, I've done just that. It requires a spreadsheet and knowing your environment very well. I knew how much data we generally take in a month (the transfer-in bandwidth), how many times the data is read as part of our processing methods (the storage transfer rates), what the growth factor is for processed data versus source data (data storage costs), as well as an estimate as to what percentage during a month are we actually doing work (the hours used). If you don't have that, it's hard to estimate billing accurately.
I was able to take what we know about our private environment and build a sheet that predicts what something like AWS would cost versus rolling our own in a colo. It was very informative. In our specific case the cloud vendor we were considering represented anywhere from a 2x to 10x increase in costs versus doing it all ourselves. This was highly useful for upper management, which had been considering going all-in with that cloud vendor.
We ended up going with a hybrid approach, since the surge capability the cloud represents is highly useful. It sucks to tell clients we can't meet their deadlines because we've taken on too much work. If anything, the cloud capability can tide us over until we can get infrastructure upgrades in place for our in-house plant.
In the given example cpu_period is 20,000 microseconds, cpu_quota 10,000 microseconds.
For each 20,000μs period of time m1.low_cpu is permitted to use 10,000μs of processor time.
Source: I read the quoted text 3 times.
Best Answer
There are a few different methods to measure bandwidth over time. If you want something graphical and easy to read, you might want to look at
ntop:You can also track bandwidth with iptables pretty easily. You'll just need to set up some ACCEPT rules and then print the iptables rules to see the bandwidth add up. I wrote up a post about this a while back:
If you want to just check a few page loads or look at your instantaneous bandwidth usage, you can also use bwm-ng, iftop, and jnettop.