|
|
|
|
|
|
by ipsun4
2361 days ago
|
|
|
That's all fine if you stay stateless. Once a well-meaning developer introduces local application state into your web app or adds a feature that locks your database, your web server is no longer "embarrassingly parallelizable". This doesn't even start to handle issues you get when you use a single-threaded langugage that cannot handle multitasking well. Sidekiq makes money purely because Ruby is single threaded, and its thread will lock if you give it a task that takes too long. The microservices movement seems to be a misguided reaction to these self-imposed issues where instead of handling proper task management on a process level or with async/concurrency, functionality is split between servers, codebases and infrastructure. This problem was solved with Erlang decades ago with the actor model and supervision, and newer BEAM languages like Elixir and LFE are a pleasure to work in. You even have this model and concurrency ported to JVM with Akka, C++ with CAF. Granted, the Actor model and the field of concurrency as a whole is solving the problem of enforcing statelessness in a way such that tasks can be efficiently distributed multiple cores, and that no single task locks up your machine for too long. |
|
|
And this would break the minute you have more than one web server. How many websites of any consequence are running on only one web server?
Having server side session state that can be shared across servers is a solved problem as is having a load balancer that handles “sticky sessions”. I’m not saying either is a good idea.
Also if you are “locking your database” even if you use a faster runtime, you’re just delaying the inevitable of your scaling limits.