3 ms·

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 wit

by 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".

by ousta 11y ago

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".