Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hypergrowth isn’t always easy

tailscale.com

Post reply on HN
Print view View original

31–40 of 53 posts

Re: Hypergrowth isn’t always easy

#31

Post by direwolf20 »

arccy wrote: post #23
easton wrote: post #13

Earlier quoted context omitted.

Notably, it's a VPN for connecting your own devices together, so unless you're deploying a server elsewhere for access to porn it's probably not for that.

you can pay for the mullvad add-on to use their exit nodes

You can also just use Mullvad

Re: Hypergrowth isn’t always easy

#32

Post by direwolf20 »

wolttam wrote: post #27

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

A network partition between the client and server is a network partition between two nodes in a distributed system, which is the P.

Re: Hypergrowth isn’t always easy

#33

Post by deep_u »

wolttam wrote: post #27

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

This is a common misunderstanding about the poorly named ‘Availability’ in CAP. Availability under CAP means that if your request reaches a non-failing node, that node still responds despite being unable to communicate with other nodes. This is distinct from SLA-style availability, which describes the uptime of the overall system. I’m pretty sure the partition tolerance they’re referring to is the fact that the tailnet remains intact and continues to operate even when nodes can’t reach the coordination service.

Re: Hypergrowth isn’t always easy

#34

Post by rootnod3 »

Traubenfuchs wrote: post #29
rapnie wrote: post #24

In addition hypergrowth isn't needed. Grow naturally and healthy or just be sustainable, that's okay too.

> just be sustainable, that's okay too Not if most of your company was built on investor money. They want their pay day!

I think part of "grow naturally" assumed no investors. Just be self-sustaining with maybe some extra.

Re: Hypergrowth isn’t always easy

#35

Post by wolttam »

direwolf20 wrote: post #32
wolttam wrote: post #27

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

A network partition between the client and server is a network partition between two nodes in a distributed system, which is the P.

If there was a network partition, but it sounded like their service just went down.

Re: Hypergrowth isn’t always easy

#36

Post by internetter »

rapnie wrote: post #24

In addition hypergrowth isn't needed. Grow naturally and healthy or just be sustainable, that's okay too.

Hypergrowth can be natural. Random example but what if you designed a microblogging service and all of the sudden the biggest platform gets bought by a facist and users come flocking? You could start turning users away or you could work as fast as you can to accommodate them and make small mistakes along the way. Both of these are reasonable decisions and neither one is really wrong.

Re: Hypergrowth isn’t always easy

#37

Post by cael450 »

1dom wrote: post #5

No issues using headscale and selfhosted derp servers. Tailscale is great technology and protocol and facilitates decentralisation. Hypergrowth is a synonym for unsustainable growth. The headline here is business breaks tech, again.

> Hypergrowth is a synonym for unsustainable growth. The headline here is business breaks tech, again.

That just isn't true. Plenty of services do just fine after experiencing hypergrowth, and a few outages are not an example of tech breaking. That's a fairly common occurrence.

Re: Hypergrowth isn’t always easy

#38

Post by evan_ »

neom wrote: post #20
heyitsmedotjayb wrote: post #15

Not my deviantart ass thinking hypergrowth meant something else

Would you mind explaining this comment? (I worked on deviantart for many years when it started so I'm curious, tho the servers did literally melt at one point)

the joke is porn

a specific type of porn

Re: Hypergrowth isn’t always easy

#40

Post by clayhacks »

elashri wrote: post #6
1dom wrote: post #5

No issues using headscale and selfhosted derp servers. Tailscale is great technology and protocol and facilitates decentralisation. Hypergrowth is a synonym for unsustainable growth. The headline here is business breaks tech, again.

How do you selfhost your own derp servers? I am curious if it is an easy like headscale itself

It’s not super well fleshed out by Tailscale but they have a guide.

https://tailscale.com/kb/1118/custom-derp-servers

My last company ran our own DERP servers to have more consistent endpoints we controlled

Post reply on HN