Kind of annoying to read. No, the P in CAP theorem isn’t when the client can’t connect to your unavailable service. That would be the A. Maybe it was down because of a P on your side, but don’t start blaming your downtime on network partitions between the client and your service.
Edit: your service going down and not being able to take requests from clients does not a network partition make
Isn't Availablility the ability to connect to something? If I'm calling from region A to region A servers, and the region A servers' networks go down. Well, my client is clever and can failover to region B servers. Except, all my state and context was on region A servers, and maybe that state wasn't replicated over to region B - that replication might only happen on a nightly basis.
When I reconnect, my dating profile is missing all the pictures I uploaded of me in my new convertible with me lowering my sunglasses and winking at the camera.
The LovinHuggin.com server architecture is Available, but not Partition Tolerant. And after I upload different pictures of me in tuxedos and talking like a boss on the cellphone to region B, I've potentially created a weird "split brain" situation. Region A and region B servers have different views of me. Both views are super hot, but the client might get confused if my session returns to region A when their network heals, and the nightly region replication might be messy with reconciling the split brain. Eventual consistency is a helpful (or fraught) feature to have in the database when things like split brain happen.
Interesting post. I appreciate their candor and self-criticism, but, as a customer, I'm consistently surprised by how robust Tailscale ends up being, and how rarely I've experienced an issue that actually broke my tailnet. The sort of downtime that might keep me from accessing the admin tool or something else like that is rare enough, but my nodes have almost (?) never failed to talk to each other. Pretty great.
Caveat: I have a very small tailnet (<100 nodes). Anyone running with thousands of nodes may have a very different experience where inconvenience might be existential.
The reason for that is that all nodes talk p2p to each other. There is no central communication server like with many other vpn solutions. So even if Tailscale would go down for days you won't have any downtime between your nodes.
It makes me wonder why they do not allow you to have a failover that is in your own tailnet. Ex: let me use one of my servers as the control plane, if stuff goes down let that coordinate everything. Maybe its too close to self hosting for them to do it?
11 comments
[ 3.5 ms ] story [ 31.4 ms ] threadTailscale is great technology and protocol and facilitates decentralisation.
Hypergrowth is a synonym for unsustainable growth. The headline here is business breaks tech, again.
Edit: your service going down and not being able to take requests from clients does not a network partition make
When I reconnect, my dating profile is missing all the pictures I uploaded of me in my new convertible with me lowering my sunglasses and winking at the camera.
The LovinHuggin.com server architecture is Available, but not Partition Tolerant. And after I upload different pictures of me in tuxedos and talking like a boss on the cellphone to region B, I've potentially created a weird "split brain" situation. Region A and region B servers have different views of me. Both views are super hot, but the client might get confused if my session returns to region A when their network heals, and the nightly region replication might be messy with reconciling the split brain. Eventual consistency is a helpful (or fraught) feature to have in the database when things like split brain happen.
Caveat: I have a very small tailnet (<100 nodes). Anyone running with thousands of nodes may have a very different experience where inconvenience might be existential.