Migrating Millions of Concurrent WebSockets to Envoy

Re:Migrating Millions of Concurrent WebSockets to Envoy by jayd16 on Wednesday March 17, 2021 @02:42PM (#26495224)

The Gmail load balancer has to do a cold restart to add or remove an instance? That's the requirement they placed on themselves because they do not trust the runtime HAProxy api.

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by jfrunyon on Wednesday March 17, 2021 @08:46PM (#26498603)

Are you saying that Slack don't trust it? Or Google? If the former, it's actually because they don't trust their code that used the HAProxy API. https://slack.engineering/a-terrible-horrible-no-good-very-b...

> Consul-template renders a new version of the host list, and a separate program developed at Slack, haproxy-server-state-management, reads that host list and uses the HAProxy Runtime API to update the HAProxy state. ... However, over the course of the day, a problem developed. The program which synced the host list generated by consul template with the HAProxy server state had a bug.

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by theflyinghorse on Wednesday March 17, 2021 @02:51PM (#26495329)

If they do not trust HAProxy runtime API then why are they using HAProxy at all?

[ Parent | on HN ]

Re:Migrating Millions of Concurrent WebSockets to Envoy by vad_ on Wednesday March 17, 2021 @03:32PM (#26495832)

Haproxy itself is a solid piece of software. The runtime API is something they added on top of it because of competitors (envoy).

[ Parent | on HN ]