MightyMoud
commented
1 month ago Hi @gedw99,
I really appreciate your love for the project. Really makes my day.
I don't think I will take Sidekick that far tbh. I think I want to focus on making a great deployment tool that works with easy to get servers that you can rent easily. Hetzner/DigitalOcean and the like. Managing things that far would require Sidekick to manage some infra to allow and handle all those, correct me if I'm wrong here. I don't think I want to do that.
I'm definitely at awe of the way you broke things down and will have a look at all the libraries and invest more time into learning more about NATS for sure.
But generally the idea for sidekick is you get the servers, we set them up, deploy your app and off you go. Something that can come out of this is that if you give us multiple servers we set all of them up for you, then you can have a load balancer in front of them and do what you want. In the distant future I can imagine maybe we can ask you for servers across say 3 regions and one controller server and we deploy some code to the controller to do that. Using NATS maybe. (maybe that is what you meant all along?) Distant future tho and would be a massive expansion to the scope of the project.
gedw99
So fly has a few things that make it compelling, and that Side Kick could have.
It's got an Anycast / BGP proxy in front of everything. It's not DNS load balancing. Its below DNS with a single IP mapping to many IP.
This is how FLY does it magic geo physical load balancing. It's how Google AWS, etc etc do it. It's not magic.
https://bgpview.io/asn/40509#info shows the FLY config.
These are why FLY has Gateways.
Setting up your own ASN and BGP is not hard, but not exactly for the startups.
There is an alternative though :)
NATS Jetstream does the equivalent of BGP Anycast, without using BGP Anycas. Clients alway connect to the nearest server and also load balancing between them, but also real time server changes being reflected in the list of severs. As Servers do up and down, clients are told and NATS ensures that no RPC call is lost using NACK. It's all golang and has JS and GO connectors.
For Sidekick its compelling as both a control plane and data plane. You can find ally our dockers wherever they are. Clients connect in can connect to your nearest docker.
Its a dumb name but its basically scale to zero if not used, combined wit wake up if a request comes though.
With NATS we can do all this.
NATS can shut down any server based on usage, because the client nats.go can be backed into any Docker. Use Runner, so you dont have to compile it in too.
With NATS in the Data Plane, it can see the request, and direct it to the next nearest, whilst starting up a servers that is closer. The client will be told and then on its next request it will hit the closer server.
In many ways this is kind of better than fly. Client will not have to wait as long as one server somewhere is Up. We can also do zero server, and watch the data plane and start one top but that does not work for us, because we are not running Firecracker, and to be frank dont want to go that far. We just want good old docker that works anywhere that we have nested Virtualisation.
The other thing Fly has invested in is data replication.
NATS can do data replication. Both these use NATS for MASTER MASTER replication.
https://github.com/maxpert/marmot/tree/master/examples
https://github.com/voxoco/nqlite
Then you have a Volumes and blob storage.
We can do this now with Side kick, but we can make it a bit better perhaps with NATS controlling the data replication. NATS has an Object store, and so its can replicate to S3. SO you get multi region S3 balancing. There are plenty of examples-out there too.
https://github.com/wpnpeiris/nats-s3