I’m currently evaluating options to move our multi region microservices platform to a service mesh. We’re currently hosted in kubernetes in 5 regions and each service talk to each other through distinct ingress per service and per region. The 5 regions network is peered together so services from regionA can talk to regionB through its ingress without a problem.
To discover the endpoints, we currently use Eureka in a central region where all the services from all the regions register to.
Now, we have some special business requirements that force us to choose the region of an application based on 2 characteristics :
- The client’s organization ID (the 5 regions are data resident, but we also support cross-region talk but only for some organization. This info on which allowed region per organization is stored in a global service)
- The service name (some services are global, like the one storing the map of organization->region(s))
This logic is currently shared in a library in Java, but since we’re onboarding golang services, we’d like to generalize this at the service mesh level, and gain the other goodies that istio brings to the table.
I’ve read a lot and from what I’ve gathered, a custom wasm service + wasm extension, combined with virtual services could give me what I want. The wasm service would be responsible to hold a cache of the mapping of organization ID → region and the wasm extension would be responsible to extract the organization ID, match it with the cache, and apply the routing rules based on the result.
Is it something realistic to do? Do I have any other option than this?