anchor.diff:  having to update every other service to match. Muon takes the position that _availability_ (in the CAP theorum sense) is more
   likely to be systemically useful than _consistency_. Not all service discovery systems take this same view.
   
  -Service discovery is baked into the core of Muon, and every implementation has a similar looking subsystem.
  +Service discovery is baked into the core of Muon, and every implementation has a similar looking subsystem. This allows you
  +to build services that are _autonomous_ and _self healing_. As dependencies of a service start and stop, Muon can tell your application,
  +and it can react accordingly.
   
   This is accessed in Muon Java by the ```Discovery``` object. This is accessible on the Muon and gives access to listings
   of the existing services and a ```ServiceDescriptor``` for each remote service that is currently accessible by the local service.
  
positive.code: An example of this in action is
  
  [source,java,indent=0]
  ```
  include::src/main/java/io/muoncore/example/ReactiveRPCAsync.java[]
  ```
  //TODO, callouts and description
  
  This demonstrates adding the requests onto a queue and processing them asynchronously.
  
negative.code: You can then create a new Spring Boot based application as a Groovy script.
  
  [source,groovy,indent=0]
  ----
  include::src/main/groovy/io/muoncore/example/Introduction.groovy[lines=7..22]
  ----
  (1) TODO, make these work ok.
  
  [source,groovy,indent=0]
  ----
  include::src/main/groovy/io/muoncore/example/Introduction2.groovy[lines=7..22]
  ----
  
  These will run in production, as independent services and require no underlying platform or runtime.
  
  == Service Discovery
  
  