Says it is fast, but presents zero benchmarks to demonstrate it is actually fast or even “faster”. It is shameful to make up adjectives just to sound cool.
My standard solution for doing stuff in a VM is to prepare some kind of storage with downloads, batch jobs, etc. Control it over serial and have the last step be a shutdown. Artifacts can then be found in one of the storage units.
Given how slow protobufs and grpc is, I wonder if the socket transport would ever be the bottleneck to throughput here.
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?
This is interesting. I wasn't familiar with 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
disappointed to find out "nbd" doesn't mean "No Big Deal"
This is a weird article. It’s titled “how to use vsock” but 95% is how to set up Bazel, gRPC, and building a C++ project. And then 5% is a link to an off-site Twitter thread of screenshots for setting up a Linux VM image and running that in qemu.
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.