I’m having trouble getting from sidekick to ambassador and back. The problem is clearly in the container networking wheelhouse; and progress seems to be wicked fast with new tools and idioms being published very rapidly. But here’s what I see:you have a client/server service paireach service runs in a different containereach container may or may not be on different hostseach service is subject to crashes or network partitioningcoreos/fleet is acting as a broker of sortsif the container restarts there is a chance that the container’s IP address will change and it’s pair will not necessarily be notifiedthe sidekick service is paired with each service in order to maintain the link.one shortcoming of the sidekick service is that it depends on being able to quietly update the config. The best example is the nginx example. (impedance mismatch)By contrastthis example breaks down when one of the services might be a user interface like a redis console.The ambassador pattern uses a special purpose sidekick pattern which corrects the impedance mismatch.where in the sidekick pattern the services seem to model the same client/server POV as it’s pair, in the ambassador model the service pairs are servers that implement a dynamic network proxyin order to repair the torn network fabric.I might have mangled the vocabulary but this fits in my mental model.