5 ms·

Stateful: you have one web server! Stateless: you grow to require tens of servers or more, horizontal scalability is much cheaper than vertical, look to softwa

Stateful: you have one web server! Stateless: you grow to require tens of servers or more, horizontal scalability is much cheaper than vertical, look to software solutions to help slow expenses, move to NoSQL clustered DBs like Riak, Casandra, Hadoop, etc. 1-2 engineers can still run the whole show, cloud services, SaaS and PaaS are employed. Stateful: you run thousands of servers, having since brought many services back in-house. Many if not most are your own metal, with dedicated staff. Looking to slow power bills and space requirements, you look once again at software solutions. If you stay at the same growing company long enough, what's old will be new again.

statictype 11y ago
I think this would depend on your specific use case. If you're app is basically managing data (managing bookmarks, note taking, etc...) then a stateless architecture makes sense If your app is reacting to data in real-time to do some work (monitoring system, chat system, sending alerts on conditions) then using a statefull service makes total sense.
- jkarneges 11y ago
  For some use cases it does make sense, but even realtime/push systems can be made relatively stateless by isolating the stateful parts (e.g. into a message broker). The way I see it, nothing we design is truly stateless. There are stateful pieces everywhere (such as TCP, beneath HTTP). What we can do is minimize the effects that the stateful pieces may have on other parts of the system.
ousta 11y ago
quite frankly I never understood the craze most of the companies had with stateless services. For the last 7 years we moved away from statefull to stateless without any aftertought just because it was what everyone was doing even tho sometimes it just didn't make sense to design something stateless. In terms of pure design this was always akward. I understand why it makes sense in some cases I just don't understand why it became the new black. If someone has an answer to that, ill be happy to hear
- acjohnson55 11y ago
  Stateless services have some huge advantages, analogous to pure functional programming, especially when you truly commit to purity. The surface area for verfication and optimization is far more manageable, without having to worry about an internal state space. There's a dead-simple horizontal scalability story and reliability isn't much of a concern due to the fungibility of individual instances. Any real service must, of course, have state somewhere. I've had a lot of success being very intentional about factoring state into the smallest possible interfaces, ideally contained in well understood products like databases. Much like pure functional programming, it's not necessarily easy to go truly stateless. I've plenty of "RESTful" architectures get bogged down in the complications seemingly harmless stateful optimizations like caching layers, often to cover up poor performance of runtimes like Ruby and Python. It's very tempting to take a couple shortcuts and end up with the worst of both worlds. Of course, stateless isn't always the best way to go, especially once you start getting to the exotic territory inhabited by the examples in the article. I think for 99% of us, those are problems we'll never experience. I'd be interested in seeing a case where statefulness really let someone down, who wasn't at Facebook/Twitter/Google scale.
- curryst 11y ago
  I think it's tied to the rise of RESTful services. RESTful APIs lead to people getting used to thinking and working in stateless architectures, and it became the thing to do. If your API is stateless, why make the rest stateful? And stateful APIs can be... difficult to deal with, having to handle a lot more in your HTTP client than you do with a simple REST endpoint. I also think open source has had an impact here. A lot of open source stuff is designed to have a simplistic architecture, since the users tend to be unwilling to start up 4 servers to run an application (whether it's a business that doesn't like the complexity, or a user who lacks the resources). That drives open source toward stateless services, and open source often defines what's "popular".

statictype 11y ago

I think this would depend on your specific use case. If you're app is basically managing data (managing bookmarks, note taking, etc...) then a stateless architecture makes sense If your app is reacting to data in real-time to do some work (monitoring system, chat system, sending alerts on conditions) then using a statefull service makes total sense.

jkarneges 11y ago
For some use cases it does make sense, but even realtime/push systems can be made relatively stateless by isolating the stateful parts (e.g. into a message broker). The way I see it, nothing we design is truly stateless. There are stateful pieces everywhere (such as TCP, beneath HTTP). What we can do is minimize the effects that the stateful pieces may have on other parts of the system.

ousta 11y ago

quite frankly I never understood the craze most of the companies had with stateless services. For the last 7 years we moved away from statefull to stateless without any aftertought just because it was what everyone was doing even tho sometimes it just didn't make sense to design something stateless. In terms of pure design this was always akward. I understand why it makes sense in some cases I just don't understand why it became the new black. If someone has an answer to that, ill be happy to hear

acjohnson55 11y ago
Stateless services have some huge advantages, analogous to pure functional programming, especially when you truly commit to purity. The surface area for verfication and optimization is far more manageable, without having to worry about an internal state space. There's a dead-simple horizontal scalability story and reliability isn't much of a concern due to the fungibility of individual instances. Any real service must, of course, have state somewhere. I've had a lot of success being very intentional about factoring state into the smallest possible interfaces, ideally contained in well understood products like databases. Much like pure functional programming, it's not necessarily easy to go truly stateless. I've plenty of "RESTful" architectures get bogged down in the complications seemingly harmless stateful optimizations like caching layers, often to cover up poor performance of runtimes like Ruby and Python. It's very tempting to take a couple shortcuts and end up with the worst of both worlds. Of course, stateless isn't always the best way to go, especially once you start getting to the exotic territory inhabited by the examples in the article. I think for 99% of us, those are problems we'll never experience. I'd be interested in seeing a case where statefulness really let someone down, who wasn't at Facebook/Twitter/Google scale.
curryst 11y ago
I think it's tied to the rise of RESTful services. RESTful APIs lead to people getting used to thinking and working in stateless architectures, and it became the thing to do. If your API is stateless, why make the rest stateful? And stateful APIs can be... difficult to deal with, having to handle a lot more in your HTTP client than you do with a simple REST endpoint. I also think open source has had an impact here. A lot of open source stuff is designed to have a simplistic architecture, since the users tend to be unwilling to start up 4 servers to run an application (whether it's a business that doesn't like the complexity, or a user who lacks the resources). That drives open source toward stateless services, and open source often defines what's "popular".