I have mixed feelings about the use of sidecar applications alongside a microservice. Sidecars were introduced by this blog post by Netflix in 2014. A sidecar is an independently running process that wraps infrastructure services APIs behind a more “portable” or language-neutral API (e.g., RESTful endpoints) that the microserver can invoke. The idea is that the infrastructure service’s native API may not have a binding for the programming language of the microservice. For example, AWS provides SDKs for Java, .Net, Node.js, PHP, Python, Ruby, Go, and C++. What if your service is written in Lua?
The architecture of sidecars may be applicable for any situation where there is impedance between programming languages. The idea is that if the API of the sidecar is language neutral, then you wouldn’t need to provide a separate wrapper for each programming language you want to use to write the microservice.
Is this a heavy-handed approach? Even if a binary interface (e.g., one based on Thrift) is published by the sidecar, it can still be fairly costly for the microservice to use. On the other hand, the cost is probably not any higher than one microservice calling another one, which is usually accomplish via RESTful APIs. Event-driven services (e.g., pub-sub via Kafka) also incur network overhead due to the extra hops.
I am mystified why the sidecar needs to be one-per-microservice. How about a cluster-wide microservice, say, Sidecar Service, which is shared by all microservices? The Sidecar Service’s API can take a context argument so it can differentiate calls from one microservice from another. Of course, this Sidecar Service had better be reliable, since all other services depend on it. But that is not much different than the requirement for almost any microservice.
Cloud providers would do everyone a great service if they provided language-neutral (e.g., REST) interfaces for all of their APIs. Language-specific SDKs are still useful, but at least we (cloud customers) no longer each have to invent our own sidecar applications that do the same thing. Performance of language-neutral interfaces should not be an issue: SDKs are not necessary more efficient, since under the covers most API calls from SDKs are translated into network interactions with the cloud provider anyway.