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 pair
- each service runs in a different container
- each container may or may not be on different hosts
- each service is subject to crashes or network partitioning
- coreos/fleet is acting as a broker of sorts
- if the container restarts there is a chance that the container’s IP address will change and it’s pair will not necessarily be notified
- the 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)
- this 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 proxy
- in order to repair the torn network fabric.
I might have mangled the vocabulary but this fits in my mental model.