6. Service Discovery within oCIS and Reva
Technical Story: Introduce Named Services.
Reva relies heavily on config files. A known implication of this approach are having to know a-priori where a service is running (host + port). We want to move away from hardcoded values and rely instead on named services for service discovery. Furthermore, we would like both platforms (Reva + oCIS) to have the same source of truth at any given time, not having one to notify the other whenever a service status changes.
- Avoid a-priori knowledge of services.
- Ease of scalability.
- Always up-to-date knowledge of the running services on a given deployment (a service registry doesn’t have to necessarily be running on the same machine / network)
- Hardcoded tuples of hostname + port
- Dynamic service registration
Chosen option: “Dynamic service registration”. There were some drawbacks regarding this due to introducing go-micro to Reva was from start an issue. Given the little usage of go-micro we need, we decided instead to define our very own Registry interface on Reva and extended the runtime arguments to allow for injecting a registry.
- Having dynamic service registration delegates the entire lifecycle of finding a process to the service registry.
- Removing a-priori knowledge of hostname + port for services.
- Marrying go-micro’s registry and a newly defined registry abstraction on Reva.
- We will embrace go-micro interfaces by defining a third merger interface in order to marry go-micro registry and reva registry.
- The ability to fetch a service node relying only on its name (i.e: com.owncloud.proxy) and not on a tuple hostname + port that we rely on being preconfigured during runtime.
- Conceptually speaking, a better framework to tie all the services together. Referring to services by names is less overall confusing than having to add a service name + where it is running. A registry is agnostic to “where is it running” because it, by definition, keeps track of this specific question, so when speaking about design or functionality, it will ease communication.
- Good, because firewalls are easier to configure since IP are static.
- Good, because the mental model required is easier to grasp as IP addresses can be easily bundled.
- Bad, because it requires thorough planning of ports.
- Good, because it abstracts the use of service lookup away to registry logic from the admin or developer.
- Good, because it allows for, through interfaces, registry injection
- This means we can have a service registry that we extensively use in oCIS and inject its functionality onto Reva.
- Bad, because it’s yet another abstraction.
- Bad, because firewalls are harder to configure with dynamic IPs.f