←back to thread

Tailscale raises $100M

(tailscale.com)
854 points gmemstr | 1 comments | | HN request time: 0s | source
Show context
arsome ◴[] No.31261100[source]
I was going to try TailScale but then it seemed the only option to do so as an individual was to login with a 3rd party cloud provider, which I in no way want tied into my networks.

I gave up and just setup wireguard directly instead, I don't trust Tailscale either if that's their attitude towards privacy, it's permanently marred my vision of their product.

replies(10): >>31261128 #>>31261230 #>>31261250 #>>31261558 #>>31261667 #>>31261807 #>>31261815 #>>31261981 #>>31262022 #>>31262899 #
JeremyNT ◴[] No.31261250[source]
Indeed, this is why I won't use it either. I settled on Slack's Nebula [0] instead of wireguard because it handles direct p2p communication between nodes automatically.

There also exists an open source implementation of the tailscale control server [1] that you could self host.

[0] https://github.com/slackhq/nebula

[1] https://github.com/juanfont/headscale

replies(2): >>31261607 #>>31261688 #
rhuber ◴[] No.31261607[source]
(Nebula coauthor here)

People sometimes ask me to describe the differences between Nebula and Tailscale. One of the most important relates to performance and scale. Nebula can handle the amount of internal network traffic and scalability of nodes (100k+ nodes, constant churn) required on a large network like Slack's, but Tailscale cannot. Tailscale's performance is fine for many situations, but not suitable for infrastructure. It is just a fundamentally different set of goals.

Nebula was created and open sourced before Tailscale was offering their product, but their architecture is similar to older offerings in the market, and is something we purposely avoided when creating Nebula.

Fwiw, I even recommend Tailscale to friends who want to do things like connect to their Plex server or Synology or [other thing] at home remotely. It simplifies this kind of thing greatly and doesn't require you to set up any infrastructure you control directly, which can be a headache for folks who just want to reach a handful of computers/devices.

replies(6): >>31261776 #>>31261960 #>>31262150 #>>31262492 #>>31263218 #>>31264233 #
vgel ◴[] No.31262492[source]
> People sometimes ask me to describe the differences between Nebula and Tailscale. One of the most important relates to performance and scale. Nebula can handle the amount of internal network traffic and scalability of nodes (100k+ nodes, constant churn) required on a large network like Slack's, but Tailscale cannot. Tailscale's performance is fine for many situations, but not suitable for infrastructure. It is just a fundamentally different set of goals.

Making broad claims like this without a source or links to benchmarks feels like FUD to me. For example Tailscale's comparison page on performance (https://tailscale.com/kb/1148/tailscale-vs-nebula/#performan...) doesn't mention a meaningful performance difference, so if you're claiming they're not telling the truth (by omission), I'd hope to see more to that than just a straight assertion, even just "We tried Tailscale in Slack's network and it wasn't able to keep up with our usage patterns".

replies(1): >>31262546 #
rhuber ◴[] No.31262546{3}[source]
Another fair criticism. We will publish the benchmarks and make them repeatable (which most existing ones I've found don't bother to do). We hadn't done so because Tailscale isn't really seen as a direct competitor to what the Nebula project is doing, but if people want numbers, that's a thing we are happy to provide.
replies(2): >>31265922 #>>31266998 #
1. vgel ◴[] No.31266998{4}[source]
That's fair, if you've been benchmarking but haven't made the benchmarks public / repeatable yet. Too used to software where the authors claim it's fast with no proof or based on heuristics like what language it's written in :-)