Dynamic by design

So when we think about loosely coupled services that compounds bigger complex services and expects resiliency, high availability, security and performance, between other key qualities. All single component of the tissue should behave to address those premises. Some functionality should be provided by the tissue DNA and the services should inherit those functionality without knowing how to do this.As a dynamic system the tissue use the service movement as a key function to increase availability and security, without interacting with the tissue core repository is not possible to know where is what, only the tissue itself knows that and protects this information from outside. Even a service don't know the whole tissue dimension.To implement the service movement architecture, some premises needs to be achieved:

• Migration between datacenter providers
• DNS service based on service availability
• DNS TTL on entry reduced while service migrations/recovery
• One DNS entry by service (TCP port) 
• This is a restriction not a functionality, to adapt to TCP/IP thinking way.
• All listening service should be load balanced (this is a requirement for high availability)
• Socket Listening services should implement a tissue listening API, that provides the same behavior for all listening components.
• Load Balancer registry using service tissue DNA.
• Load balancer balancing using service performance and availability information in the tissue DNA.
• One empty DNS service is started. There is not services available into the tissue yet. Is uses the tissue DNA as DNS entry catalog.
• When a load balancer service starts it registers itself into tissue DNA and is automatically available throught the tissue DNS service.
• When a listener service start it registers itself into tissue DNA and is automatically available to receive traffic routing from load balancing services. 
• The tissue DNA is replicated among the tissue and following the DNA service requirements.
• All load balancers are able to start forwarding for new listening services as it appears in the tissue DNA.
• Client do a DNS query to locate service (one hostname means a service).
• DNS service uses the tissue DNA to locate the  load balancer responsible for the service.
• DNS service answers the query with the IP of one loadbalancer.
• The client opens a socket to the IP received of a load balancer.
• The load balancer looks a listening service into the tissue DNA:
• More attributes are used to define the best listening service to forward the request to.
• If no listening service available throws an error.
• The load balancer creates a new socket to the listening service and forwards the client request:
• Wait for a determined timeout for the service.
• If the listening returns and error tries to open another socket to other listening service (connection errors).
• Tries to establish the connect a determined number of times.
• The listening service receives the socket and deals with it (forwarding or calling other sub-services).
• The listening service answers the request to the load balancer.
• The load balancer service answers the request to the client.

Sample service instantiation:

Sample service consumption:

This is a very simple task list of service flow, the way that is is divided, it can be used to scale horizontally maybe between datacenters, using load balancing for high availability and DNS roud robin for contingency. The DNS contingency can guarantee the right name resolution for valid IP address because it is based on a dynamig catalog (tissue DNA) istead of a static catalog.