I'm working on a Web API that requires inter-instance Remote Procedure Calls (RPC) to share state among all instances. While I recognize solutions like Azure Service Bus exist, I want to avoid being locked into a specific cloud provider's technology. My backup plan is to use database polling, but I'm not a fan of that approach due to the additional load it places on the database server and the latency involved. Is there a way for my API instances to discover each other behind the load balancer and communicate effectively?
3 Answers
You might want to explore Dapr. It's a library designed to abstract the infrastructure from your application, which could help with your messaging needs. It allows you to implement a message queue or publish-subscribe system while pointing to different backends, whether it's a managed service or self-hosted open source solutions.
Just a heads-up, Azure App Services sometimes perform app pool recycles, which can lead to the loss of in-memory state for your applications. This is something to consider when thinking about how your instances will communicate after such an event.
Yeah, I'm aware of that! I just need to ensure they can find each other again after they're back online.
If you're looking for solutions that aren't tied to a specific provider, have you considered using Kafka or RabbitMQ? They can be a bit complex, but they are good options for handling these kinds of communication needs. If you really want to avoid vendor lock-in for this functionality, you might also think about self-hosting or finding a custom solution that fits your requirements. It could also be useful to set build flags for different environments, allowing for platform-specific builds—just a thought!
I want to minimize reliance on extra external services, though. Setting up another service seems like it would waste resources and increase costs, which I'm trying to avoid.
Again, I'm aiming to be resource-conscious. If there's a way for my instances to communicate directly without a middleman, that would be ideal.