What aren't we doing?
Before we get started, we should make sure we're clear about what we aren't doing. This will inform choices that we make further down the line, and ensure our load balancer does what we need it to without being more complicated than necessary.
Writing our own reverse proxy - this is relatively complicated. If you're interested, look at the Go standard library methods which we'll be using.
Allowing more than two backends - normally there would be a large number of servers, with a canary being a small subset. In this case, we only need our existing server and our new code on the canary host.
Running health checks - load balancers generally ensure the servers they are talking to are healthy, but because we're only working with two, we'll assume they're up and running fine.
Tracing - this can be an important aspect of understanding the health of the canary deployment, especially when things go wrong, but handling it distracts from our primary goal of setting up the canary deployment server.