Investing in Isovalent(a16z.com)
a16z.com
Investing in Isovalent
https://a16z.com/2020/11/10/investing-in-isovalent/
20 comments
Had the same thought. Like “Boom,” it would be impressive to name your company “Insolvent.”
I'm responding here because your other posts remain dead despite vouching for them. I just wanted to say that your questions about sctb seemed reasonable to me, and yes, your comments for the last year (and probably more) have been high quality. I don't understand your relationship with dang, but without trying to pick a winner, I'll just suggest you not worry too much about it. Keep posting quality things, try to stay civil, and hopefully the rest will eventually work out.
I saw 'insolvent' on first pass and did a double take. Glad it's not just me!
I saw constant valence (e.g. electrons) but makes no sense to me still.
I saw Insolvent at first as well and figured it was a piece on contrarian investing.
If eBPF is new to you (it was to me), this article offers some useful context to help parse "eBPF brings to the Linux kernel what JavaScript brought to the browser" (which made me shudder at first): https://thenewstack.io/how-io_uring-and-ebpf-will-revolution...
There was also a more recent one on eBPF and Kubernetes which was an interesting read: https://thenewstack.io/ebpf-put-the-kubernetes-data-plane-in...
What do people think about this way to explain eBPF:
Microkernels were presented as the future in which fewer things would run in the kernel. Instead we've gone in the other direction in which more is running inside the kernel.
Monolithic kernel: the Network Device runs inside the kernel and the Packet Filter outside.
Microkernel: both the Network Device and Packet Filter run outside the kernel.
eBPF: both the Network Device and the Packet Filter run inside the kernel.
Microkernels were presented as the future in which fewer things would run in the kernel. Instead we've gone in the other direction in which more is running inside the kernel.
Monolithic kernel: the Network Device runs inside the kernel and the Packet Filter outside.
Microkernel: both the Network Device and Packet Filter run outside the kernel.
eBPF: both the Network Device and the Packet Filter run inside the kernel.
Yep, that seems pretty spot on. Not sure yet how I feel about allowing sandboxed user code in the kernel (my gut doesn't like the idea) but much smarter people than me seem to think it makes sense so I guess time will tell.
[deleted]
Another good way to get started is https://ebpf.io/. It features pointers that go beyond just networking and also cover usage of use cases involving tracing, profiling, security, ...
Note: the A16Z article is written by Martin Casado, now partner at A16Z. I met Martin at VMware in 2014-2016, where he was leading the SDN (Software Defined Networking) team after the company he co-founded, Nicira, was acquired by VMware in 2012. Martin also (co?)invented Openflow.
I didn't work closely with Martin, but I've noticed multiple times how good he is at vision, strategy, understanding tech and predicting where it's going. Not surprised he led the investment in Isovalent, which I believe is a very promising company.
I didn't work closely with Martin, but I've noticed multiple times how good he is at vision, strategy, understanding tech and predicting where it's going. Not surprised he led the investment in Isovalent, which I believe is a very promising company.
It's interesting to see, tbh we knew it was coming because Dan and Martin worked together before and Cilium is now baked into K8s in a number of places like GKE and Scaleway Kapsule. Although what I'm more interested in now is some user space networking like Snap from Google, that feels like it has a huge future https://research.google/pubs/pub48630/
Userspace networking had been around for quite a few years, yet didn't seem to have taken off, despite all the great benchmarks... I think the main blocker is that you cannot make apps use it without hacks. It looks like Snap requires a custom library that probably doesn't even have to implement BSD sockets, since that's something you don't have to care about at Google.
Some years ago I recall looking into this, and it looked kernel had limitations in higher speed ethernet (must had been 50GbE at the time), and it came down to single-threaded nature of the TCP/IP stack in the kernel at the time. So that's been one of the drivers for experiments in userspace. Looks like that might now be the case now [1], but if someone has more specific info I'd be quite curious to hear.
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...
Some years ago I recall looking into this, and it looked kernel had limitations in higher speed ethernet (must had been 50GbE at the time), and it came down to single-threaded nature of the TCP/IP stack in the kernel at the time. So that's been one of the drivers for experiments in userspace. Looks like that might now be the case now [1], but if someone has more specific info I'd be quite curious to hear.
[1]: https://www.phoronix.com/scan.php?page=news_item&px=Broadcom...
There have been a lot of advances to the point that the Linux kernel can handle ~100Gbps TCP streams via native socket API [0].
[0] https://netdevconf.info/0x14/session.html?talk-the-path-to-t...
[0] https://netdevconf.info/0x14/session.html?talk-the-path-to-t...
Is it accurate to say that eBPF can observe data at kernel level as what wireshark does for networking?
Yeah, with kprobes.
Yeah you are correct, but apart from networking there are other domains where eBPF can help you observe data. Recently during ebpf-summit 2020 there were a number of usecases presented by various industry leaders like Google, Facebook, Datadog, Adobe, Gitlab etc. You can view the recordings from the summit to know about the power of eBPF - https://ebpf.io/summit-2020
Ironically, BPF is a part of what Wireshark does for networking.
Also - read the piece: it is very informative.