I'm amazed that when talking about RPC that schemas never came up. Schemas are probably my favorite part of RPCs. Let's say you have multiple services that need

I'm amazed that when talking about RPC that schemas never came up. Schemas are probably my favorite part of RPCs. Let's say you have multiple services that need to communicate, but testing interoperability between the services is tricky. RPC type enforced schemas (interface definition language (IDL)) are great for this because the schemas provide guarantees that the services are communicating correctly. If a system starts seeing exceptions about IDL/schema errors, then you know right away that things are broken. Writing tests that can assume that RPC method calls will be enforced. Another thing that struck me strange about the article is showing the RPC urls. When I was using Thrift, I never needed to think about URLs. I just needed to make sure that I was calling methods correctly. I think RPCs are a good fit for organizations looking for a way for their service based architecture to communicate. I don't really like exposing RPCs as a public API or for web clients to interact with.