A Fractal Constellation of Autonomous Services
I've been talking to more and more people over the last few weeks about how the notion of autonomy affects the choices you make when designing a Service Oriented system.
I would like to propose two concepts which might help clarify how autonomy benefits a system, but first, let's just remind ourselves what autonomy means:
Autonomy:
1. liberty, immunity from arbitrary exercise of authority
2. self-direction, self-reliance, self-sufficiency
What autonomy gives us is loose-coupling - the ability to independently deploy, version, manage, locate and translocate services. In order to achieve autonomy, a service and its callers must not be welded together and should be largely self-sufficient. This is tricky to do today using some technologies, easier in others but explicitly consistent and easy with Indigo.
Autonomous services should be able to take care of themselves. Autonomous services should contain all of the behavior, data, process and mechanisms necessary to keep themselves running, even in the event of a catastrophic failure (such as network outage) beyond the service's boundaries. Autonomous services should be built to assume that he world outside its borders is untrustworthy, insecure and unreliable, but that there are compatriates out there who will honor the service's contracts and send correctly formatted and secured messages over an agreeable transport of some kind.
Autonomous services are not independent. Independence infers isolation. An independent service has no requirements on any other services and no other service makes any use of it.. It stands on an island, separated from the rest of the world, all lonely and bored. This is not a very useful topology.
I suggest that autonomous services should be composed in (at least) two ways:
- Constellations
- Fractals
A "constellation" of Services refers to a group of services which communicate amongst one another, sending messages that conform to mutually agreed contracts over mutually agreed transports and encoded in a mutually agreeable manner. These services collabarate and cooperate with one another rather than depend upon one another. If a service moves. its callers dynamically resolve the service's new location. If a service is upgraded, its callers can continue to send messages conforming to the originally agreed contracts or can opt to begin sending messages conforming to the more recent contracts. If a service's internals are modified and/or replaced, nothing else need know so long as the contracts are honored.
A "fractal" Service is one which encapsulates one or more services within it, preventing the services callers' from directly accessing any inner-services or outer-services. Peer inside a fractal service and you may find another service. Peer inside this service and find a constellation. Open up one of the constellation's services and there are yet more services inside. Look up and, guess what, you find that your service is inside another service. There are physics theoreticians who propose that the universe is structured in this manner. Fractal services provide encapsulation and control over who and what can access which services and when. Fractal services also help in the construction systems which can be decomposed into smaller sub-services, enabling the incremental building of a complex system.
Interestingly, both of these toplogies can be controlled and defined by infrastructure alone - there's no code required!
I hope this helps convey some interesting facets of how systems can be built from autonomous services and how autonomy affects how you construct your future systems.
