3 ms·

Reminds me of the talk "Building Scalable Stateful Services" by Caitie McCaffrey about stateful app servers for Microsoft Halo (the multiplayer shooter game). S

Reminds me of the talk "Building Scalable Stateful Services" by Caitie McCaffrey about stateful app servers for Microsoft Halo (the multiplayer shooter game). She explained that stateless app servers are wasteful and the user's data should be cached in an instance and routing should be sticky to always reach that instance, and once it is warm performance is good. If the instance goes down, the user data will get loaded into another instance and will get stickied there. http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html http://highscalability.com/blog/2015/10/12/making-the-case-f... https://www.youtube.com/watch?v=H0i_bXKwujQ https://www.youtube.com/watch?v=H0i_bXKwujQ https://speakerdeck.com/caitiem20/building-scalable-stateful-services https://speakerdeck.com/caitiem20/building-scalable-stateful...

hinkley 7y ago
We are an all or nothing sort. If we use statefulness and sticky sessions we almost always tend to use it in a way where migration to another server is next to impossible. If we had better tools for the moderate position then life would probably be easier than at the extremes. While the idea of migration is useful for resilience in the face of hardware failure, it’s more attractive from a standpoint of elastic scalability. But. We are still living in a bubble where we believe that cloud providers aren’t going to oversubscribe their hardware the way ISPs have been doing for decades. As the ratio of private server rooms declines, that bubble starts to wear thin.
- stcredzero 7y ago
  If we use statefulness and sticky sessions we almost always tend to use it in a way where migration to another server is next to impossible. I'm developing a server cluster with statefulness and "sticky sessions" (1) for a multiplayer game. Migration to another server is a feature I'm working on, and already have prototyped in demo form. (1) -- "Sticky sessions" are actually Player agents which live in a particular server.
- Johnny555 7y ago
  We are still living in a bubble where we believe that cloud providers aren’t going to oversubscribe their hardware AWS doesn't oversubscribe their main class of cloud servers, but they will sell you a cheaper t-series if you're willing to accept throttling under heavy CPU use. They used to have "noisy neighbor" issues with some of their older instance types where another server on the same physical hardware could monopolize the disk/network bandwidth (but not the CPU), but they've resolved that now, every server can use it's published resources (except for network which can burst up on 10 Gig on some instances types, but sustained except on large instance types that can sustain 10Gig) They've built their business model on selling dedicated resources, and I don't see that changing.

hinkley 7y ago

We are an all or nothing sort. If we use statefulness and sticky sessions we almost always tend to use it in a way where migration to another server is next to impossible. If we had better tools for the moderate position then life would probably be easier than at the extremes. While the idea of migration is useful for resilience in the face of hardware failure, it’s more attractive from a standpoint of elastic scalability. But. We are still living in a bubble where we believe that cloud providers aren’t going to oversubscribe their hardware the way ISPs have been doing for decades. As the ratio of private server rooms declines, that bubble starts to wear thin.

stcredzero 7y ago
If we use statefulness and sticky sessions we almost always tend to use it in a way where migration to another server is next to impossible. I'm developing a server cluster with statefulness and "sticky sessions" (1) for a multiplayer game. Migration to another server is a feature I'm working on, and already have prototyped in demo form. (1) -- "Sticky sessions" are actually Player agents which live in a particular server.
Johnny555 7y ago
We are still living in a bubble where we believe that cloud providers aren’t going to oversubscribe their hardware AWS doesn't oversubscribe their main class of cloud servers, but they will sell you a cheaper t-series if you're willing to accept throttling under heavy CPU use. They used to have "noisy neighbor" issues with some of their older instance types where another server on the same physical hardware could monopolize the disk/network bandwidth (but not the CPU), but they've resolved that now, every server can use it's published resources (except for network which can burst up on 10 Gig on some instances types, but sustained except on large instance types that can sustain 10Gig) They've built their business model on selling dedicated resources, and I don't see that changing.