Oh, wow, I forgot that this (database ingress filtering) was a big motivator for the engineering project we were considering for giving apps persistent outbound IP addresses, a project I loathe and now have another arrow in my quiver with which to shoot it down.
I stand alone athwart all efforts to introduce dynamic routing protocols here.
(I could still lose this argument if there are comparably important use cases).
Infra engineering is the most important, hardest engineering practice in the company. I'm not one, and the people who want to do this are. So leave a lot of space here for me just being wrong.
I've had a bit of experience implementing IGP-style routing --- both as a "user" (a Cisco network engineer doing multi-area OSPF) and a developer (of a custom link-state IGP) --- and it left me pretty terrified of the failure modes here, which feel pretty similar to those of Raft/Paxos consensus, or of the SWIM Gossip consensus we do in our Consul replacement, Corrosion, which has its own challenges. If there are "innovation tokens", there are also "distributed consensus" tokens, and my basic take is I don't think we should spend them for such a marginal feature.
Here I am litigating an internal company discussion on HN (this is simultaneously bad, and an exercise in us just being an open book). I remind you of the initial paragraph here, which lays out plainly that the people in our company who disagree with me are smarter than me. A really good use case could end my reign of static routing reign of terror!
One can try to push Fly.io to implement dynamic routing to get persistent outbound IP addresses. This is full of foot guns and dragons.
Or one can push the other vendor to implement vpn support on their side such that their service can talk to Fly.io-hosted ones in an end-to-end secure channel so the actual services can trust that a lot more. This is the solution often suggested in Fly.io forums.
If the other vendor is sending ostensibly private traffic over the public internet and relying on a combination of “the Postgres protocol is safe and passwords are strong enough” and “oh but they really aren’t so we will limit this service to talk to only one IP address” it seems to me it’s them who should be nudged towards a more secure and versatile solution.
I stand alone athwart all efforts to introduce dynamic routing protocols here.
(I could still lose this argument if there are comparably important use cases).