ownCloud / oCIS - ownCloud Infinite Scale / Architecture Decisions / 6. Service Discovery within oCIS and Reva Edit this page

6. Service Discovery within oCIS and Reva

  • Status: accepted
  • Deciders: @refs, @butonic, @micbar, @dragotin, @pmaier1
  • Date: 2021-04-19

Technical Story: Introduce Named Services.

Context and Problem Statement

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.

Decision Drivers

  • 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)

Considered Options

  • Hardcoded tuples of hostname + port
  • Dynamic service registration

Decision Outcome

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.

Positive Consequences

  • 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 rega revistry.
  • 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.

Pros and Cons of the Options

Hardcoded tuples of hostname + port

  • 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.

Dynamic service registration

  • 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