4 ms·

How we do it would be giving away the kitchen sink. There is no soft limit on how much you can scale. We attempt to distribute all yours apps as much as possib

How we do it would be giving away the kitchen sink. There is no soft limit on how much you can scale. We attempt to distribute all yours apps as much as possible to ensure there are enough resources for you to grow in to. If there is no more capacity on the host server for your instance(s), you are able to transparently migrate to one which does. This happens within 2 seconds.

mnutt 14y ago
It's a neat technology and I'm very interested in using it. It's almost a perfect fit for my business, which deals with serving traffic during email spikes. I think the questions are just around the economics to make sure you guys stick around and can continue to offer it. My initial thought was that being able to scale up and down so quickly would require you to have a lot of idle resources sitting around at any given time, both on individual hosts as well as across hosts.
- ColinHayhurst 14y ago
  Thanks. Fair point about whether we stick around: You'd expect me to say we intend to but the proof is in the pudding. We have a lot to do and long term vision. As for the economics a key point is that the resizing allows us/users to optimize much better the allocation of resources to what is needed
moe 14y ago
This happens within 2 seconds. I'm sorry but statements like that freak me out a bit. Do I get a warning when my instance is going to be migrated instead of resized, and an estimate of the downtime? Because unless you found a way to defy physics you are pretty surely not migrating e.g. a 4GB Ram/40GB disk instance in anywhere close to 2 seconds.
- devopstom 14y ago
  Actually.. If you had all of the instance data stored on a fast SAN, so that it was available to all of the hosts simultaneously (possible.) And you had an ultra-high speed interconnect (40Gbit Infiniband would do) between hosts, for sharing the memory state when you migrate.. 4GB of memory, at 40Gbit/s would be transferred in 0.8s. (assuming perfect throughput, all cows are spherical, etc..)
  - accountoftheday 14y ago
    Actually... you do not need that fast a network. You can converge state incrementally rather than transfer it in one go. Xen and VMware do this. Surely the cost of a fast SAN and interconnect would quickly outpace the (imho minor) savings from smaller memory allocations.
    - devopstom 14y ago
      Yeah, you can do that too..
deleted 14y ago
[deleted]
toomuchtodo 14y ago
So instead of telling us the limitations up front, we have to sign up for your service and stress test it ourselves to find out.
- batista 14y ago
  And this is different to any other services, like GAE, AWS, etc, how?
  - ceejayoz 14y ago
    One generally trusts Google and Amazon to have enough capacity more than one trusts a startup.
  - regularfry 14y ago
    At least with AWS, the model is relatively familiar, which makes the failure modes predictable. This seems to be breaking new ground, and is likely to fail in New and Interesting ways.

mnutt 14y ago

It's a neat technology and I'm very interested in using it. It's almost a perfect fit for my business, which deals with serving traffic during email spikes. I think the questions are just around the economics to make sure you guys stick around and can continue to offer it. My initial thought was that being able to scale up and down so quickly would require you to have a lot of idle resources sitting around at any given time, both on individual hosts as well as across hosts.

ColinHayhurst 14y ago
Thanks. Fair point about whether we stick around: You'd expect me to say we intend to but the proof is in the pudding. We have a lot to do and long term vision. As for the economics a key point is that the resizing allows us/users to optimize much better the allocation of resources to what is needed

moe 14y ago

This happens within 2 seconds. I'm sorry but statements like that freak me out a bit. Do I get a warning when my instance is going to be migrated instead of resized, and an estimate of the downtime? Because unless you found a way to defy physics you are pretty surely not migrating e.g. a 4GB Ram/40GB disk instance in anywhere close to 2 seconds.

devopstom 14y ago
Actually.. If you had all of the instance data stored on a fast SAN, so that it was available to all of the hosts simultaneously (possible.) And you had an ultra-high speed interconnect (40Gbit Infiniband would do) between hosts, for sharing the memory state when you migrate.. 4GB of memory, at 40Gbit/s would be transferred in 0.8s. (assuming perfect throughput, all cows are spherical, etc..)
- accountoftheday 14y ago
  Actually... you do not need that fast a network. You can converge state incrementally rather than transfer it in one go. Xen and VMware do this. Surely the cost of a fast SAN and interconnect would quickly outpace the (imho minor) savings from smaller memory allocations.
  - devopstom 14y ago
    Yeah, you can do that too..

deleted 14y ago

[deleted]

toomuchtodo 14y ago

So instead of telling us the limitations up front, we have to sign up for your service and stress test it ourselves to find out.

batista 14y ago
And this is different to any other services, like GAE, AWS, etc, how?
- ceejayoz 14y ago
  One generally trusts Google and Amazon to have enough capacity more than one trusts a startup.
- regularfry 14y ago
  At least with AWS, the model is relatively familiar, which makes the failure modes predictable. This seems to be breaking new ground, and is likely to fail in New and Interesting ways.