This should have been a VM with a basic server and socat’ing the vsocket. I don’t know why so much space was dedicated to unrelated topics. Also zero qualifications or benchmarks for “fast” compared to tcp/virtio.
Author says “no ssh keys” when ssh is an orthogonal concept. sshd can listen on a vsock interface, it’s not specific to tcp/ip.
From the “Under the hood” section, which should be the part actually about vsock:
> I haven’t delved into the low-level system API for vsocks, as frameworks typically abstract this away.
Changing transports means if you want to move your grpc server process to a different box you now have new runtime configuration to implement/support and new performance characteristics to test.
I can see some of the security benefits if you are running on one host, but I also don't buy the advantages highlighted at the end of the article about using many different OS's and language environments on a single host. Seems like enabling and micro-optimising chaos instead of trying to tame it.
Particularly in the ops demo: Statically linking a C++ grpc binary, and standardising on host OS and gcc-toolset, doesn't seem that hard. On the other hand, if you're using e.g. a python rpc server are you even going to be able to feel the impact of switching to vsock?
I think the use of Bazel and gRPC in the article distracts from understanding how vsock works. I found this article[1] much more approachable.
[1]: https://medium.com/@F.DL/understanding-vsock-684016cf0eb0