3 ms·
Nobody said that calls between microservices have to be done via RPCs. I use a framework at Google that is microservice-based, and allows for composition of mi
by QuercusMax 10y ago
Nobody said that calls between microservices have to be done via RPCs.
I use a framework at Google that is microservice-based, and allows for composition of microservices into an assembly. Within an assembly, calls between services are done in-process; if you are calling a service in a different assembly, it has to make an RPC.
The mechanics of whether it's a local call or an RPC are all handled at the framework leve. This makes splitting a service into its own assembly a simple task (don't have to update any code, just configuration; this can be managed by SREs).
- wcummings 10y ago>I use a framework at Google that is microservice-based, and allows for composition of microservices into an assembly. Within an assembly, calls between services are done in-process; if you are calling a service in a different assembly, it has to make an RPC. Sounds a lot like OTP. In Java-land, you could also just have your client and service use the same interface. Just inject different implementations for local and remote.
- twic 10y agoRight, then you can have some supporting code automatically handle the remoting. Once you've gone to the trouble of automatically generating the glue between the local interface and the remote object, it becomes simple to interpose further useful things - security checks, transactions if you're using a relational database, and so on. You can even have the glue code lazily instantiate the service components, so you don't need to actually load them until a client makes a call. You'd want a cool name for it, though. Extreme Java Binding? Enhanced Jet Bus? Excellent Joy Bringer?