On 31/10/2022 15:07, Tobias Urdin wrote:
Interesting topic, we use Redis because frankly we see that as the most logical choice due to the complexity of others.
Interesting now one's mileage varies :-)
You might have seen my thread about investigating replacing RabbitMQ with NATS; our plan is to then also investigate getting Tooz and oslo.cache using the Jetstream Key-Value feature.
That sounds really interesting, I shall follow that discussion then. If one tool, e.g. NATS in your case, could cover more than one communication use case, e.g. (async) messaging and distributed locking, this would reduce the number of different components required to assemble a cloud, thus reducing the complexity. Even if there was more than once instance of that software required. As I was also arguing that adding more and more implementations and "ways" to do things, does neither help the operators nor the developers. To me, software developers benefit from clear abstractions for such cross-cutting concerns as messaging or coordination. While e.g. tooz already aims to be such an abstraction, when deploying OpenStack or operating a cloud things can look so vastly different. No coordination at all, different drivers with different features and inherently different guarantees and behavior in case of problems. Discussing broadly, and then agreeing not only on a common library and its interface, but also on an implementation to me is not inflexible, but makes sense to keep the complexity manageable. It happened with MySQL/MariaDB as db engine and actually also with AMQP as messaging protocol (including it's paradigms). It's progress to simply revisit such decisions and conventions over time. Regards Christian