6 ms·

"AWS is expensive, as soon as we start an instance, we’re billed for the entire hour, even if we only need to run a 2 minute test on it." What you really neede

by UK-AL 13y ago

"AWS is expensive, as soon as we start an instance, we’re billed for the entire hour, even if we only need to run a 2 minute test on it." What you really needed to do was design algorithm that keeps machines running over period in time, according to a general trend. Not shutdown, and instantly bootup for every customer deciding to run tests.

giulianob 13y ago
If it takes people to code it, it's still part of the expenses for running in that environment.
- mildtrepidation 13y ago
  The relevant and important difference being that this is a one-time expense. It contributes almost nothing to the cost unless you do this then immediately drop the platform.
aquark 13y ago
Except, if you are running customer supplied code on the instance then you've made the sandboxing problem that much more difficult. I'd much sooner have a clean VM to run my tests on than have to think about the ways the previous user might have left things in an insecure state.
- defied 13y ago
  Exactly, now we guarantee a pristine VM for every single test, something which was not possible with our setup on EC2.
  - thezilch 13y ago
    Something completely possible with mounting a new EBS volume with a pristine image or simply instructing to replace the instances current volume...
    - defied 13y ago
      As far as I know you have to stop the instance to mount a fresh EBS volume, which means as soon as you start up the instance with the new volume you're paying for another full hour again.
    - asdasf 13y ago
      You pay for another hour every time you do that, that was the point.
- kisielk 13y ago
  This can solved by containerization.
lotsofcows 13y ago
What you really needed to do was move to Google who bill by the minute. Not a Google shill by the way - I don't have a preference yet. However, for that particular complaint, Google has the solution.
- octix 13y ago
  I think you get billed for at least 10min... still better than 1 hour though.
  - linker3000 13y ago
    When/if Amazon notice significant churn heading Google's way, I expect one of the things they'll look at is their billing time granularity.
  - Florin_Andrei 13y ago
    Right, 10 min upfront, then by the minute. The last minute chunk is discarded from billing if it was actually used less than 15 sec. Or so I remember from reading the ToS yesterday. The command-line cloud utility is so much easier than Amazon's. Everything is in one place. ssh keys are managed automatically. In less than 1 hour I was able to do everything with Google, whereas it took me a couple days to feel comfortable with AWS.
- tstrimple 13y ago
  Azure bills by the minute as well. http://weblogs.asp.net/scottgu/archive/2013/06/03/windows-azure-announcing-new-dev-test-offering-biztalk-services-ssl-support-with-web-sites-ad-improvements-per-minute-billing.aspx http://weblogs.asp.net/scottgu/archive/2013/06/03/windows-az...
  - pyrocat 13y ago
    True, but it doesn't always play well with non-msft tech stacks.
    - 13y ago
caw 13y ago
I'm glad I'm not the only person that thought this, because I'm a HPC batch admin and that sort of machine packing is just what I do. I'm glad they found a solution which seems to work out really well for their use case. Changing the algorithm to use the machine for an hour would imply that some tests may wait to be run, and that could be a bad thing for TestingBot (I'm not sure what their SLA is). Going to their own "cloud" though will require them to either overbuy capacity or eventually make a push to increase utilization, so they may end up making that algo anyhow.
- hhw 13y ago
  The reality is that once you reach a reasonable level of scale (multiple physical machines), the cost savings from going to your own cloud will easily allow you to afford that extra capacity and then some.
  - caw 13y ago
    I disagree that it's the only reality. Definitely there is a scale where paying a sysadmin makes more sense than paying a provider for their sysadmin skills. There is another situation, which I would argue is the "enterprise" situation, where you will want to pay your programmers to make the changes because they're fixed overhead rather than capital expenditures. This scenario comes because of an internal push to save money (adding significant capacity costs too much), or because adding any sort of capacity increases operational complexity more than it increases code complexity. It's a much larger scale than where TestingBot is at, but a problem they probably hope to encounter one day.

by UK-AL 13y ago

giulianob 13y ago

If it takes people to code it, it's still part of the expenses for running in that environment.

mildtrepidation 13y ago
The relevant and important difference being that this is a one-time expense. It contributes almost nothing to the cost unless you do this then immediately drop the platform.

aquark 13y ago

Except, if you are running customer supplied code on the instance then you've made the sandboxing problem that much more difficult. I'd much sooner have a clean VM to run my tests on than have to think about the ways the previous user might have left things in an insecure state.

defied 13y ago
Exactly, now we guarantee a pristine VM for every single test, something which was not possible with our setup on EC2.
- thezilch 13y ago
  Something completely possible with mounting a new EBS volume with a pristine image or simply instructing to replace the instances current volume...
  - defied 13y ago
    As far as I know you have to stop the instance to mount a fresh EBS volume, which means as soon as you start up the instance with the new volume you're paying for another full hour again.
  - asdasf 13y ago
    You pay for another hour every time you do that, that was the point.
kisielk 13y ago
This can solved by containerization.

lotsofcows 13y ago

What you really needed to do was move to Google who bill by the minute. Not a Google shill by the way - I don't have a preference yet. However, for that particular complaint, Google has the solution.

octix 13y ago
I think you get billed for at least 10min... still better than 1 hour though.
- linker3000 13y ago
  When/if Amazon notice significant churn heading Google's way, I expect one of the things they'll look at is their billing time granularity.
- Florin_Andrei 13y ago
  Right, 10 min upfront, then by the minute. The last minute chunk is discarded from billing if it was actually used less than 15 sec. Or so I remember from reading the ToS yesterday. The command-line cloud utility is so much easier than Amazon's. Everything is in one place. ssh keys are managed automatically. In less than 1 hour I was able to do everything with Google, whereas it took me a couple days to feel comfortable with AWS.
tstrimple 13y ago
Azure bills by the minute as well. http://weblogs.asp.net/scottgu/archive/2013/06/03/windows-azure-announcing-new-dev-test-offering-biztalk-services-ssl-support-with-web-sites-ad-improvements-per-minute-billing.aspx http://weblogs.asp.net/scottgu/archive/2013/06/03/windows-az...
- pyrocat 13y ago
  True, but it doesn't always play well with non-msft tech stacks.
  - 13y ago

caw 13y ago

I'm glad I'm not the only person that thought this, because I'm a HPC batch admin and that sort of machine packing is just what I do. I'm glad they found a solution which seems to work out really well for their use case. Changing the algorithm to use the machine for an hour would imply that some tests may wait to be run, and that could be a bad thing for TestingBot (I'm not sure what their SLA is). Going to their own "cloud" though will require them to either overbuy capacity or eventually make a push to increase utilization, so they may end up making that algo anyhow.

hhw 13y ago
The reality is that once you reach a reasonable level of scale (multiple physical machines), the cost savings from going to your own cloud will easily allow you to afford that extra capacity and then some.
- caw 13y ago
  I disagree that it's the only reality. Definitely there is a scale where paying a sysadmin makes more sense than paying a provider for their sysadmin skills. There is another situation, which I would argue is the "enterprise" situation, where you will want to pay your programmers to make the changes because they're fixed overhead rather than capital expenditures. This scenario comes because of an internal push to save money (adding significant capacity costs too much), or because adding any sort of capacity increases operational complexity more than it increases code complexity. It's a much larger scale than where TestingBot is at, but a problem they probably hope to encounter one day.